CVE-2026-84181 — camel-shiro: थ्रेड-बाउंड सब्जेक्ट के माध्यम से प्रमाणीकरण बायपास

Apache Camel की उस भेद्यता के लिए चलाने योग्य प्रूफ-ऑफ-कॉन्सेप्ट रिप्रोड्यूसर, जिसमें Shiro सुरक्षा प्रोसेसर ने क्रेडेंशियल सत्यापन छोड़ दिया जब वर्तमान थ्रेड से पहले से बंधा Shiro Subject आने वाले एक्सचेंज के समान ही प्रिंसिपल रखता था। चूँकि Camel एक्सचेंज को वहन करने वाला थ्रेड एक पूल से लिया जाता है और एक्सचेंजों के बीच पुनः उपयोग किया जाता है, इसलिए किसी पूर्व प्रमाणीकृत एक्सचेंज द्वारा बंधा छोड़ा गया सब्जेक्ट किसी बाद के ऐसे एक्सचेंज के लिए जाँच को संतुष्ट कर सकता था जो अपने स्वयं के कोई वैध क्रेडेंशियल प्रस्तुत नहीं करता — उस बाद के एक्सचेंज पर पासवर्ड का कभी सत्यापन ही नहीं हुआ। हमलावर को इससे अधिक कुछ नहीं चाहिए कि वह ऐसे प्रिंसिपल का नाम लेते हुए एक अनुरोध भेजे जो वर्तमान में सक्रिय उपयोग में हो।

रनटाइम	निर्देशिका	स्टैक
Camel Spring Boot	camel-spring-boot/	Spring Boot 3.5.13 + camel-shiro 4.22.0 (प्रभावित; ठीक किया गया 4.22.1)
Camel Quarkus	camel-quarkus/	Quarkus 3.29.0 + camel-quarkus-shiro (Camel 4.15.0, प्रभावित; ठीक किया गया नियंत्रण CQ 3.40.0 / Camel 4.22.1)

दोनों मॉड्यूल प्रभावित और ठीक किए गए व्यवहार को प्रदर्शित करते हैं।

यह क्या प्रदर्शित करता है

एक रूट को ShiroSecurityPolicy द्वारा सुरक्षित किया गया है जिसे alwaysReauthenticate=false के साथ बनाया गया है — यह प्रलेखित मोड है जिसमें प्रमाणीकृत सब्जेक्ट को जानबूझकर एक्सचेंजों के बीच (पूल किए गए, पुनः उपयोग किए जाने वाले) वर्कर थ्रेड से बंधा रखा जाता है। शोषण ड्राइवर, एक ही HTTP वर्कर थ्रेड के भीतर, क्रम से दो एक्सचेंज चलाता है:

1. ringo द्वारा सही पासवर्ड starr के साथ एक वैध अनुरोध — यह प्रमाणीकृत होता है और Shiro सब्जेक्ट को इस थ्रेड से बंधा छोड़ देता है (जैसे किसी व्यस्त सेवा में कोई पूर्व प्रमाणीकृत अनुरोध करता होगा);
2. उसी उपयोगकर्ता ringo का नाम लेते हुए लेकिन गलत पासवर्ड not-starr के साथ एक हमलावर अनुरोध, उसी थ्रेड पर।

• प्रभावित: दूसरा एक्सचेंज अपने पासवर्ड का सत्यापन किए बिना स्वीकार कर लिया जाता है — यह चरण 1 द्वारा थ्रेड से बंधा छोड़े गए सब्जेक्ट पर सवार हो जाता है — और संरक्षित लॉजिक तक पहुँच जाता है। प्रमाणीकरण बायपास।
• ठीक किया गया: दूसरे एक्सचेंज के क्रेडेंशियल का स्वतंत्र रूप से सत्यापन किया जाता है और इसे AuthenticationException के साथ अस्वीकार कर दिया जाता है, भले ही वही उपयोगकर्ता अभी भी थ्रेड से बंधा हुआ हो।

# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected: wrong password reaches protected logic; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-84181-shiro-auth-bypass-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: wrong password rejected; >>> Not exploited

# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack     # affected (Camel 4.15.0): wrong password reaches protected logic
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack     # fixed: wrong password rejected

भेद्यता सारांश

Property	Value
घटक	camel-shiro (ShiroSecurityProcessor.authenticateUser)
CWE	CWE-287 (अनुचित प्रमाणीकरण)
गंभीरता	MEDIUM
आक्रमण वेक्टर	एक अनुरोध जो वर्तमान में पुनः उपयोग किए गए वर्कर थ्रेड से बंधे प्रिंसिपल का नाम लेता है, और अपने स्वयं के कोई वैध क्रेडेंशियल नहीं रखता
प्रभाव	प्रमाणीकरण बायपास: एक अप्रमाणित अनुरोध को पहले से बंधे प्रिंसिपल के रूप में स्वीकार कर लिया जाता है; इसका पासवर्ड कभी सत्यापित नहीं होता
प्रभावित संस्करण	4.0.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक
ठीक किए गए संस्करण	4.18.5, 4.22.1, 4.23.0
JIRA	CAMEL-24439
श्रेय	Claude Security Scan Tool

सलाह: https://camel.apache.org/security/CVE-2026-84181.html

समाधान

ShiroSecurityProcessor.authenticateUser अब लॉगिन को छोड़ता नहीं है जब थ्रेड-बद्ध सब्जेक्ट पहले से ही वही प्रिंसिपल रखता है। पिछला कोड currentUser.isAuthenticated() && username.equals(currentUser.getPrincipal()) पर शॉर्ट-सर्किट करता था; एक मेल खाता उपयोगकर्ता नाम इस एक्सचेंज के साथ प्रस्तुत पासवर्ड के बारे में कुछ नहीं कहता। प्रोसेसर अब प्रत्येक एक्सचेंज पर currentUser.login(token) कॉल करता है, इसलिए प्रस्तुत क्रेडेंशियल हमेशा सत्यापित होते हैं। alwaysReauthenticate अभी भी सब्जेक्ट की rememberMe दीर्घायु को नियंत्रित करता है, लेकिन यह अब यह तय नहीं करता कि पासवर्ड जाँचा जाए या नहीं।

यदि आप अपग्रेड नहीं कर सकते तो शमन

सुनिश्चित करें कि प्रत्येक एक्सचेंज के अंत में Shiro सब्जेक्ट को थ्रेड से साफ़ कर दिया जाए (ताकि कोई भी सब्जेक्ट बाद वाले एक्सचेंज द्वारा विरासत में न लिया जा सके) — उदाहरण के लिए एक onCompletion/प्रोसेसर के साथ जो Shiro के ThreadContext.unbindSubject() को कॉल करता है — जब तक आप अपग्रेड नहीं कर सकते।

अस्वीकरण

यह रिपॉज़िटरी शैक्षिक और रक्षात्मक उद्देश्यों के लिए प्रकाशित की गई है: Apache Camel उपयोगकर्ताओं को भेद्यता को समझने, यह सत्यापित करने में मदद करने के लिए कि क्या वे प्रभावित हैं, और पुष्टि करने के लिए कि अपग्रेड करने से यह हल हो जाता है। यहाँ दिए गए उपयोगकर्ता, पासवर्ड और कुंजियाँ निष्क्रिय स्थानीय फ़िक्स्चर हैं। इस सामग्री का उपयोग उन सिस्टम के विरुद्ध न करें जो आपके स्वामित्व में या संचालन में नहीं हैं।