
CVE-2026-80312 के लिए रन करने योग्य प्रूफ-ऑफ-कॉन्सेप्ट, जो Apache Camel camel-oauth में एक फेल-ओपन OAuth गार्ड है, जिसमें प्रभावित और ठीक किए गए Spring Boot और Quarkus रीप्रोड्यूसर शामिल हैं।
Apache Camel की उस भेद्यता के लिए चलाने योग्य प्रूफ-ऑफ-कॉन्सेप्ट पुनरुत्पादक, जिसमें किसी रूट की रक्षा करने वाले camel-oauth प्रोसेसर प्रमाणीकरण पूरा न हो पाने पर एक्सचेंज को रोकते नहीं थे। जहाँ प्रमाणित सत्र स्थापित करने में विफलता को रूटिंग समाप्त करनी चाहिए थी और एक त्रुटि लौटानी चाहिए थी, वहाँ प्रोसेसर ने एक प्रतिक्रिया कोड सेट किया लेकिन नियंत्रण रूट को लौटा दिया — इसलिए अनुरोध संरक्षित एंडपॉइंट तक ऐसे पहुँचता रहा जैसे प्रमाणीकरण सफल हो गया हो। परिणाम एक फेल-ओपन प्रमाणीकरण गार्ड है: एक अप्रमाणित कॉलर सामान्य अनुरोध पथ पर, बिना किसी विशेष कॉन्फ़िगरेशन के, रूट जो भी अगला कार्य करता है उस तक पहुँच जाता है।
| रनटाइम | निर्देशिका | स्टैक |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-oauth 4.22.0 (प्रभावित; 4.22.1 में ठीक किया गया), HTTP camel-undertow के माध्यम से |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-oauth 3.39.0 (Camel 4.22.0, प्रभावित; नियंत्रण 3.40.0 / Camel 4.22.1 में ठीक किया गया), HTTP camel-quarkus-platform-http के माध्यम से |
दोनों मॉड्यूल प्रभावित और ठीक किए गए व्यवहार दोनों को प्रदर्शित करते हैं। (Spring Boot मॉड्यूल HTTP ट्रांसपोर्ट के रूप में camel-undertow का उपयोग करता है — गार्ड ट्रांसपोर्ट-अज्ञेय है, और camel-platform-http-starter 4.22.0 को 3.5.x की तुलना में भिन्न Spring Boot लाइन के विरुद्ध बनाया गया है।)
एक रूट /protected को उजागर करता है, जिसे OAuthBearerTokenProcessor द्वारा सुरक्षित किया गया है; केवल एक प्रमाणित अनुरोध को ही उसके बाद आने वाले संरक्षित चरणों तक पहुँचना चाहिए। हमलावर बिना किसी Authorization हेडर के GET /protected भेजता है।
exchange.setRouteStop(true) के बिना लौटा दिया, इसलिए रूट संरक्षित चरणों तक गिर गया → HTTP 200 और संरक्षित बॉडी।rejectUnauthorized(...) को कॉल करता है, जो 401 का उत्तर देता है और रूट को रोक देता है → संरक्षित चरण कभी नहीं चलते।cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
प्रभावित बिल्ड पर अपेक्षित आउटपुट:
Sent: GET /protected (NO Authorization header)
Response status: 200
Response body : PROTECTED-DATA: reached the protected endpoint WITHOUT authenticating
>>> PROVEN: the OAuth guard failed open ...
ठीक किए गए बिल्ड पर: Response status: 401, बॉडी Authorization header, सुरक्षित चरण कभी नहीं चले।
| गुण | मान |
|---|---|
| घटक | camel-oauth (रूट-गार्ड प्रोसेसर, जैसे OAuthBearerTokenProcessor) |
| CWE | CWE-287 (अनुचित प्रमाणीकरण) |
| गंभीरता | उच्च |
| आक्रमण वेक्टर | OAuth-संरक्षित रूट पर एक सामान्य अनुरोध जहाँ प्रमाणीकरण पूरा नहीं किया जा सकता (यहाँ: कोई Authorization हेडर नहीं) |
| प्रभाव | संरक्षित एंडपॉइंट तक अनप्रमाणित पहुँच (प्रमाणीकरण बायपास) |
| प्रभावित संस्करण | 4.11.0 से 4.18.5 से पहले तक, 4.19.0 से 4.22.1 से पहले तक |
| ठीक किए गए संस्करण | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24411 |
| श्रेय | Claude Security Scan Tool |
सलाह: https://camel.apache.org/security/CVE-2026-80312.html
गार्ड प्रोसेसर अब हर उस पथ पर rejectUnauthorized(...) / reject(...) कॉल करते हैं जहाँ प्रमाणीकरण पूरा नहीं किया जा सकता, जो HTTP स्थिति (401) सेट करता है और exchange.setRouteStop(true) कॉल करता है ताकि उस अनुरोध के लिए कोई भी बाद का चरण न चले जिसे प्रोसेसर ने प्रमाणित नहीं किया। "क्रेडेंशियल्स की अनुपस्थिति को कम से कम उतनी ही दृढ़ता से अस्वीकार किया जाना चाहिए जितना अमान्य क्रेडेंशियल्स को।"
गार्ड के बाद एक स्पष्ट प्राधिकरण जाँच रखें, या सुनिश्चित करें कि जब तक आप अपग्रेड नहीं कर सकते, तब तक CamelOAuthUserProfile एक्सचेंज प्रॉपर्टी अनुपस्थित होने पर रूट समाप्त हो जाए।
यह रिपॉज़िटरी शैक्षिक और रक्षात्मक उद्देश्यों के लिए प्रकाशित की गई है: Apache Camel उपयोगकर्ताओं को भेद्यता को समझने, यह सत्यापित करने में मदद करने के लिए कि क्या वे प्रभावित हैं, और पुष्टि करने के लिए कि अपग्रेड करने से यह हल हो जाती है। इस सामग्री का उपयोग उन सिस्टमों के विरुद्ध न करें जिनके आप स्वामी या संचालक नहीं हैं।