CVE-2025-22381: Host-Header-Injection in Aggie

Detaillierte Analyse und Proof-of-Concept für CVE-2025-22381, eine Host-Header-Injection-Schwachstelle, die im Open-Source-Projekt Aggie entdeckt wurde.

Schwachstellenübersicht+

CVE ID: CVE-2025-22381

Veröffentlicht: Oktober 2025 (MITRE-Zuordnung)

Öffentlich bekannt gegeben: Februar 2026

Reporter: Anas Abderrahman Benbarek

Entdeckungsdatum: 17. September 2025

Betroffenes Projekt: TID-Lab/aggie

Betroffene Versionen: Alle Versionen (einschließlich 2.6.1 und früher; Stand Februar 2026 kein Fix angewendet)

Schweregrad: Mittel bis Hoch (geschätzter CVSS-Wert ~7.1–7.5)

Auswirkung: Ermöglicht Phishing-Angriffe, die zum Diebstahl von Passwort-Reset-Tokens und potenzieller Kontokompromittierung führen.

Hintergrund

Ich verbringe ziemlich viel Zeit damit, Open-Source-Node.js-Projekte auf GitHub zu überprüfen, insbesondere solche, die Authentifizierungsabläufe behandeln. Im September 2025, als ich das Aggie-Repository durchsah, fiel mir etwas auf, das in der Passwort-Reset-Logik sofort ins Auge stach. Was als routinemäßiges Lesen von Code begann, endete als CVE-2025-22381 – eine klassische Host-Header-Injection-Schwachstelle, die es einem Angreifer ermöglicht, die Domain in Passwort-Reset-E-Mails zu kontrollieren.

Wie ich es gefunden habe

Ich klonte das Repository und begann, Dateien unter lib/api/ zu lesen, wobei ich mich auf alles konzentrierte, was mit Authentifizierung und E-Mail-Erzeugung zu tun hatte.

Die Datei lib/api/reset-password.js enthält die Endpunktlogik für /reset-password. Der kritische Teil befindet sich im sendEmail-Helfer:

function sendEmail(user, req, callback) { var token = encodeToken(user);

mailer.sendFromTemplate({ template: 'forgotPassword', user: user, token: token, host: req.headers.host, // ← vulnerable protocol: req.protocol, acceptLanguage: req.headers['accept-language'] }, callback); }

Die Zeile host: req.headers.host ist das Problem. In express stammt req.headers.host direkt aus dem Host-HTTP-Header, der vollständig vom Angreifer kontrolliert wird. Es gibt keine Validierung, keine Whitelist und keinen Rückgriff auf eine vertrauenswürdige Domain aus der Konfiguration.

Erste Bestätigung

Ich richtete schnell eine lokale Instanz gemäß den README-Anweisungen ein (Ubuntu, nvm, npm install, secrets.json mit Test-SMTP), startete den Server und löste einen Passwort-Reset aus. Der generierte E-Mail-Link verwendete wie erwartet localhost:3000.

Dann wiederholte ich die Anfrage mit einem manipulierten Host-Header:

curl -X POST http://localhost:3000/reset-password
-H "Host: evil-phish.example"
-d "email=[email protected]"

Die E-Mail (über MailHog erfasst) enthielt: http://evil-phish.example/reset-password?token=...

Der Beweis ist erbracht. Die Anwendung vertraut beim Erstellen des Reset-Links dem vom Client gelieferten Host-Header.

Wie der Angriff tatsächlich funktioniert

Der Angreifer sendet eine Passwort-Reset-Anfrage für die E-Mail-Adresse des Opfers, setzt den Host-Header jedoch auf eine Domain, die er kontrolliert (z. B. evil-phish.example).

Aggie erzeugt ein legitimes Reset-Token (serverseitig, zeitlich begrenzt, mit dem Konfigurationsgeheimnis verschlüsselt).

Die E-Mail wird mit einem Link zur Domain des Angreifers statt zur echten Domain gesendet.

Das Opfer erhält die E-Mail und klickt auf den Link (Phishing-Erfolgsbedingung).

Das Opfer landet auf dem Server des Angreifers.

Der Server des Angreifers kann:

Einfach eine gefälschte Seite „Reset fehlgeschlagen“ anzeigen und das Token stillschweigend verwerfen, oder

Das Token aus dem Query-String erfassen (über serverseitiges Logging oder JavaScript), oder

Die Anfrage per Proxy an die echte Aggie-Instanz weiterleiten, das Token erfassen und den Benutzer auf die legitime Reset-Seite umleiten (damit das Opfer nicht sofort merkt, dass etwas nicht stimmt).

Der Angreifer verwendet das erfasste Token später auf der echten Domain, um das Passwort des Opfers zurückzusetzen.

Der Kernpunkt: Host-Header-Injection allein ermöglicht dem Angreifer nicht, das Token direkt zu verwenden. Der Angreifer muss das Opfer weiterhin dazu bringen, den bösartigen Link zu besuchen, damit das Token die Infrastruktur des Angreifers erreicht. Aus diesem Grund handelt es sich um eine Phishing-ermöglichende Schwachstelle und nicht um eine direkte Kontokompromittierung ohne Benutzerinteraktion.

Technischer Schweregrad & Auswirkung

Dies ist ein Problem mit mittlerem bis hohem Schweregrad, je nach Kontext:

AV:N: Über das Netzwerk erreichbar

PR:N: Keine Berechtigungen erforderlich

AC:L: Geringe Komplexität

UI:R: Erfordert Benutzerinteraktion

S:C: Der Scope kann sich ändern (die Auswirkung erstreckt sich auf das Konto des Opfers auf der legitimen Domain)

C:L / I:H: Auswirkung auf Vertraulichkeit und Integrität des Kontos des Opfers

Viele Datenbanken geben ihn mit CVSS ~7.1–7.5 an. Ich persönlich halte ihn in Produktionsumgebungen für ernst, in denen Aggie für sensible Überwachung (Wahlen, Krisen) eingesetzt wird, da erfolgreiches Phishing hier zu einer vollständigen Kontokompromittierung führen kann.

Proof-of-Concept (Detailliert & Reproduzierbar)

Umgebung

Ubuntu 18.04/20.04 (wie empfohlen)

Node 12.16 (gemäß .nvmrc)

MailHog: Läuft lokal zur E-Mail-Erfassung (docker run -d -p 8025:8025 -p 1025:1025 mailhog/mailhog)

Aggie konfiguriert mit email.transport, das auf localhost:1025 zeigt

Schritt für Schritt

Aggie klonen & starten:

git clone https://github.com/TID-Lab/aggie.git cd aggie nvm install npm install cp config/secrets.json.example config/secrets.json edit secrets.json → set adminPassword, add test SMTP if needed npm start

Erstellen Sie einen Testbenutzer über die Web-UI oder direkt in MongoDB.

Bösartigen Reset auslösen:

curl -i -X POST http://localhost:3000/reset-password
-H "Host: evil-phish.example"
-H "Content-Type: application/x-www-form-urlencoded"
-d "email=[email protected]"

Öffnen Sie MailHog: Untersuchen Sie die gesendete E-Mail. Der Reset-Link zeigt auf http://evil-phish.example/reset-password?token=...

Offenlegungszeitplan

Sep 2025: Entdeckt + lokaler PoC
Sep 2025: E-Mail an [email protected] mit vollständigen Details und PoC
Sep 2025: Bei MITRE eingereicht (Service-Request 1926730 / MCID15453119)
Okt 2025: MITRE hat CVE-2025-22381 zugewiesen

Okt–Dez 2025: Weder öffentlicher Patch noch Reaktion beobachtet

Feb 2026: Öffentliche Offenlegung (dieser Artikel)

Empfohlener Fix

Codeänderung

Ersetzen Sie die verwundbare Zeile in lib/api/reset-password.js durch einen vertrauenswürdigen Wert:

// In lib/api/reset-password.js, inside sendEmail() const config = require('../../config/secrets').get();

// Option A: Hard trust config value (recommended for single-domain) const host = config.appHost || 'localhost:3000';

// Then use it: mailer.sendFromTemplate({ template: 'forgotPassword', user: user, token: token, host: host, // Use the trusted variable protocol: config.environment === 'production' ? 'https' : req.protocol, acceptLanguage: req.headers['accept-language'] }, callback);

Konfiguration

Fügen Sie zu secrets.json hinzu:

"appHost": "https://your-real-domain.com"

Abschließende Gedanken

Host-Header-Injection bleibt in den Jahren 2025–2026 überraschend häufig, insbesondere in Projekten, die vor Jahren gestartet wurden und nicht intensiv geprüft wurden. Aggie ist ein wertvolles Werkzeug für Civic Tech und Krisenüberwachung – ich hoffe, die Maintainer wenden bald einen Fix an.

Wenn Sie Aggie warten oder verwenden, überprüfen Sie Ihre Bereitstellung und patchen Sie manuell, bis eine offizielle Version erscheint. Zögern Sie nicht, sich zu melden, wenn Sie Fragen haben oder ähnliche Probleme in anderen Projekten besprechen möchten.

Danke fürs Lesen und bleiben Sie sicher da draußen.

CVE-2025-22381

Beliebteste