oscerd/cve-2026-80343Proof-of-concept eseguibile per CVE-2026-80343, un bypass della distinzione tra maiuscole e minuscole nei security-constraint di camel-netty-http, con riproduttori Spring Boot e Quarkus e verifica della correzione.
Reproduttore proof-of-concept eseguibile per la vulnerabilità di Apache Camel in cui il security constraint di
camel-netty-http confrontava il percorso della richiesta con il context path configurato usando una corrispondenza
case-sensitive, mentre il routing che inoltra la richiesta all'endpoint non applicava la stessa regola. I due
confronti sono discordanti per qualsiasi percorso la cui combinazione di maiuscole e minuscole differisca dal valore
configurato: un chiamante esterno può modificare il caso di un carattere nel segmento del context-path in modo che il
security constraint non riconosca più il percorso come protetto, mentre la richiesta viene comunque inoltrata allo
stesso endpoint. Il constraint viene saltato e la route protetta viene raggiunta senza soddisfarlo — nessuna
credenziale, nessun accesso preventivo e nessuna configurazione speciale richiesti.
| Runtime | Directory | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-netty-http 4.22.0 (affetto; corretto in 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-netty-http 3.29.0 (Camel 4.15.0, affetto; controllo corretto 3.40.0 / Camel 4.22.1) |
Un consumer netty-http è in ascolto sul context path /app ed è protetto da un SecurityConstraintMapping che
protegge /secret (relativo all'endpoint) con un authenticator che rifiuta. Entrambe le richieste seguenti non
portano credenziali:
GET /app/secret (caso configurato) → il constraint la riconosce come protetta → 401.GET /App/secret (caso del context-path alterato) → l'extractTarget dell'handler rimuove il context path solo con
uno startsWith case-sensitive, quindi la rimozione viene saltata e il constraint non riconosce il percorso come
protetto → il router la inoltra comunque all'endpoint /app → 200 e il body protetto, senza autenticazione.Sulla build corretta entrambe le richieste restituiscono 401.
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Output atteso sulla build affetta:
Configured case GET /app/secret -> status 401, body:
Altered case GET /App/secret -> status 200, body: PROTECTED-ADMIN-DATA: reached the protected endpoint
>>> PROVEN: /app/secret is correctly rejected (401), but /App/secret bypassed the security constraint ...
| Proprietà | Valore |
|---|---|
| Componente | camel-netty-http |
| CWE | CWE-178 (Gestione impropria della distinzione tra maiuscole e minuscole) |
| Gravità | ALTA |
| Vettore di attacco | Una richiesta il cui caso del context-path differisce dal percorso dell'endpoint configurato |
| Impatto | Security constraint saltato; route protetta raggiunta senza autenticazione |
| Versioni affette | Dalla 4.0.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1 |
| Versioni corrette | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24412 |
| Credito | Claude Security Scan Tool |
Advisory: https://camel.apache.org/security/CVE-2026-80343.html
Il security constraint e la gestione del context-path ora confrontano il percorso in modo coerente (senza distinzione tra maiuscole e minuscole sul context path), così una richiesta con il caso alterato viene riconosciuta come protetta esattamente come la sua forma con il caso configurato ed è soggetta alla stessa autenticazione.
Applica l'autorizzazione direttamente nella route invece di affidarti esclusivamente al security constraint di netty-http, oppure normalizza il caso del percorso della richiesta prima del controllo di sicurezza, finché non potrai aggiornare.
Questo repository è pubblicato per scopi educativi e difensivi: per aiutare gli utenti di Apache Camel a comprendere la vulnerabilità, verificare se sono affetti e confermare che l'aggiornamento la risolve. Non usare questo materiale contro sistemi che non possiedi o non gestisci.