0x0oz/cve-2026-7482-pocProof-of-Concept-Exploit für CVE-2026-7482, eine nicht authentifizierte Heap-Out-of-Bounds-Read-Schwachstelle im GGUF-Loader von Ollama, die die Speicher-Exfiltration über eine manipulierte Modelldatei demonstriert.
Dieses Repository enthält eine 1-Tage-Proof-of-Concept-Exploitation-Kette (PoC) für CVE-2026-7482, eine nicht authentifizierte Out-of-Bounds-Read-Schwachstelle (OOB) im GGUF-Modell-Loader von Ollama (Versionen vor 0.17.1).
Hinweis: Dies ist eine 1-Tage-Forschungsreproduktion. Ich habe die ursprüngliche CVE nicht entdeckt. Dieses PoC wurde auf Grundlage der öffentlichen Advisory-Details entwickelt, um die Mechanik der Schwachstelle für Bildungs- und defensive Forschungszwecke zu demonstrieren.
Durch die Bereitstellung einer bösartig konstruierten, abgeschnittenen GGUF-Datei an den /api/create-Endpunkt kann ein Angreifer den Quantisierungsparser in fs/ggml/gguf.go und server/quantization.go zwingen, über den zugewiesenen Heap-Puffer hinauszulesen. Der geleakte Speicher wird anschließend exfiltriert, indem das resultierende Modell-Artefakt über den /api/push-Endpunkt an eine angreiferkontrollierte Docker-Registry gepusht wird.
Während dieser 1-Tage-Forschung war die Reproduktion des Absturzes trivial, aber eine stabile Exfiltration ohne Absturz des Servers oder Auslösen von API-Validierungsblockaden erforderte spezifisches architektonisches Forging:
F16 (general.file_type = 1) gekennzeichnet sein, um die strengen Pre-Flight-Checks der Ollama-API zu erfüllen.Q4_K_M-Down-Quantisierung an. Da der Payload als F16 erkannt wird, wird das C++-ggml-Backend gezwungen, den Payload zu verarbeiten, anstatt eine sichere 1:1-Speicherkopie durchzuführen.token_embd.weight) muss als 2D-Matrix geformt sein, bei der die innerste Dimension exakt 256 beträgt (z. B. [num_rows, 256]). Dies richtet sich strikt nach den Q4_K_M-Blockanforderungen und verhindert, dass das Backend die Schicht überspringt.pip install requests numpy gguf
Außerdem benötigen Sie einen öffentlich erreichbaren HTTP-Listener (wie Ngrok), um die exfiltrierten Docker-Layer-Pushes abzufangen.
1. Starten Sie die Rogue-Registry Starten Sie den Listener, um die geleakten Speicherblobs abzufangen.
sudo python3 registry.py
2. Forgen Sie den bösartigen Payload
Generieren Sie die abgeschnittene GGUF-Datei. Sie können TARGET_LEAK_SIZE_MB im Skript anpassen, um zu steuern, wie viel Heap-Speicher pro Anfrage abgeschabt wird. (Empfohlen: 0,5 MB bis 2,0 MB, um Segfaults auf nicht gemappten Seiten zu vermeiden).
python3 forge.py
3. Feuern Sie den Exploit
Bearbeiten Sie exploit.py, um Ihre Ziel-IP und Ihre Rogue-Registry-URL einzufügen, und führen Sie dann aus:
python3 exploit.py
4. Analysieren Sie das Artefakt
Die Registry legt die geleakten Heap-Dumps im Verzeichnis exfils/ ab.
Hinweis zur Datenintegrität (Die Quantisierungsfalle): Obwohl der Exploit erfolgreich bis zu mehrere Megabyte Server-Heap-Speicher erfasst und exfiltriert, werden die Daten während des OOB-Reads dem Q4_K_M-Down-Quantisierungsalgorithmus von Ollama unterzogen. Das Backend castet die rohen Speicherbytes auf float16 und wendet ein verlustbehaftetes 4-Bit-Blockkomprimierungsschema an. Folglich wird der geleakte Speicher mathematisch verzerrt. Standard-ASCII-Extraktionstools liefern binären Müll, was die Wiederherstellung von Klartext-Anmeldedaten über diesen spezifischen Erzwingungspfad praktisch unmöglich macht.
Dieses Projekt dient ausschließlich Bildungs- und autorisierten Schwachstellenforschungszwecken. Verwenden Sie dieses Tool nicht gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche Testberechtigung haben.