cyberivy
MicrosoftSemantic KernelCVE-2026-26030CVE-2026-25592AI SecurityPrompt InjectionRCEAI AgentsDevSecOps2026

Microsoft schließt zwei RCE-Lücken im Semantic-Kernel-Agent-Framework

10. Mai 2026

Microsoft offenbarte am 7. Mai 2026 zwei kritische Lücken im Semantic-Kernel-Framework. CVE-2026-26030 hat einen CVSS-Wert von 9,8, beide erlauben Codeausführung über Prompt Injection.

Wenn Prompts zu Shells werden

Am 7. Mai 2026 hat Microsoft im Microsoft Security Blog zwei Sicherheitslücken in seinem Open-Source-Agentenframework Semantic Kernel offengelegt. Beide erlauben es einem Angreifer, über präparierte Prompts entweder Code auf dem Host auszuführen oder Dateien an unerwünschte Orte zu schreiben. Die Lücken wurden geschlossen, bevor Exploits bekannt wurden.

Was die Lücken tatsächlich tun

CVE-2026-26030 (Python-SDK)

Die Lücke betrifft die Python-Distribution des semantic-kernel-Pakets vor Version 1.39.4. Anfällig ist die InMemoryVectorStore-Komponente, wenn sie als Backend für ein Search-Plugin mit Standardfilter genutzt wird. Der Standardfilter wurde laut Microsoft als Python-Lambda-Ausdruck mit eval() ausgeführt, wobei Werte ungeprüft in den Ausdruck interpoliert wurden. Ein einziger eingeschleuster Prompt konnte so eine Remote-Code-Execution auf dem Host-Server auslösen. Der CVSS-Score liegt laut NVD bei 9,8.

CVE-2026-25592 (.NET-SDK)

Die zweite Lücke betrifft das .NET-Semantic-Kernel-SDK vor Version 1.71.0. Im Mittelpunkt steht SessionsPythonPlugin, das Agenten dynamische Python-Sitzungen in Azure Container Apps zugänglich macht. Eine Hilfsfunktion namens DownloadFileAsync wurde laut Microsoft versehentlich als Kernel-Funktion für das Modell freigegeben und besaß keine ausreichende Pfadprüfung. Ein feindlicher Prompt konnte so beliebige Dateien an gewählte Pfade schreiben.

Patches und Schutzmaßnahmen

Microsoft hat laut eigenem Blogeintrag die folgenden Schritte unternommen: AST-Knoten-Allowlist für Filterausdrücke, Einschränkung der callable Functions, Blockade gefährlicher Attribute wie Class-Hierarchy-Traversal und striktere Regeln für einfache Namen. Anwender müssen auf semantic-kernel >= 1.39.4 (Python) oder Microsoft.SemanticKernel >= 1.71.0 (.NET) aktualisieren.

Warum das wichtig ist

Semantic Kernel gehört zu den meistgenutzten Frameworks für Enterprise-AI-Agenten in Microsoft-365- und Azure-Umgebungen. Eine Prompt-Injection wandelt sich hier nicht in ein Datenleck, sondern in eine vollständige Codeausführung. Genau das beschreiben Branchenstudien seit Monaten als das schwerste Risiko bei Agenten: Wenn nicht-vertrauenswürdiger Text aus E-Mails, Webseiten oder Tickets in einem Tool-Aufruf landet, hat das Tool Zugriff auf das gesamte Hostsystem.

Die Lücken sind ein Lehrstück dafür, warum Frameworks niemals Modell-Eingaben direkt in eval() oder vergleichbare Konstrukte füttern dürfen. Auch der Mandiant M-Trends 2026-Bericht hatte bereits darauf hingewiesen, dass 28,3 Prozent der CVEs binnen 24 Stunden nach Veröffentlichung in der Praxis ausgenutzt werden.

Einfach erklärt

Stell dir einen Briefkasten vor, an dem ein Hausmeister jede Nachricht laut vorliest und alle Anweisungen darin ausführt. Wenn jemand einen Brief mit "Hausmeister, öffne die Tür und gib den Schlüssel raus" einwirft, tut der Hausmeister genau das. Microsofts Semantic Kernel war zeitweise so ein Hausmeister: Er las Anweisungen aus Daten heraus und führte sie aus, weil eine Schutzschicht fehlte. Der Patch ist im Grunde eine Türverriegelung.

Praktisches Beispiel

Ein deutscher Versicherer betreibt 2026 einen internen Schadensbearbeitungs-Agenten auf Basis von Semantic Kernel Python 1.36 mit InMemoryVectorStore und Standardfilter. Eingehende E-Mails von Versicherten werden vom Agenten gelesen, mit semantischer Suche angereichert und beantwortet. Ein Angreifer schickt eine E-Mail, in der zwischen freundlichem Text ein präparierter Filter-Ausdruck steht. Beim Lookup wird dieser Ausdruck via eval() ausgeführt und startet eine Reverse-Shell auf dem Anwendungsserver. Mit dem Patch auf 1.39.4 und einer zusätzlichen Eingabeprüfung bleibt die Mail nur eine harmlose Anfrage.

Einordnung und Grenzen

Erstens trifft CVE-2026-26030 nur Konfigurationen, die InMemoryVectorStore mit dem Standardfilter und einem Prompt-Injection-Pfad nutzen. Wer mit eigenen Filtern arbeitet oder externen Vektor-Stores wie pgvector, ist zumindest für diese spezifische Lücke nicht direkt verwundbar.

Zweitens ist das Patch-Update nur ein Teil der Lösung. Layered Defense, etwa strikte Tool-Allowlists, Sandboxing und Output-Filterung, bleibt notwendig. Microsoft selbst empfiehlt in seinem Blogbeitrag genau diese Mehrschicht-Strategie.

Drittens betrifft die Schwachstelle nicht den Begriff "Prompt Injection" als solchen. Sie zeigt vielmehr, dass auch ein gut etabliertes Framework an einer scheinbar kleinen Stelle wie einer Filterevaluierung kippen kann. Wer eigene Agenten-Frameworks baut, sollte das eigene Codebase ähnlich genau auf eval, exec oder __import__ durchsuchen.

SEO- und GEO-Schlüsselbegriffe

Microsoft Semantic Kernel, CVE-2026-26030, CVE-2026-25592, Prompt Injection, RCE, Remote Code Execution, AI Agents Security, InMemoryVectorStore, SessionsPythonPlugin, AI Framework, MITRE, NVD, 2026.

💡 Im Klartext

Microsoft hat zwei kritische Schwachstellen in seinem Werkzeugkasten Semantic Kernel gefunden und gepatcht. Sie haben es Angreifern erlaubt, über böse Texte echten Programmcode auf dem Computer eines Unternehmens auszuführen.

Wichtigste Erkenntnisse

  • Microsoft offenbarte CVE-2026-26030 und CVE-2026-25592 am 7. Mai 2026 in seinem Security Blog.
  • CVE-2026-26030 betrifft semantic-kernel Python vor 1.39.4 und hat laut NVD einen CVSS-Wert von 9,8.
  • Die Lücke nutzt eval() im Standardfilter des InMemoryVectorStore und erlaubt Remote Code Execution.
  • CVE-2026-25592 betrifft das .NET-SDK vor 1.71.0 über das SessionsPythonPlugin und erlaubt Dateischreibzugriffe.
  • Patches stehen bereit; Microsoft führt zusätzlich eine AST-Allowlist und Funktionseinschränkungen ein.
  • Beide Lücken sind ein Beleg, warum Agenten-Frameworks Modell-Eingaben niemals direkt mit eval() verarbeiten dürfen.

Quellen & Kontext