Schwere Sicherheitslücke in Googles Gemini‑Architektur: Was die neue MoE‑Schwachstelle für Unternehmen bedeutet

Die am 26. Dezember 2025 veröffentlichte Arbeit eines KAIST‑Forschungsteams legt eine gravierende Schwachstelle in Mixture‑of‑Experts‑(MoE‑)Architekturen offen, wie sie unter anderem in Googles Gemini‑Modellen eingesetzt werden. Die Forscher zeigen, dass bereits ein einziges bösartig präpariertes Experten‑Modul ausreicht, um Sicherheitsfilter weitgehend zu umgehen und den Anteil schädlicher Antworten sprunghaft zu erhöhen – ohne dass Leistung oder Stabilität des Modells merklich leiden.

Für Unternehmen, die Gemini einsetzen oder eigene MoE‑Modelle entwickeln, ist dies kein theoretisches Detail, sondern ein akutes Supply‑Chain‑ und Compliance‑Thema. Der Vorfall zwingt dazu, Bedrohungsmodelle für LLM‑Infrastrukturen zu überarbeiten und die Herkunft einzelner Expertenmodelle sowie Fine‑Tuning‑Prozesse deutlich strenger zu kontrollieren.

Kontext: Was haben die KAIST‑Forscher herausgefunden?

Mixture‑of‑Experts kurz eingeordnet

Mixture‑of‑Experts‑Modelle kombinieren viele spezialisierte „Expertennetze“, von denen pro Eingabe nur ein kleiner Teil aktiv wird. Ein Router entscheidet, welche Token an welche Experten geleitet werden. Damit lassen sich große Kapazitäten bei moderaten Rechenkosten realisieren – ein zentrales Designprinzip von Gemini und anderen modernen LLMs.

Anstelle eines monolithischen Modells existiert damit eine modulare Struktur mit hunderten oder tausenden Experten, die prinzipiell austauschbar und wiederverwendbar sind. Genau diese Modularität eröffnet neue Angriffsflächen.

Kernergebnisse der KAIST‑Studie

Das KAIST‑Team um die Professoren Shin Seung‑won und Son Sooel hat eine Angriffsklasse beschrieben, bei der ein einzelner manipulierte Experte genügen kann, um die Sicherheit eines gesamten MoE‑LLM massiv zu untergraben:

• Ein einziger „malicious expert“ reicht aus: Wird ein bösartiger Experte in eine ansonsten legitime Expertenmenge integriert, kann er – bei passenden Trigger‑Themen oder ‑Mustern – immer wieder ausgewählt werden.

• Sprung von 0 % auf bis zu 80 % schädliche Antworten: In den Experimenten stieg die Rate gefährlicher oder verbotener Ausgaben von praktisch null auf bis zu rund 80 %, sobald der bösartige Experte zum Zug kam.

• Keine auffälligen Performance‑Einbußen: Für normale Benchmarks und Standard‑Use‑Cases verhält sich das Modell weitgehend unauffällig. Genau das erschwert die Erkennung im regulären Testprozess.

• Angriff über die Lieferkette: Der Angreifer muss nicht die komplette Modellinfrastruktur kompromittieren. Es genügt, ein Expert‑Modul als (scheinbar) nützliches Open‑Source‑Artefakt oder vortrainierten Baustein in Umlauf zu bringen, der dann in größeren MoE‑Systemen wiederverwendet wird.

Der Angriff zielt also nicht auf das Gesamtsystem, sondern auf ein einzelnes Bauteil. Für eine Architektur, die zwangsläufig auf Komposition von Experten setzt, ist das ein strukturelles Risiko.

Einordnung im Kontext bestehender MoE‑Forschung

Bereits frühere Arbeiten hatten auf spezifische MoE‑Risiken hingewiesen, etwa:

• Batch‑Überlauf und Routing‑Manipulation (z. B. Arbeiten zu „Buffer Overflow in Mixture of Experts“): Bösartige Anfragen können die Auslastung bestimmter Experten so verändern, dass harmlose Anfragen schlechtere oder inkorrekte Antworten erhalten.

• Positional Vulnerability und Safety‑kritische Experten: Neuere Studien wie SAFEx zeigen, dass Sicherheitsverhalten bei MoE‑LLMs häufig auf wenigen Experten konzentriert ist. Werden diese deaktiviert oder umgangen, verschlechtert sich die Sicherheitslage stark.

• Drift der Routing‑Gewichte durch Fine‑Tuning: Arbeiten wie SafeMoE verdeutlichen, dass scheinbar harmloses Fine‑Tuning dazu führen kann, dass schädliche Eingaben nicht mehr zu „Sicherheits‑Experten“ geroutet werden, sondern zu generativen Experten.

Die KAIST‑Arbeit bringt nun eine weitere Dimension hinzu: Nicht nur das Routing selbst, sondern bereits ein kompromittierter Experte kann in einer ansonsten vertrauenswürdigen MoE‑Architektur als Einfallstor dienen.

Detaillierte Analyse: Risiken, Angriffsvektoren und Chancen

1. Neue Angriffsoberfläche für AI‑Supply‑Chain‑Attacken

In klassischen LLM‑Setups konzentriert sich der Fokus von Sicherheitsaudits auf das Gesamtmodell und dessen APIs. Bei MoE‑Systemen verschiebt sich die Perspektive:

• Feingranulare Komponenten: Expertenmodule können von unterschiedlichen Teams, Organisationen oder Open‑Source‑Communities entwickelt werden.

• Wiederverwendung und Komposition: Ein Experte, der ursprünglich für ein Nischenprojekt entwickelt wurde, taucht später in einem großskaligen System wieder auf – oftmals ohne gründliche Re‑Evaluation.

• Geringe Sichtbarkeit einzelner Experten: Viele Plattformen dokumentieren nicht transparent, aus welchen konkreten Experten sich ein bereitgestelltes Modell zusammensetzt.

Damit entsteht ein klassisches Supply‑Chain‑Risiko, das aus der Software‑Welt bekannt ist (kompromittierte Libraries, Container‑Images etc.), aber nun auf die Modellebene übertragen wird.

2. Täuschend „normales“ Modellverhalten

Die größte Gefahr besteht darin, dass ein kompromittiertes MoE‑System unter Standardbedingungen völlig normal wirkt:

• Benchmarks zur Sprachqualität und zu gängigen Aufgaben bleiben unverändert.

• Übliche Red‑Teaming‑Szenarien greifen zu kurz, weil die Triggerbedingungen des bösartigen Experten nicht getroffen werden.

• Monitoring auf Latenz, Fehlerraten oder Auslastung liefert keine eindeutigen Hinweise.

Das macht die Schwachstelle operativ heimtückisch: Unternehmen glauben, ein sicheres, zertifiziertes Modell einzusetzen, während bestimmte Nutzergruppen (z. B. Angreifer, Insider oder besonders informierte Dritte) den versteckten Experten gezielt aktivieren können.

3. Konkrete Bedrohungsszenarien für Unternehmen

#### Szenario A: Unterlaufen von Safety‑Policies

Ein Konzern nutzt Gemini‑basierte Dienste zur internen Wissenssuche und für Entwickler‑Assistenz. Ein Angreifer kennt die Trigger für den bösartigen Experten und kann damit Inhalte generieren, die:

• Unternehmensrichtlinien zur Sprache und Compliance verletzen,

• klassifizierte oder sensible Informationen aus Trainingsdaten verstärkt hervorbringen,

• gefährliche Handlungsanweisungen (z. B. für Malware, Angriffe auf OT‑Systeme) trotz Safety‑Policies liefern.

Die Organisation steht dann vor der Frage, ob sie ihre eigenen Governance‑Vorgaben noch erfüllt und welche Haftungsrisiken entstehen, wenn Mitarbeitende solche Inhalte nutzen.

#### Szenario B: Reputationsschäden über Kunden‑Facing‑Anwendungen

Ein SaaS‑Anbieter integriert Gemini‑Funktionen in sein Produkt (z. B. Chat‑Assistent auf der Website). Wenn Angreifer oder findige Nutzer den bösartigen Experten aktivieren, können plötzlich:

• diskriminierende oder beleidigende Antworten,

• rechtlich bedenkliche Empfehlungen,

• Marken‑ oder Urheberrechtsverletzungen

ausgegeben werden. Selbst wenn dies nur bei bestimmten Prompt‑Mustern geschieht, reichen Screenshots solcher Antworten für nachhaltige Reputationsschäden und mögliche regulatorische Prüfungen.

#### Szenario C: Compliance‑Verstöße bei sensiblen Branchen

Im Finanz‑ oder Gesundheitssektor gelten strenge aufsichtsrechtliche Vorgaben zu Kontrollierbarkeit und Nachvollziehbarkeit von Algorithmen. Wenn eine Aufsicht fragt, ob Sicherheitsmechanismen zuverlässig sind, genügt die Antwort „wir nutzen einen großen Provider mit Safety‑Layern“ nicht mehr.

Eine Architektur, in der ein unentdeckter bösartiger Experte Sicherheitsverhalten selektiv aushebelt, kann als mangelnde organisatorische und technische Kontrolle interpretiert werden – mit entsprechendem Risiko für Bußgelder oder Auflagen.

4. Chancen: MoE als Hebel für bessere Sicherheitsarchitekturen

Die neue Schwachstelle bedeutet nicht, dass MoE‑Modelle grundsätzlich unsicher wären. Im Gegenteil: Die modularen Eigenschaften eröffnen auch neue Verteidigungsansätze, wenn sie bewusst genutzt werden:

• Explizite Sicherheits‑Experten: Bestimmte Experten können ausschließlich für Moderation, Erkennung von Missbrauch oder Datenschutz‑Filter vorgesehen und entsprechend gehärtet werden.

• Isolierte Ausbildungs‑ und Prüfpfade: Experten lassen sich separat trainieren, testen und zertifizieren – inklusive formaler Signierung und Supply‑Chain‑Überwachung.

• Routing‑Audits und Invarianten: Mit Verfahren wie SafeMoE oder SAFEx‑ähnlichen Ansätzen lassen sich sicherheitskritische Experten identifizieren und deren Auswahlverhalten unter Veränderungen (Fine‑Tuning, neue Experten) überwachen.

Voraussetzung ist jedoch, dass Anbieter und Integratoren MoE nicht nur als Performance‑Optimierung, sondern als Sicherheits‑kritische Systemarchitektur behandeln.

Praktische Implikationen und Beispiele aus der Unternehmenspraxis

Interne LLM‑Plattformen und AI‑Hubs

Viele Konzerne bauen interne AI‑Plattformen, auf denen Teams Modelle, Prompts und Fine‑Tunings teilen. In einem MoE‑Setup bedeutet das:

• Teams könnten eigene Expertenmodule entwickeln und in den gemeinsamen Pool einstellen.

• Andere Teams nutzen diese Experten ohne tiefen Einblick in deren Trainingsdaten oder Safety‑Eigenschaften.

Risiko: Ein böswilliger oder nachlässiger Beitrag (z. B. ein Experte mit fragwürdigen Trainingsdaten oder versteckten Triggern) kann unbemerkt in unternehmenskritische Anwendungen wandern.

Gegenmaßnahmen:

• Pflicht zur Registrierung jedes Experten mit Metadaten (Zweck, Trainingsdatenquellen, Verantwortliche).

• Security‑Gate vor Freigabe in die gemeinsame Plattform: automatisierte Tests plus manuelle Prüfung für sicherheitskritische Domänen.

• Isolierte Testumgebungen, in denen Experten adversarial getestet werden, bevor sie mit Produktiv‑Routern kombiniert werden.

Externe Gemini‑Integration über APIs

Unternehmen, die Gemini‑Funktionalität über APIs einbinden, haben naturgemäß weniger Kontrolle über die interne Expertentopologie. Trotzdem lässt sich das Risiko reduzieren:

• Segmentierung nach Anwendungsfällen: Hochsensible Anwendungsfälle (z. B. HR, Legal, Regulatorik) werden von weniger sensiblen (z. B. interne Wissenssuche) getrennt, ggf. mit unterschiedlichen Providern.

• Prompt‑Policies und Guardrails vor dem Modell: Eingaben werden vorab gefiltert und normalisiert, um offensichtliche Trigger oder böswillige Experimente zu reduzieren.

• Ausgabe‑Filtration hinter dem Modell: Kritische Antworten (bestimmte Schlagwörter, Kategorien) werden zusätzlich durch regelbasierte oder alternative Modelle geprüft.

Fine‑Tuning und Anpassungen bestehender MoE‑Modelle

Viele Organisationen planen oder betreiben Fine‑Tuning auf MoE‑Basismodellen. Die KAIST‑Ergebnisse sowie Arbeiten zu SafeMoE legen nahe:

• Fine‑Tuning kann Routing‑Entscheidungen verschieben und Safety‑Verhalten unbeabsichtigt schwächen.

• Ein bösartiger Experte könnte gezielt so trainiert werden, dass er nach Fine‑Tuning häufiger ausgewählt wird.

Empfehlungen:

• Differenzielle Logging‑Analyse: Vor und nach Fine‑Tuning müssen Routing‑Statistiken und Sicherheitsmetriken verglichen werden.

• Begrenzte Lernrate und Zielräume für sicherheitskritische Experten: Sicherheits‑Experten dürfen nur unter strengen Kontrollen angepasst werden.

• Safe‑Fine‑Tuning‑Methoden nutzen, die explizit darauf abzielen, Sicherheits‑Routing beizubehalten.

Geschäftliche Relevanz: Was Unternehmen jetzt konkret tun sollten

1. Bedrohungsmodell für LLM‑Infrastruktur aktualisieren

CISOs und Security‑Architekten sollten MoE‑Architekturen explizit in ihre Modelle aufnehmen:

• Neuer Angreifer‑Typ: „Model Supply‑Chain Angreifer“, der versucht, Expertenmodule in interne oder externe MoE‑Systeme einzuschleusen.

• Asset‑Definition: Expertenmodule, Router‑Konfigurationen und Fine‑Tuning‑Pipelines als schützenswerte Assets.

• Angriffsziele: Umgehung von Safety‑Policies, Datenexfiltration aus Trainingsdaten, Reputationsschäden.

2. Governance und Prozesse für Expertenmodule etablieren

Unternehmen mit eigenen Modellen sollten Richtlinien formulieren wie:

• Zulassungskriterien für neue Experten (Trainingsdatenanforderungen, Dokumentation, Review‑Pflichten).

• Versions‑ und Herkunftsnachweis: Jeder Experte braucht eine eindeutige Herkunft (internes Team, externer Partner, Open‑Source‑Projekt) und eine Versionierung.

• Verpflichtende Sicherheits‑ und Bias‑Tests: Nicht nur Leistungs‑KPIs, sondern auch Sicherheitskennzahlen fließen in die Freigabe ein.

3. Vertrags- und Beschaffungsanforderungen an Provider nachschärfen

Bei der Nutzung von Gemini und anderen MoE‑basierten Diensten sollten Einkaufs‑ und Rechtsabteilungen gemeinsam mit der IT Sicherheitsanforderungen formulieren:

• Transparenz über Modellarchitektur und Update‑Prozesse (zumindest auf abstrakter Ebene).

• Verpflichtung zu Security‑Audits für Expertenmodule und zu Reaktionsplänen bei entdeckten Schwachstellen.

• Benachrichtigungs‑ und Patch‑Fristen, wenn kritische Sicherheitslücken – wie jetzt die MoE‑Schwachstelle – publik werden.

4. Monitoring, Logging und Incident‑Response anpassen

• Protokollierung von Prompt‑Muster und Ausgaben, insbesondere dort, wo mit sensiblen Inhalten gearbeitet wird.

• Einrichtung von Detektionsmechanismen für ungewöhnliche Antwortmuster (plötzlicher Anstieg riskanter Inhalte bei bestimmten Nutzern, Themen oder Zeiträumen).

• Playbooks für AI‑Incidents: Vorgehen bei Verdacht auf Modellkompromittierung, inkl. Abschaltung, Fallback‑Modell und interner/externer Kommunikation.

5. Schulung von Entwicklern und Data‑Science‑Teams

MoE‑Sicherheitsrisiken sind bislang selten Teil klassischer AI‑Schulungen. Organisationen sollten sicherstellen, dass:

• Entwickler die Unterschiede zwischen monolithischen und MoE‑Modellen verstehen.

• Data Scientists wissen, wie sie Routing‑Statistiken und Expertennutzung interpretieren.

• Teams sensibilisiert sind, keine unvalidierten Expertenmodule unkritisch zu übernehmen.

Fazit: MoE‑Leistungsgewinne erfordern Security‑Reife

Die von KAIST offengelegte Schwachstelle in der Mixture‑of‑Experts‑Architektur macht deutlich: Skalierbarkeit und Effizienz moderner LLMs haben ihren Preis in Form neuer, komplexer Angriffsflächen. Für Unternehmen reicht es nicht mehr aus, sich auf allgemeine „AI‑Safety“‑Versprechen von Anbietern zu verlassen. Gefragt sind konkrete Fragen nach Expertenmodulen, Routing‑Mechanismen und Supply‑Chain‑Kontrollen.

Wer frühzeitig Governance, technische Kontrollen und passende Vertragsklauseln etabliert, kann die Vorteile von Gemini und anderen MoE‑Modellen nutzen, ohne die eigene Sicherheits- und Compliance‑Position zu kompromittieren.

Zentrale Takeaways für Entscheidungsträger:

• Ein einzelnes kompromittiertes Expertenmodul kann in MoE‑Systemen wie Gemini Sicherheitsmechanismen weitgehend aushebeln, ohne klassische Tests zu triggern.

• MoE‑Modelle verschieben Sicherheitsfragen von einer monolithischen Modellprüfung hin zu fein granularer Kontrolle von Experten, Routing und Fine‑Tuning‑Pipelines.

• Unternehmen müssen ihr LLM‑Bedrohungsmodell um „Model Supply‑Chain“-Angriffe und bösartige Experten erweitern.

• Governance‑Regeln für Entwicklung, Freigabe und Einsatz einzelner Expertenmodule sind zwingend notwendig – insbesondere in regulierten Branchen.

• Bei externen MoE‑Services sollten Transparenz, Auditierung und Reaktionszeiten für Sicherheitslücken vertraglich fixiert werden.

• Wer jetzt in Monitoring, Testing und Schulung für MoE‑Sicherheit investiert, stärkt nicht nur die Resilienz seiner AI‑Systeme, sondern auch seine regulatorische und reputative Robustheit.

Häufig gestellte Fragen (FAQ)

Was ist die von KAIST entdeckte MoE‑Schwachstelle in Googles Gemini-Architektur?

Die KAIST-Forscher haben gezeigt, dass in Mixture-of-Experts-Modellen bereits ein einziges bösartiges Expertenmodul ausreicht, um Sicherheitsmechanismen weitgehend zu umgehen. Dadurch kann der Anteil schädlicher Antworten sprunghaft ansteigen, während das Modell in Standardtests weiterhin normal und performant wirkt.

Wie funktioniert der Angriff über einen „malicious expert“ in MoE-Modellen wie Gemini?

In MoE-Modellen entscheidet ein Router, welche Experten für bestimmte Eingaben aktiviert werden. Wird ein gezielt manipuliertes Expertenmodul integriert, kann es bei bestimmten Trigger-Themen oder -Mustern wiederholt ausgewählt werden und dann Sicherheitsfilter umgehen, ohne das restliche System sichtbar zu beeinträchtigen.

Welche Auswirkungen hat die MoE-Schwachstelle auf Unternehmen, die Gemini oder ähnliche LLMs nutzen?

Unternehmen riskieren, dass interne und externe Anwendungen trotz vermeintlicher Safety-Layer schädliche, diskriminierende oder rechtlich problematische Inhalte ausgeben. Besonders kritisch ist dies in regulierten Branchen, da Aufsichtsbehörden mangelnde technische und organisatorische Kontrolle über die Modellkomponenten als Compliance-Verstoß werten können.

Worin besteht der Unterschied zwischen monolithischen LLMs und MoE-Modellen im Hinblick auf Sicherheit?

Monolithische LLMs werden als ein einziges Modell betrachtet, während MoE-Modelle aus vielen Expertenmodulen bestehen, die dynamisch kombiniert werden. Dadurch verschiebt sich die Sicherheitsperspektive: Statt nur das Gesamtmodell zu prüfen, müssen bei MoE-Systemen einzelne Experten, das Routing und Fine-Tuning-Pipelines als eigenständige Angriffs- und Kontrollpunkte betrachtet werden.

Welche konkreten Bedrohungsszenarien ergeben sich durch die MoE-Schwachstelle für Unternehmen?

Mögliche Szenarien reichen vom gezielten Unterlaufen interner Safety-Policies über Reputationsschäden durch problematische Antworten in Kundenanwendungen bis hin zu aufsichtsrechtlichen Problemen in sensiblen Sektoren wie Finanz- oder Gesundheitswesen. In allen Fällen können Angreifer versteckte Trigger nutzen, um schädliche Ausgaben zu erzwingen, während das System im Normalbetrieb unauffällig bleibt.

Was sollten CISOs und CTOs jetzt tun, um Gemini- und MoE-Risiken zu reduzieren?

Führungskräfte sollten ihr Bedrohungsmodell um Model-Supply-Chain-Angriffe erweitern, Governance-Regeln für Expertenmodule definieren und strengere Freigabeprozesse einführen. Dazu gehören die Registrierung und Prüfung jedes Experten, differenzielle Tests nach Fine-Tuning, angepasstes Monitoring sowie vertragliche Anforderungen an Provider hinsichtlich Transparenz, Audits und Reaktionszeiten bei Sicherheitslücken.

Wie können Unternehmen MoE-Architekturen trotz der Schwachstelle sicher nutzen?

MoE kann sogar ein Hebel für bessere Sicherheit sein, wenn Organisationen explizite Sicherheits-Experten definieren, diese isoliert trainieren und zertifizieren und Routing-Audits etablieren. In Kombination mit strengen Supply-Chain-Kontrollen, Guardrails vor und hinter dem Modell und Schulungen für Entwickler lassen sich Leistungsgewinne von MoE nutzen, ohne die Sicherheits- und Compliance-Position zu gefährden.