
Abhängigkeitsfreier Python-Verifier, der CVE-2026-24733 erkennt, eine Apache Tomcat HTTP/0.9 HEAD Security-Constraint-Bypass-Schwachstelle, mit JSON-Ausgabe und CI/CD-Exit-Codes.
HEAD-Anfrage im HTTP/0.9-Stil unter bestimmten Security-Constraint-Konfigurationen fehlerhaft.Ein leichtgewichtiger, abhängigkeitsfreier Python-Sicherheitsverifier für
CVE-2026-24733, eine Apache Tomcat HTTP/0.9 HEAD Security-Constraint-
Umgehung.
Das Projekt ist konzipiert für:
Nur autorisiertes Testen. Scannen Sie nur Systeme, die Ihnen gehören oder für die Sie eine ausdrückliche Testgenehmigung haben.
Apache Tomcat verarbeitete eine HEAD-Anfrage im HTTP/0.9-Stil unter
bestimmten Security-Constraint-Konfigurationen fehlerhaft.
Die relevante Bedingung ist eine Konfiguration, bei der:
GET-Zugriff auf eine Ressource eingeschränkt istHEAD erlaubt istHEAD-Anfrage im HTTP/0.9-Stil empfängtUnter den betroffenen Tomcat-Versionen konnte dies zu einer Umgehung der Security-Constraint führen.
Dies ist in erster Linie eine konfigurationsabhängige Verhaltensschwachstelle. Daher sollte die alleinige Erkennung einer betroffenen Tomcat-Version nicht automatisch als Beweis für eine Ausnutzung behandelt werden.
Gemäß den Apache Tomcat Security Advisories:
| Branch | Behobene Version |
|---|---|
| Tomcat 9 | 9.0.113 |
| Tomcat 10.1 | 10.1.50 |
| Tomcat 11 | 11.0.15 |
Betroffene Versionen sind die entsprechenden früheren Versionen in diesen unterstützten Branches.
Konsultieren Sie stets das offizielle Apache-Advisory, bevor Sie Behebungsentscheidungen treffen.
Python 3.9+.
Es sind keine Python-Pakete von Drittanbietern erforderlich.
Der Verifier verwendet ausschließlich die Python-Standardbibliothek.
Basis-HTTP:
python3 cve_2026_24733.py \
http://127.0.0.1:8080/protected
HTTPS:
python3 cve_2026_24733.py \
https://127.0.0.1:8443/protected
Für ein autorisiertes Labor mit einem selbstsignierten Zertifikat:
python3 cve_2026_24733.py \
--insecure \
https://127.0.0.1:8443/protected
JSON-Ausgabe Für Automatisierung und SIEM/CI-Pipelines:
python3 cve_2026_24733.py \
--json \
https://127.0.0.1:8443/protected
Beispiel:
{
"cve": "CVE-2026-24733",
"verdict": "INCONCLUSIVE",
"confidence": "medium",
"version": "10.1.49",
"version_assessment": "affected-range"
}
Exit-Codes Code Bedeutung 0 Nicht anfällig / Schwachstelle nicht bestätigt 1 Potenziell anfällig 2 Unschlüssig oder Scanner-Fehler
Dies macht das Tool geeignet für CI/CD:
python3 cve_2026_24733.py \
--json \
https://target.example/protected
if [ $? -eq 1 ]; then
echo "Potential CVE-2026-24733 exposure"
exit 1
fi
Erkennungsmethodik Der Verifier führt zwei begrenzte Anfragen gegen den vom Bediener ausdrücklich angegebenen Pfad durch:
Normales HTTP/1.1 GET Eine konventionelle Anfrage wird gesendet, um das normale Zugriffsverhalten festzustellen.
HTTP/0.9-Stil HEAD Der Verifier sendet eine absichtlich im HTTP/0.9-Stil gehaltene Anfrage:
HEAD /protected
Die Anfrage enthält absichtlich keine HTTP-Version oder HTTP/1.x- Header.
Die beiden Beobachtungen werden verglichen.
Ein besonders interessantes Ergebnis ist:
GET /protected -> 401/403 HTTP/0.9 HEAD -> Antwort empfangen
In Kombination mit einer betroffenen Tomcat-Version wird dies gemeldet als:
POTENTIALLY VULNERABLE
Das Tool verwendet bewusst das Wort potenziell, da Netzwerkkomponenten, Reverse-Proxies, Anwendungs-Routing und endpunktspezifische Sicherheitsrichtlinien die Beobachtung beeinflussen können.
Falsch-Positive Dieser Verifier ist bewusst konservativ.
Ein POTENTIALLY_VULNERABLE-Ergebnis sollte untersucht werden, anstatt blind als bestätigte Ausnutzung behandelt zu werden.
Mögliche Ursachen sind:
Reverse-Proxies
WAF-Verhalten
Load Balancer
Unterschiedliche Backend-Knoten
Benutzerdefinierte Servlet-Filter
Autorisierung auf Anwendungsebene
Endpunktspezifische Konfiguration
Nicht-Tomcat-HTTP-Server vor Tomcat
Für eine Behebung mit hoher Konfidenz prüfen Sie die Tomcat-Version und die entsprechenden Security Constraints.
Sicherheitsdesign Der Verifier führt absichtlich Folgendes nicht aus:
das Ziel crawlen
Verzeichnisse auflisten
URLs brute-forcen
Authentifizierung umgehen
geschützte Anwendungsdaten extrahieren
Befehle ausführen
Dateien hochladen
den Serverzustand verändern
Rechteausweitung versuchen
das Problem mit einer anderen Schwachstelle verketten
Der Bediener gibt den zu testenden Endpunkt ausdrücklich an.
Die Antworterfassung ist begrenzt, um das unnötige Herunterladen großer Antworten zu verhindern.
Empfohlener defensiver Workflow Wenn das Tool meldet:
POTENTIALLY VULNERABLE
Identifizieren Sie die tatsächliche Tomcat-Backend-Version.
Überprüfen Sie, ob der Endpunkt eine Security Constraint mit GET- Einschränkung / HEAD-Erlaubnis verwendet.
Prüfen Sie das Reverse-Proxy-/WAF-Routing.
Aktualisieren Sie Tomcat auf die entsprechende behobene Version.
Testen Sie denselben Endpunkt erneut.
Überprüfen Sie die Logs auf unerwarteten HTTP/0.9-Verkehr.
Blockieren Sie bei Bedarf vorübergehend fehlerhafte HTTP/0.9-Anfragen am Reverse-Proxy, während die Behebung durchgeführt wird.
Verantwortungsvolle Offenlegung Wenn beim Testen ein bisher unbekanntes Sicherheitsproblem festgestellt wird:
Veröffentlichen Sie keine sensiblen Zielinformationen.
Bewahren Sie relevante Beweise auf.
Benachrichtigen Sie die betroffene Organisation.
Befolgen Sie den Sicherheitsmeldeweg des Herstellers.
Koordinieren Sie Offenlegungsfristen verantwortungsvoll.
Referenzen Apache Tomcat Security Advisories:
CVE:
NVD:
Lizenz MIT-Lizenz.
Verwenden Sie es verantwortungsvoll und nur gegen Systeme, für die Sie eine Autorisierung haben.