Tenable Cloud and AI Security Risk Report 2026

Tenable Research analysierte anonymisierte Telemetriedaten aus einer globalen Stichprobe öffentlicher Cloud- und Unternehmensumgebungen, die zwischen April und Oktober 2025 gescannt wurden, wobei sich die Analyse für KI-bezogene Erkenntnisse bis Dezember 2025 erstreckte. Die Ergebnisse dokumentieren vier sich überschneidende Fehlerzonen: KI-Sicherheitsgovernance, Lieferkettenrisiko, Identitätsmanagement und Workload-Patching. Keines dieser Risiken ist isoliert. Zusammen bilden sie einen vernetzten Ausnutzungspfad, den Gegner bereits nutzen.

Die Lücke in der KI-Governance

Ab 2025 nutzen 55 Prozent der Unternehmen KI-Tools für aktive Geschäftsbedürfnisse. Diese Akzeptanzrate wurde nicht von Sicherheitsdisziplin begleitet. Unter Verwendung von Amazon Web Services als repräsentativem Ausgangspunkt stellten Forscher fest, dass 18 Prozent der Unternehmen IAM-Rollen – Identitäts- und Zugriffsmanagementkonfigurationen – mit kritischen oder hohen übermäßigen Berechtigungen besitzen, die AWS-KI-Dienste wie Amazon SageMaker oder Amazon Bedrock sofort übernehmen können. Davon weisen 13 Prozent übermäßige Berechtigungen mit kritischer Schwere auf.

Das Problem geht tiefer als aktive Fehlkonfigurationen. Standardausführungsrollen – IAM-Rollen, die AWS während der Schnellstart-Bereitstellungen automatisch generiert – werden nach der Ersteinrichtung routinemäßig aufgegeben. Im Durchschnitt sind 73 Prozent der Standardausführungsrollen von SageMaker und 70 Prozent der Agentenrollen von Bedrock in den analysierten Organisationen inaktiv. Diese ruhenden Rollen verschwinden nicht; sie warten und halten breite Berechtigungen, die niemand überwacht. Ein Angreifer, der eine laufende Modellinstanz kompromittiert oder Berechtigungen zum Starten einer neuen erhält, erbt diese Privilegien sofort.

Ein kleineres, aber wachsendes Problem sind statische API-Schlüssel. Drei Prozent der Organisationen stellten Anmeldeinformationen für Drittanbieter von KI-Diensten – hauptsächlich OpenAI und Anthropic – fest, die in Konfigurationsdateien als Code, wie z. B. Terraform-Zustandsdateien und .env-Dateien, die in Cloud-Datenressourcen gespeichert sind, fest codiert waren. Das kurzfristige Risiko ist das Ressourcen-Hijacking: Ausgelaufene Schlüssel ermöglichen die unbefugte Nutzung von KI-Rechenquoten, die der Opferorganisation in Rechnung gestellt werden. Da die Produktionsbereitstellung von KI-APIs von Drittanbietern zunimmt, wird erwartet, dass diese Zahl steigen wird.

Auf Protokollebene wurde das Model Context Protocol (MCP) – ein Standard zur Verbindung großer Sprachmodelle mit externen Tools und Datenquellen – von 50 Prozent der analysierten Organisationen integriert, weniger als ein Jahr nach seiner Veröffentlichung. Siebzig Prozent der Organisationen haben jetzt mindestens ein KI- oder MCP-Drittanbieter-Code-Paket in ihrer Umgebung. Die Geschwindigkeit der Einführung birgt einen zentralisierten Angriffsvektor: Ein kompromittierter MCP-Server oder einer, der durch einen Namensverwirrungsangriff imitiert wird, kann unbefugten Zugriff auf die Tools und Datenquellen gewähren, die diese Organisationen eilig zu vereinheitlichen versuchen.

Lieferkettenrisiko in großem Maßstab

Code-Pakete von Drittanbietern sind das Bindegewebe moderner Cloud-Anwendungen. Sie sind auch ein primärer Vektor für ererbtes Risiko. Über alle analysierten Umgebungen hinweg weisen 86 Prozent der Organisationen mindestens ein installiertes Paket mit einer kritischen Sicherheitslücke auf. Einunddreißig Prozent weisen kritische Schwachstellen in 100 oder mehr separaten Paketen auf.

Über die passive Gefährdung hinaus haben 13 Prozent der Organisationen – fast jede achte – mindestens ein Paket mit nachgewiesener aktiver Kompromittierung eingesetzt. Zwei Kampagnen aus dem dritten Quartal 2025 veranschaulichen den Umfang. Shai-Hulud war ein sich selbst replizierender Wurm, der in legitimen npm-Paketen eingebettet war, darunter einige, die von einem großen Cybersicherheitsanbieter veröffentlicht wurden. Nachdem die Malware Anmeldeinformationen gestohlen hatte, versuchte sie, sich mit den Veröffentlichungsdaten des Opfers in andere interne Projekte auszubreiten. Bis November 2025 hatte eine aggressivere Variante Hunderte von hochkarätigen Paketen kompromittiert, was auf eine Gesamtexposition über die ursprünglichen Erkenntnisse hinaus hindeutete. Die Singularity-Kampagne zielte auf das nx-Paketökosystem auf npm ab, durchsuchte Dateisysteme nach KI- und Cloud-Plattformschlüsseln und veröffentlichte gestohlene Anmeldeinformationen direkt in öffentlichen GitHub-Repositories.

Der externe Identitätszugriff verschärft das Problem. Mehr als die Hälfte der Organisationen – 53 Prozent – hat externen Konten die Möglichkeit eingeräumt, kritische übermäßige Berechtigungen zu übernehmen. In 14 Prozent der Organisationen sind über 75 Prozent aller Cloud-Ressourcen für externe Konten zugänglich. Fünf Prozent der Organisationen, insbesondere diejenigen, die Microsoft Entra ID oder Google Cloud Platform nutzen, haben bereits kritische übermäßige Berechtigungen direkt an mindestens einen Gast- oder externen Benutzer vergeben, ohne dass ein Eskalationsschritt erforderlich ist.

Schlafende Identitäten und vergessene Anmeldedaten

Das Prinzip der geringsten Privilegien, also der Grundsatz, dass Identitäten nur die Berechtigungen haben sollten, die sie aktiv benötigen, wird nach wie vor weitgehend nicht durchgesetzt. Im Durchschnitt sind 49 Prozent aller Identitäten mit kritischen, übermäßigen Berechtigungen inaktiv, da sie seit mindestens 90 Tagen nicht genutzt wurden. Bei menschlichen Identitäten mit kritisch übermäßigen Berechtigungen liegt die Inaktivitätsrate sogar bei 72 Prozent.

Nicht-menschliche Identitäten, einschließlich Dienstkonten, Automatisierungsrollen und KI-Agenten, bergen heute ein höheres Risiko als menschliche Konten: 52 Prozent der Unternehmen verfügen über nicht-menschliche Identitäten mit kritischen, übermäßigen Berechtigungen, verglichen mit 37 Prozent bei menschlichen Identitäten. Diese Maschinenkonten sind häufig überdimensioniert, um schnelle Bereitstellungszyklen zu unterstützen, und werden selten auf die Einhaltung des Prinzips der geringsten Privilegien überprüft.

Vergessene Anmeldedaten stellen eine weitere Ebene der dauerhaften Gefährdung dar. Rund 65 Prozent der Organisationen verfügen über ungenutzte oder nicht rotierte Schlüssel, die an Identitäten mit kritischen oder hohen übermäßigen Berechtigungen angehängt sind. Dies ist eine Verbesserung gegenüber den 84 Prozent aus dem Jahr 2024, stellt jedoch immer noch eine breite Angriffsfläche dar. In 17 Prozent der Organisationen sind diese Anmeldeinformationen mit Identitäten verknüpft, die über volle administrative Rechte verfügen. Ein kompromittierter Schlüssel auf dieser Ebene erfordert keine laterale Bewegung, da er sich bereits am Zielort befindet.

Ungeschützte Arbeitslasten

Zweiundachtzig Prozent der Organisationen betreiben mindestens eine Cloud-Workload, die bekannte, ausgenutzte, kritische CVEs (Common Vulnerabilities and Exposures) enthält. Das sind Schwachstellen, die im CISA-Katalog der bekannten, ausgenutzten Schwachstellen aufgeführt sind und für die aktiver Exploit-Code existiert. Die Sanierungslücke ist keine Frage der Erkennung: Organisationen scannen. Das Scheitern liegt jedoch in der Priorisierung und Umsetzung.

Virtuelle Maschinen tragen den Großteil des nicht gepatchten Risikos: Sie kommen in 77 Prozent der Unternehmen mit ungepatchten, kritischen oder hochschwerwiegenden Schwachstellen vor und machen 84 Prozent aller ungepatchten Workloads nach Volumen aus. Container-Images sind zwar weit verbreitet, machen aber einen viel geringeren Anteil an ungepatchten Systemen aus, obwohl sie einen unverhältnismäßig großen Teil der Gefährdung durch Betriebssysteme darstellen, deren Lebenszyklus endet. Dies deutet auf Fehler in der Governance von Basis-Images hin.

57 Prozent der Unternehmen betreiben Workloads auf Betriebssystemen, die das Ende ihres Lebenszyklus erreicht haben oder sich diesem nähern. Das bedeutet, dass vom Hersteller keine weiteren Sicherheitspatches verfügbar sind.

Das Tempo der Ausbeutung beschleunigt sich. So wurde Anfang Dezember 2025 eine Remote-Code-Ausführbarkeitslücke mit maximaler Schwere in React – CVE-2025-55182 mit einem CVSS-Score von 10,0 – innerhalb von sechs Stunden nach der öffentlichen Bekanntmachung als aktiv in freier Wildbahn ausgenutzt bestätigt. Zwei Wochen nach Veröffentlichung eines Patches führten noch immer 12 Prozent der Unternehmen anfällige Workloads aus und waren somit einem bekannten, als Waffe eingesetzten Angriffspfad ausgesetzt.

Das Konvergenzproblem

Nicht eine einzelne Erkenntnis macht die Ergebnisse besonders relevant, sondern die Art und Weise, wie diese Risiken miteinander verbunden sind. Ein KI-Dienst nimmt eine überprivilegierte IAM-Rolle ein. Diese Rolle gehört zu einer Identität, deren Referenzen seit Monaten nicht mehr aktualisiert wurden. Die Arbeitslast, die der Dienst ausführt, enthält eine ungepatchte CVE. Die Konfigurationsdatei, die den API-Schlüssel enthält, wird in einem Cloud-Bucket gespeichert, auf den ein externes Anbieterkonto zugreifen kann.

Um diesen Weg zu gehen, ist keine neue Leistung erforderlich. Der Bericht stellt die Herausforderung als ein Problem des Expositionsmanagements und nicht der Erkennung dar. Die Route des Gegners durch die Umgebung kann im Voraus kartiert werden und die Knoten entlang dieser Route können entfernt werden. Zu den operativen Maßnahmen zählen die Stilllegung ruhender Identitäten, die Rotation veralteter Anmeldeinformationen, die Durchsetzung des Prinzips der geringsten Privilegien für KI-Rollen, die Validierung von Drittanbieterpaketen vor der Bereitstellung und das Patchen von Workloads in der Reihenfolge der Ausnutzbarkeit und nicht nur nach CVSS-Wert. Architektonische Überarbeitungen sind dies nicht.

Die zugrunde liegende Bedingung, die das Risiko antreibt, ist in allen vier Kategorien dieselbe: Die Entwicklungsgeschwindigkeit hat die Sicherheitskontrolle überholt. Um diese Lücke zu schließen, muss man nicht langsamer werden. Es ist erforderlich, die Kontrollen vor der Bereitstellung und nicht danach einzubauen.

Tenable Research analyzed anonymized telemetry from a global sample of public cloud and enterprise environments scanned between April and October 2025, extending to December 2025 for AI-related findings. The results document four overlapping failure zones: AI security governance, supply chain exposure, identity management, and workload patching. None of these risks is isolated. Together, they form a connected exploitation path that adversaries are already using.

The AI governance gap

As of 2025, 55 percent of organizations use AI tools for active business needs. That adoption rate has not been matched by security discipline. Using Amazon Web Services as a representative baseline, researchers found that 18 percent of organizations possess IAM roles — identity and access management configurations — with critical or high excessive permissions that AWS AI services such as Amazon SageMaker or Amazon Bedrock can instantly assume. Of those, 13 percent carry critical-severity excessive permissions.

The problem runs deeper than active misconfigurations. Default execution roles — IAM roles that AWS generates automatically during quick-start deployments — are routinely abandoned after initial setup. On average, 73 percent of SageMaker default execution roles and 70 percent of Bedrock agent roles are inactive across the organizations analyzed. These dormant roles do not disappear; they wait, holding broad permissions that no one is monitoring. An attacker who compromises a running model instance, or gains permissions to launch a new one, inherits those privileges immediately.

A smaller but growing problem involves static API keys. Three percent of organizations were found to have exposed credentials for third-party AI providers — primarily OpenAI and Anthropic — hardcoded in configuration-as-code files such as Terraform state files and .env files stored in cloud data resources. The near-term risk is resource hijacking: leaked keys enable unauthorized use of AI compute quotas billed to the victim organization. As production deployment of third-party AI APIs grows, this figure is expected to rise.

On the protocol level, Model Context Protocol (MCP) — a standard for connecting large language models to external tools and data sources — has been integrated by 50 percent of analyzed organizations, less than a year after its release. Seventy percent of organizations now have at least one AI or MCP third-party code package in their environment. The speed of adoption introduces a centralized attack vector: a compromised MCP server, or one impersonated through a name-confusion attack, can grant unauthorized access to the tools and data sources those organizations are rushing to unify.

Supply chain exposure at scale

Third-party code packages are the connective tissue of modern cloud applications. They are also a primary vector for inherited risk. Across the environments analyzed, 86 percent of organizations have at least one installed package containing a critical-severity vulnerability. Thirty-one percent host critical vulnerabilities across 100 or more separate packages.

Beyond passive vulnerability exposure, 13 percent of organizations — nearly one in eight — have deployed at least one package with a documented history of active compromise. Two campaigns from the third quarter of 2025 illustrate the scope. Shai-Hulud was a self-replicating worm embedded in legitimate npm packages, including some published by a major cybersecurity vendor. After stealing credentials, the malware attempted to propagate into other internal projects using the victim’s own publishing credentials. By November 2025, a more aggressive variant had compromised hundreds of high-profile packages, suggesting total exposure beyond the initial findings. The s1ngularity campaign targeted the nx package ecosystem on npm, scraping file systems for AI and cloud platform keys and publishing stolen credentials directly to public GitHub repositories.

External identity access compounds the problem. More than half of organizations — 53 percent — have granted external accounts the ability to assume critical excessive permissions. In 14 percent of organizations, over 75 percent of all cloud resources are accessible to external accounts. Five percent of organizations, specifically those using Microsoft Entra ID or Google Cloud Platform, have already assigned critical excessive permissions directly to at least one guest or external user, with no escalation step required.

Dormant identities and forgotten credentials

Least privilege — the principle that identities should hold only the permissions they actively need — remains widely unenforced. On average, 49 percent of all identities holding critical excessive permissions are inactive, having gone unused for at least 90 days. For human identities with critical excessive permissions, the inactivity rate reaches 72 percent.

Non-human identities, including service accounts, automation roles, and AI agents, now represent a higher risk concentration than human accounts: 52 percent of organizations have non-human identities with critical excessive permissions, compared to 37 percent for human identities. These machine accounts are frequently over-provisioned to support rapid deployment cycles and are rarely audited for least-privilege alignment.

Forgotten credentials add a further layer of persistent exposure. Some 65 percent of organizations have unused or unrotated keys attached to identities with critical or high excessive permissions — an improvement from 84 percent reported in 2024, but still representing a broad attack surface. In 17 percent of organizations, those credentials are tied to identities with full administrative privileges. A compromised key at that level does not require lateral movement; it is already at the destination.

Workloads left exposed

Eighty-two percent of organizations operate at least one cloud workload containing known, exploited, critical CVEs — vulnerabilities that appear on the CISA Known Exploited Vulnerabilities catalogue and for which active exploit code exists. The remediation gap is not a matter of detection: organizations are scanning. The failure is in prioritization and follow-through.

Virtual machines carry the bulk of unpatched risk, appearing in 77 percent of organizations with unpatched critical or high-severity vulnerabilities and accounting for 84 percent of all unpatched workloads by volume. Container images, while widely used, account for a far smaller share of unpatched systems — though they represent a disproportionate share of end-of-life operating system exposure, pointing to failures in base image governance.

Fifty-seven percent of organizations run workloads on operating systems that have reached or are approaching end of life, meaning no further security patches are available from the vendor.

The pace of exploitation is accelerating. In early December 2025, a maximum-severity remote code execution vulnerability in React — CVE-2025-55182, carrying a CVSS score of 10.0 — was confirmed as actively exploited in the wild within six hours of public disclosure. Two weeks after a patch was released, 12 percent of organizations were still running vulnerable workloads, leaving them exposed to a known, weaponized attack path.

The convergence problem

What makes the findings particularly relevant is not any single finding but the way these risks connect. An AI service assumes an overprivileged IAM role. That role belongs to an identity whose credentials have not been rotated in months. The workload running the service contains an unpatched CVE. The configuration file holding its API key is stored in a cloud bucket accessible to an external vendor account.

No novel exploit is required to traverse that path. The report frames the challenge as an exposure management problem rather than a detection problem: the adversary’s route through the environment can be mapped in advance, and the nodes along it can be removed. Decommissioning dormant identities, rotating stale credentials, enforcing least privilege for AI roles, validating third-party packages before deployment, and patching workloads in order of exploitability rather than CVSS score alone — these are operational measures, not architectural overhauls.

The underlying condition driving the risk is the same across all four categories: engineering velocity has outpaced security governance. Closing that gap does not require slowing down. It requires building the controls in before the deployment, not after.