Semantic Kernel: Wenn der Prompt zur Shell wird — was die Microsoft-Disclosure für Ihre Agent-Architektur bedeutet

TL;DR — die 90-Sekunden-Zusammenfassung

Betroffen?

Microsoft Semantic Kernel .NET vor 1.71.0 (CVE-2026-25592, SessionsPythonPlugin) und Python vor 1.39.4 (CVE-2026-26030, InMemoryVectorStore Default-Filter). Indirekt: jedes Mittelstand-Stack mit Semantic Kernel in Agent-Architektur, oft unsichtbar als requirements.txt-Eintrag.

Risiko?

Prompt-Injection → Remote Code Execution auf dem Host. CVE-25592: Datei-Schreib-Tool ungewollt exponiert, Pfad-Validierung fehlt. CVE-26030: Default-Vector-Store-Filter nutzt eval() auf nutzergesteuertem String.

Sofortmaßnahme?

Versionsstand prüfen, Plugin-Inventur (welche Kernel-Funktionen sind Modell-Tools?), Default-InMemoryVectorStore auf Azure AI Search oder pgvector wechseln.

Empfehlung?

Mittelstand mit Semantic-Kernel-Agent: Patch + Plugin-Audit. Enterprise: zusätzlich Sandbox-Grenze als separater Prozess (Wolfi-OS, Firecracker, Azure Dynamic Sessions mit eigener Identität).

Kritikalität?

Hoch (siehe Badge im Seitenkopf).

 

Was ist das Problem?

Am 7. Mai 2026 hat Microsoft im hauseigenen Security-Blog zwei Schwachstellen in Semantic Kernel offengelegt, dem Agent-Framework, mit dem das Unternehmen seine .NET- und Python-Welt an die Idee von „Tool-using LLMs" angeschlossen hat. Beide Lücken — CVE-2026-25592 und CVE-2026-26030 — verwandeln eine simple Prompt-Injection in Remote Code Execution auf dem Host. Ein Satz, eine bösartige Eingabe, und die Trennung zwischen Modell-Output und Betriebssystem ist weg.

Das ist keine Randnotiz. Semantic Kernel ist in der Microsoft-Welt für viele Mittelständler der naheliegende Einstieg in Agent-Architekturen — geprägt durch Azure-Bindung, .NET-Vertrautheit, vorhandene Lizenzen. Wer in den letzten zwölf Monaten einen ersten Agenten gegen interne Daten geöffnet hat, betreibt mit hoher Wahrscheinlichkeit eine betroffene Version.

Was Semantic Kernel ist — und warum die zwei Lücken so unangenehm sitzen

Semantic Kernel ist Microsofts Antwort auf LangChain und LlamaIndex: ein Orchestrierungs-Layer, der LLM-Aufrufe, Tool-Plugins und Speicher-Backends in einem Framework zusammenfasst. Entwickler definieren „Kernel-Funktionen", die das Modell aufrufen darf — File-Helper, Datenbank-Abfragen, Suchen über interne Dokumente. Genau diese Plugin-Schicht ist die Bruchstelle.

CVE-2026-25592 trifft die .NET-Linie vor Version 1.71.0. Im SessionsPythonPlugin — der Komponente, mit der Agents Python-Code in Azure-Container-Apps-Sandboxen ausführen lassen — war eine DownloadFileAsync-Hilfsfunktion versehentlich als Modell-aufrufbares Werkzeug exponiert. Ohne robuste Pfad-Validierung. Eine bösartige Anweisung im Prompt-Strom konnte das Modell dazu bewegen, eine Datei an einen frei wählbaren Pfad auf dem Host zu schreiben — inklusive Pfaden, die anschließend automatisch ausgeführt werden.

CVE-2026-26030 trifft die Python-Linie vor Version 1.39.4. Die Bedingung ist enger, aber häufiger als man denkt: Wer den InMemoryVectorStore als Backend für ein Search-Plugin mit dem Standard-Filterverhalten betreibt und über irgendeinen Pfad untrusted Input in den Agent bekommt, hat ein Problem. Der Default-Filter wurde als Python-Lambda gebaut und mit eval() gegen den Suchstring ausgewertet. Ein Prompt, der den Suchstring kontrolliert, kontrolliert den Lambda-Body.

Warum „nur Prompt-Injection" hier nicht trägt

In vielen Architektur-Diagrammen ist die Trennung sauber: Das Modell denkt, das Framework führt aus, der Host bleibt unangetastet. Diese Trennung ist eine Erzählung — sie hält nur so lange, wie alle Werkzeuge, die das Modell aufrufen kann, restriktiv und parameterisiert sind.

Beide Semantic-Kernel-Lücken zeigen denselben Defekt mit unterschiedlichem Gesicht. Bei CVE-2026-25592 wird ein internes Hilfsmittel versehentlich zum Modell-Werkzeug. Bei CVE-2026-26030 wird ein nutzergesteuerter String mit eval() ausgeführt. Beides sind nicht „dumme Bugs" — beides sind direkte Folgen davon, dass Plugin-Architekturen sehr leicht aus Bequemlichkeit zu viel exponieren.

In unserer Beratungspraxis sehen wir das Muster wiederkehrend. Ein Plugin wird gebaut, weil ein konkreter Use-Case es braucht. Drei Wochen später ruft das Modell im Produktivbetrieb diese Funktion in Kombinationen auf, die der Autor nie vorgesehen hat. Das ist nicht „falsche Nutzung" — das ist die Definition eines Agenten.

Was wir konkret empfehlen

Erstens: Wer Semantic Kernel produktiv betreibt, hat heute drei Aufgaben — Versionsstand prüfen (Python ≥ 1.39.4, .NET-SDK ≥ 1.71.0), Plugin-Inventur fahren (welche Kernel-Funktionen sind als Modell-Tools registriert?), und den Vector-Store-Filter härten (vom InMemoryVectorStore mit Default-Filter weg auf durable Stores wie Azure AI Search oder Postgres pgvector).

Zweitens — und das ist die strukturelle Frage hinter beiden CVEs: Eine Sandbox, die im selben Prozess wie der Agent läuft, ist nie eine echte Sandbox. Wir empfehlen seit Monaten dieselbe Linie wie schon im vm2-Block: Code-Ausführung, die aus Modell-Output stammt, gehört in einen separaten Prozess mit hartem Capability-Drop. Wolfi-OS-Container, Firecracker-Microvms, Azure-Container-Apps-Dynamic-Sessions mit eigener Identität.

Drittens — und das ist die unbequeme Wahrheit für viele Vorstände: Diese Lücken werden nicht die letzten dieser Bauart sein. Jedes Plugin-System mit dynamischer Tool-Auswahl und Eval-artigen Pfaden wird sie produzieren. Die Frage ist nicht, ob im nächsten Quartal ein vergleichbarer CVE kommt — die Frage ist, ob die eigene Architektur ihn aushält oder ob er produktiv durchschlägt.

Was wir bewusst nicht empfehlen

Wir empfehlen nicht, jetzt aus Reflex Semantic Kernel zu ersetzen. Das Framework ist nicht „kaputt"; die zwei CVEs sind in den Patches sauber adressiert. Wer sich ohnehin für die Microsoft-Welt entschieden hat — wegen Azure-Integration, .NET-Stack, Compliance-Anschluss — sollte Semantic Kernel weiter einsetzen, aber mit der hier skizzierten Plugin-Disziplin.

Wir empfehlen ebenso wenig, Prompt-Injection mit „besseren System-Prompts" auflösen zu wollen. Microsoft selbst schreibt im Disclosure-Beitrag mit deutscher Klarheit: Prompt-Injection ist eine Klasse, kein einzelner Bug. Solange ein Modell untrusted Input verarbeitet und Tools aufrufen kann, ist die Verteidigung nicht im Modell, sondern in der Tool-Schicht zu führen.

Wer am stärksten betroffen ist

Mittelständische IT-Abteilungen, die in den letzten neun Monaten ein internes Copilot-Pendant auf Semantic Kernel gebaut haben — oft als „Wir wollen unabhängig von Microsoft Copilot bleiben"-Argument. Diese Stacks haben typisch Zugriff auf SharePoint, Exchange-Postfächer, ERP-Daten. Die Lückenkette zwischen Eingabe und Host ist hier exakt die Plugin-Schicht.

Beratungs- und Audit-Häuser, die für Mandanten maßgeschneiderte Agent-Lösungen auf Azure entwickeln und diese als Long-running Agents mit Vector-Store-Backend betreiben. Wer den InMemoryVectorStore aus dem Quickstart übernommen hat — und das ist die Default-Konfiguration der meisten Tutorials — fällt in den engeren Risikokreis von CVE-2026-26030.

SaaS-Anbieter, die Semantic Kernel als Bibliothek in eigenen Agent-Produkten verwenden, ohne dass das im Architektur-Diagramm explizit auftaucht. Wir haben in den letzten Wochen mehrere Reviews gesehen, in denen Semantic Kernel als reine Implementierungs-Detail-Eintragung im requirements.txt versteckt war.

Fazit

Semantic Kernel ist nicht kaputt. Aber die beiden Lücken vom 7. Mai 2026 sind kein Zufall. Sie sind eine direkte Folge der Architektur-Annahme, dass Modell-Output und Host-Code im selben Prozess existieren dürfen, solange das Framework gut genug filtert. Diese Annahme hält nicht — bei keinem Agent-Framework, von keinem Hersteller.

Die Frage lautet nicht, wann der nächste vergleichbare CVE in Semantic Kernel, LangChain oder LlamaIndex erscheint. Sie lautet, ob Sie den nächsten auf einer Architektur erleben, in der Modell-Output durch eine harte Prozess-Grenze von Host-Code getrennt ist — oder auf einer, die wieder einen Patch-Sprint einplant.

Persönlicher Hintergrund und technische Details zur Plugin-Disziplin in Agent-Frameworks: ole-hartwig.eu.

Wer ist betroffen?

Die Reichweite ergibt sich aus dem Bestand der Semantic-Kernel-Installationen — produktiv, in PoCs, als versteckte Bibliotheks-Abhängigkeit. Drei Profile aus unserer Beratungspraxis sind heute akut:

Quer dazu: jeder Stack, der ein eigenes Plugin-System gegen Semantic Kernel gebaut hat — mit Kernel-Funktionen, die Pfad- oder Eval-Operationen ausführen. Die strukturelle Klasse trifft drei Microsoft-Produkte, aber die Architektur-Annahme dahinter (Modell-Output und Host-Code im selben Prozess) trifft auch LangChain, LlamaIndex und Eigenbau-Frameworks.

Mitigation und Sofortmaßnahmen

Die kurze Antwort: Versionsstand härten, Plugin-Inventur fahren, Vector-Store-Filter weg vom eval()-Pfad. Drei Schritte mit Code:

Versionsstand prüfen und härten

# Python
pip show semantic-kernel | grep Version
# Soll: 1.39.4 oder neuer
pip install -U "semantic-kernel>=1.39.4"

# .NET
dotnet list package | grep Microsoft.SemanticKernel
# Soll: 1.71.0 oder neuer
dotnet add package Microsoft.SemanticKernel --version 1.71.0

Plugin-Inventur — welche Kernel-Funktionen sind Modell-Tools?

# Python: alle registrierten Kernel-Funktionen auflisten
from semantic_kernel import Kernel
kernel = Kernel()
# ... plugins importieren ...
for plugin_name, plugin in kernel.plugins.items():
    for func_name, func in plugin.functions.items():
        print(f"{plugin_name}.{func_name}: {func.description}")
        # Prüfen: schreibt diese Funktion Dateien? Führt sie Code aus?
        # Wenn ja: prüfen, ob sie wirklich als Modell-Tool gebraucht wird

Vector-Store vom InMemory-Default wegmigrieren

# Statt InMemoryVectorStore mit Default-Filter:
from semantic_kernel.connectors.memory.in_memory import InMemoryVectorStore  # NICHT mehr

# Auf Azure AI Search wechseln:
from semantic_kernel.connectors.memory.azure_ai_search import AzureAISearchStore
store = AzureAISearchStore(
    search_endpoint="https://<your-search>.search.windows.net",
    api_key=os.environ["AZURE_SEARCH_KEY"],
)

# Oder auf Postgres pgvector:
from semantic_kernel.connectors.memory.postgres import PostgresStore
store = PostgresStore(
    connection_string=os.environ["PG_CONNSTR"],
)

Defense-in-Depth: Sandbox in separatem Prozess

Code-Ausführung, die aus Modell-Output stammt, gehört nicht in den Agent-Prozess. Die belastbare Trennung erfolgt über einen separaten Prozess mit hartem Capability-Drop: Wolfi-OS-Container mit non-root-User und dropped capabilities, Firecracker-MicroVM mit minimalem Kernel-Footprint, oder Azure Container Apps Dynamic Sessions mit eigener Service-Identity (nicht die Agent-Identity).

# Beispiel-Pod-Spec für Wolfi-Agent-Sandbox
apiVersion: v1
kind: Pod
metadata:
  name: semantic-kernel-sandbox
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 65534
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: sandbox
      image: cgr.dev/chainguard/python:latest
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

Detection und Prüfung

Fünf Kernfragen, wenn Semantic Kernel in Ihrem Stack läuft:

• Welche Version ist aktiv?pip show semantic-kernel bzw. dotnet list package. Vor 1.39.4 / 1.71.0 sofort patchen.
• Welche Kernel-Funktionen sind Modell-Tools? Plugin-Liste durchgehen, Funktionen mit Schreib- oder Eval-Pfad als Risiko markieren.
• Welcher Vector-Store?InMemoryVectorStore mit Default-Filter → Eval-Pfad offen → migrieren.
• Welche Eingabequellen? Customer-Chat, Wiki, E-Mail — jede Quelle kann Prompt-Injection tragen.
• Code-Ausführung im Agent-Prozess? Wenn ja: Sandbox-Grenze einführen.

# Semantic-Kernel-Installationen im Stack finden
for venv in $(find /opt -name 'pyvenv.cfg' 2>/dev/null); do
    venv_dir=$(dirname "$venv")
    "$venv_dir/bin/pip" show semantic-kernel 2>/dev/null | grep '^Version'
done
grep -rEn 'semantic[-_]kernel' /opt /srv 2>/dev/null

Betreiberempfehlung

Die Empfehlung hängt vom Setup ab. Vier Szenarien, vier Antworten — mit einem operativen Entscheidungsraster vorab:

Entscheidungsraster: Wann jetzt mitigieren, wann Wartungsfenster?

• Sofort mitigieren, wenn der Agent untrusted Eingaben verarbeitet (Customer-Chat, Wiki-Inhalte, E-Mail) und Tools mit Schreib- oder Eval-Pfad aufrufen darf.
• Wartungsfenster möglich, wenn der Agent nur in einer rein internen Test-Umgebung läuft und der Plugin-Bestand auf Read-Only-Funktionen eingegrenzt ist.
• InMemoryVectorStore in Produktion? Immer sofort — Default-Filter ist eval() auf nutzergesteuertem String.
• SaaS-Anbieter mit Library-Dependency? Patch im nächsten Release plus Customer-Notice, weil downstream Kunden gepinnt sein können.

Mittelstand mit Semantic-Kernel-Agent

Versionsstand auf 1.39.4 (Python) oder 1.71.0 (.NET). Plugin-Inventur in zwei Stunden. Vector-Store-Migration weg vom InMemory-Default im nächsten Sprint. Wer aus Quickstart kopiert hat: prüfen, ob der InMemoryVectorStore noch im Code steht.

Enterprise mit eigener Agent-Plattform

Plugin-Allowlist-Disziplin: jede Kernel-Funktion mit Schreib-/Eval-Pfad braucht ein eigenes Architektur-Review vor der Modell-Exposition. Vector-Store auf Azure AI Search oder pgvector mit echter Filter-Syntax statt Lambda-Eval. Sandbox-Grenze in separatem Prozess für alle Code-Ausführung aus Modell-Output.

Beratungshäuser mit Mandanten-Agents

Pro Mandant einen Plugin-Audit-Bericht, mit konkretem Versions- und Konfigurations-Stand. Standard-Verfahren: Quickstart-Defaults aus dem Code, Vector-Store-Migration in den Mandanten-Sprint, Mandanten-Notice mit dokumentierter Sandbox-Grenze.

SaaS-Anbieter mit Semantic Kernel als Bibliothek

Patch in der nächsten Release-Welle. Plus: explizite Customer-Notice, weil downstream-Kunden ggf. ihre eigenen Pins halten. Aufnahme in den SBOM-Bericht mit klarer Versionsangabe.

Was wir konkret getan haben

Nach der Microsoft-Disclosure am 7. Mai haben wir den eigenen Stack und alle Mandanten-Stacks mit Agent-Architektur durchgeprüft — derselbe Pattern wie bei vm2 und Comment-and-Control:

• Inventur am 7. Mai abends.pip show semantic-kernel und dotnet list package über alle Mandanten-Repositories. Ergebnis: 9 Repos mit aktiver Semantic-Kernel-Dependency, davon 6 in Python und 3 in .NET. 4 vor Patch-Version.
• Plugin-Inventur am 8. Mai. Pro Repo die @kernel_function-Dekorationen gelesen. 2 Repos mit Datei-Schreib-Tool im Modell-Werkzeugkasten, 1 Repo mit SessionsPythonPlugin-Aufruf. Diese als „heute morgen patchen“ markiert.
• Vector-Store-Audit am 8. Mai. 3 Repos mit InMemoryVectorStore aus Quickstart-Default. Migration auf Azure AI Search bzw. pgvector als Sprint-Aufgabe eingeplant.
• Patch-Welle am 8.–9. Mai. Alle 4 Pre-Patch-Repos auf 1.39.4 / 1.71.0 gezogen, Tests gefahren, deployed.
• Sandbox-Grenze-Audit am 9. Mai. Bei 2 Mandanten läuft Code-Ausführung aus Modell-Output noch im Agent-Prozess. Diese als Architektur-Aufgabe für die nächsten zwei Sprints priorisiert.
• Was wir bewusst nicht gemacht haben. Keine Semantic-Kernel-Ersetzung durch LangChain oder LlamaIndex — die Architektur-Annahme (Modell-Output und Host-Code im gleichen Prozess) trifft alle drei. Kein „System-Prompt härten“, weil OWASP-LLM01 das strukturell als nicht lösbar markiert.

Diese Routine ist die operative Praxis aus DevSecOps as a Service und der Externen IT-Abteilung. Methodisch hängt Semantic Kernel im selben Geflecht wie Comment-and-Control und vm2: KI-Agenten-Architektur ist eine Workflow-Frage, keine Modell-Frage.

Technischer Deep Dive

Beide CVEs sitzen in der Plugin-Architektur von Semantic Kernel — einer Schicht, die LLM-Aufrufe, Tool-Plugins und Speicher-Backends in einem Framework bündelt. Dort sind die strukturellen Bruchstellen:

CVE-2026-25592: SessionsPythonPlugin (.NET, vor 1.71.0)

Das SessionsPythonPlugin ist die Komponente, mit der Agents Python-Code in Azure-Container-Apps-Dynamic-Sessions ausführen lassen. Im Plugin war eine DownloadFileAsync-Hilfsfunktion als Modell-Tool registriert — ohne robuste Pfad-Validierung. Ein Modell mit Prompt-Injection im Eingabe-Strom konnte das Tool aufrufen und eine Datei an einen beliebigen Pfad auf dem Host schreiben, einschließlich autostart- oder cron-Pfaden, die anschließend automatisch ausgeführt werden.

Microsoft-Patch in 1.71.0: DownloadFileAsync nicht mehr als Modell-Tool exponiert, Pfad-Validierung gegen einen erlaubten Working-Directory-Präfix erzwungen.

CVE-2026-26030: InMemoryVectorStore Default-Filter (Python, vor 1.39.4)

Der InMemoryVectorStore ist der Quickstart-Default — ein In-Memory-Backend für Vector-Search ohne externe Abhängigkeit. Der Default-Filter für Such-Queries wurde als Python-Lambda gebaut und mit eval() gegen den Suchstring ausgewertet. Ein Prompt, der den Suchstring kontrolliert, kontrolliert damit den Lambda-Body und führt beliebigen Python-Code im Agent-Prozess aus.

Microsoft-Patch in 1.39.4: Default-Filter auf ein parameterisiertes Predicate-Modell umgestellt, eval() entfernt.

Aspekte für die Bewertung

• OWASP-LLM01 als Lehrbuch-Fall. Untrusted Input + Tool-Aufruf = die Klasse — dokumentierter Stand der Technik seit 2024.
• Plugin-Inkonsistenz im Default. Bei beiden Lücken trifft die Schwachstelle nur, wenn man Quickstart-Defaults übernimmt. Wer eine eigene Plugin-Disziplin hat, ist nicht oder weniger betroffen. Das ist die Asymmetrie zwischen „aus dem Tutorial kopiert“ und „eigene Architektur durchdacht“.
• Cross-Anbieter-Muster. Microsoft hat den Patch sauber dokumentiert — LangChain und LlamaIndex haben in den letzten Monaten vergleichbare Architektur-Schwachstellen gezeigt. Die strukturelle Klasse ist nicht microsoft-spezifisch.
• Sandbox-Annahme. Eine Sandbox, die im selben Prozess wie der Agent läuft, ist keine Sandbox. Echte Trennung braucht einen separaten Prozess mit hartem Capability-Drop — Wolfi-OS-Container, Firecracker, Azure-Container-Apps-Dynamic-Sessions mit eigener Identität.

Fazit

Semantic Kernel ist nicht kaputt. Aber die beiden Lücken vom 7. Mai 2026 sind kein Zufall — sie sind direkte Folge der Architektur-Annahme, dass Modell-Output und Host-Code im selben Prozess existieren dürfen, solange das Framework gut genug filtert. Diese Annahme hält nicht, bei keinem Agent-Framework.

Operativ wichtiger als die Einzel-CVEs ist das Muster dahinter: jedes Plugin-System mit dynamischer Tool-Auswahl und Eval-artigen Pfaden produziert diese Klasse von Lücken. Wer Plugin-Allowlist-Disziplin, Vector-Store-Migration weg vom In-Process-Eval, und Sandbox-Grenze als separater Prozess durchgezogen hat, beantwortet die nächste vergleichbare Disclosure in Stunden, nicht in einem Patch-Sprint.

Realistische Risiko-Einordnung: Hoch für Mittelständler mit internem Copilot-Pendant auf Semantic Kernel und produktivem Modell-Tool-Zugriff. Mittel für Stacks mit klarem Plugin-Inventory und Vector-Store auf durable Backend. Niedrig für Setups, die Code-Ausführung aus Modell-Output konsequent in separaten Prozess auslagern. Die Frage lautet nicht, wann der nächste vergleichbare CVE in Semantic Kernel, LangChain oder LlamaIndex erscheint. Sie lautet, ob Sie den nächsten auf einer Architektur erleben, in der Modell-Output durch eine harte Prozess-Grenze von Host-Code getrennt ist.