Omnigent CVE-2026-62674: Kritische Rechteprüfung erlaubt Command Execution in Sessions

Kurzfassung

In Omnigent steckt eine kritische Schwachstelle unter der Kennung CVE-2026-62674. Betroffen sind Versionen vor 0.3.0. Wer eine Session bearbeiten darf, kann unter bestimmten Bedingungen ein geteiltes Agenten-Bundle austauschen und so späteren Sitzungen einen fremdgesteuerten Befehl unterschieben. Der Angriff läuft über den Omnigent-Runner und kann Dateien, Zugangsdaten, Workspace-Inhalte und interne Dienste offenlegen.

Für Unternehmen mit Einsatz solcher Agenten-Frameworks ist das kein theoretisches Problem. Die Lücke sitzt genau an der Stelle, an der Rechte, Wiederverwendung und Automatisierung aufeinandertreffen. Das ist der Teil der Architektur, der in der Praxis oft zu wenig geprüft wird.

Was ist passiert?

Omnigent ist ein Open-Source-Framework zum Orchestrieren von Coding-Agents. In den Versionen vor 0.3.0 prüft der Server zwar, ob ein Nutzer eine Session bearbeiten darf. Er lehnt aber einen gebundenen Shared- oder Template-Agenten mit leerer session_id nicht sauber ab.

Genau daraus entsteht der Angriffspfad. Ein authentifizierter Nutzer mit Edit-Rechten auf eine Session kann das geteilte Agentenpaket ersetzen, einen eigenen stdio-MCP-Server hinterlegen und späteren Sessions einen Befehl mitgeben, den der Runner ausführt. Das betrifft also keine anonyme Fernlücke, sondern einen Missbrauch mit vorhandenen Rechten. In Umgebungen mit mehreren Teammitgliedern oder Self-Service-Workflows ist das dennoch ernst zu nehmen.

Technische Details

Die Schwachstelle liegt in der Zugriffskontrolle rund um PUT /sessions/{session_id}/agent. Die Anwendung prüft zwar LEVEL_EDIT für die Session, trennt aber nicht sauber zwischen direkt gebundenen Agenten und Shared- beziehungsweise Template-Agenten, wenn deren agent.session_id auf None steht.

Damit kann ein berechtigter Nutzer ein bestehendes, gemeinsam genutztes Agenten-Bundle austauschen. Wird anschließend ein stdio-MCP-Server eingebunden, kann der manipulierte Agent bei späteren Ausführungen einen attacker-kontrollierten Befehl auslösen. Der Befehl läuft mit den Rechten des Omnigent-Runner-Prozesses. Laut Herstellerbeschreibung kann das zum Abfluss von Dateien, Credentials, Workspace-Daten, internen Diensten und auch zur Beeinträchtigung der Runner-Verfügbarkeit führen.

Die NVD bewertet den Fehler als kritisch. Einen CVSS-Wert nennt der vorliegende Auszug nicht. Ob alle Deployments gleichermaßen betroffen sind, hängt davon ab, ob Omnigent in dieser Form produktiv eingesetzt wird und ob Shared Agents oder Template-Workflows aktiv sind.

Wer ist betroffen?

Direkt betroffen sind Instanzen von Omnigent vor Version 0.3.0. Relevant wird das vor allem dort, wo mehrere Nutzer Sessions bearbeiten dürfen oder wo Agenten wiederverwendet und zentral verwaltet werden. Das ist für Entwicklerplattformen, interne KI-Workflows und Laborumgebungen realistischer als für klassische Einzelplatz-Nutzung.

Für Unternehmen im DACH-Raum heißt das: Wer Omnigent testet oder bereits produktiv nutzt, sollte die eigene Berechtigungslogik und den Einsatz von Shared Agents sofort prüfen. Besonders heikel ist das in Teams mit breiten Edit-Rechten, weil hier kein klassischer Exploit von außen nötig ist. Ein kompromittiertes oder überprivilegiertes Benutzerkonto reicht aus.

Ob auch abgeleitete Distributionen, interne Forks oder Container-Images mit älterem Code betroffen sind, lässt die Quelle offen. Wer Omnigent selbst baut oder als Helm-Chart, Docker-Image oder über ein internes Paket-Repository ausrollt, muss die eigene Version separat verifizieren.

Empfohlene Maßnahmen

Die wichtigste Maßnahme ist klar: auf Version 0.3.0 oder höher aktualisieren. Das schließt die Lücke laut Hersteller. Wer den Patch nicht sofort ausrollen kann, sollte den Einsatz von Shared- und Template-Agents vorübergehend einschränken oder ganz stoppen.

Admins sollten außerdem die Rechte auf Sessions nachschärfen. Edit-Rechte gehören nur an Nutzer, die sie wirklich brauchen. Prüfen Sie zusätzlich, ob unnötige MCP-Server eingebunden sind, und entfernen Sie Konfigurationen, die nicht zwingend erforderlich sind. In produktiven Umgebungen lohnt sich ein Blick in die Logs auf Änderungen an Sessions, Agent-Bundles und MCP-Anbindungen.

Wenn Omnigent in sensiblen Netzen läuft, empfiehlt sich eine vorübergehende Isolierung des Runner-Systems. Denn selbst wenn der Fehler auf Anwendungsebene sitzt, landet die Ausführung am Ende im Prozesskontext des Runners. Das ist der Punkt, an dem aus einer Berechtigungsfrage ein echtes Betriebsrisiko wird.

Einschätzung von CyberSecurity-News.de

Die Schwachstelle ist technisch unschön und praktisch relevant. Sie zeigt ein Muster, das wir bei KI-Orchestrierungsplattformen häufiger sehen: Rechte werden auf dem Papier geprüft, aber bei wiederverwendeten Ressourcen nicht konsequent genug durchgezogen. Genau dort entstehen in der Praxis die härtesten Fehler.

Für die meisten Leser ist das kein Massenproblem wie eine breit ausgenutzte Internetlücke in einem VPN-Gateway. Wer Omnigent aber im Team oder produktiv einsetzt, sollte das Thema zügig anfassen. Besonders unangenehm ist, dass bereits legitime Zugriffsrechte missbraucht werden können. Das macht Erkennung und Abwehr deutlich schwerer als bei einem externen Exploit.

Die Informationslage ist ausreichend für eine klare Priorität: patchen, Rechte prüfen, Shared Agents kontrollieren. Mehr braucht es im Moment nicht, aber eben auch nicht weniger.

Fazit

CVE-2026-62674 in Omnigent ist eine kritische Schwachstelle mit realem Missbrauchspotenzial. Ein Nutzer mit Edit-Rechten kann über geteilte Agenten und MCP-Anbindungen attacker-kontrollierte Befehle in späteren Sessions auslösen. Betroffen sind Versionen vor 0.3.0.

Wer Omnigent einsetzt, sollte jetzt auf die korrigierte Version gehen und die Berechtigungen rund um Sessions und Agenten enger ziehen. Ohne diese Nacharbeit bleibt die eigentliche Ursache zwar gepatcht, das Betriebsrisiko aber unnötig hoch.