CVE-2026-78163
Apache Camel: l'origine di input del corpo del messaggio non convalidata in Camel-Docling consente Server-Side Request Forgery e divulgazione di file locali
- Pubblicato
- 19 ott 2026
- Aggiornato
- 19 ott 2026
- Assegnazione CNA
- apache
- Evidenza osservata
- 17 ott 2026
CVSS primario
cvelist · CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NRiepilogo
Vulnerabilità di Server-Side Request Forgery (SSRF), Limitazione Impropria di un Pathname a una Directory Ristretta ('Path Traversal') ed Esposizione di Informazioni Sensibili a un Attore Non Autorizzato nel componente Apache Camel Docling. Questo problema interessa Apache Camel: dalla 4.15.0 precedente alla 4.18.5, dalla 4.19.0 precedente alla 4.22.1. DoclingProducer decideva cosa significasse il corpo di un messaggio String ispezionandone il prefisso. Un corpo che iniziava con http:// o https:// veniva passato a Docling come URL remoto da recuperare, un corpo che iniziava con / o conteneva una barra rovesciata veniva letto dal filesystem locale, e qualsiasi altra cosa veniva scritta in un file temporaneo e convertita come contenuto del documento. La modalità veniva scelta implicitamente e nessuna opzione dell'endpoint consentiva all'autore di una route di vincolare il componente a una singola interpretazione, così una route che intende convertire qualunque testo arrivi nel corpo diventava silenziosamente un recuperatore di risorse remote o un lettore di file locali ogni volta che il testo iniziava con uno di quei prefissi. L'unica protezione applicata al valore derivato era un controllo di dimensione, e tale controllo era racchiuso in un test di esistenza, così un percorso che non risolveva a nulla, o a uno pseudo-file che riportava una dimensione pari a zero, passava senza essere controllato affatto. Cinque punti di chiamata raggiungevano i due sink: la modalità CLI aggiungeva il valore come argomento posizionale finale del sottoprocesso docling, e la modalità docling-serve lo passava o a HttpSource perché il backend lo recuperasse o a Files.readAllBytes affinché il contenuto potesse essere codificato in base64 e caricato. Poiché il corpo dello scambio non viene mai filtrato da un HeaderFilterStrategy, a differenza del namespace degli header Camel, un mittente in grado di inserire testo in un messaggio che una route inoltra a un endpoint docling poteva raggiungere entrambi i sink senza alcun opt-in da parte del deployment. Si raccomanda agli utenti di aggiornare alla versione 4.23.0, che corregge il problema. Se gli utenti si trovano sul ramo di release 4.22.x, si suggerisce di aggiornare alla 4.22.1. Se gli utenti si trovano sul ramo di release 4.18.x, si suggerisce di aggiornare alla 4.18.5. Il ramo di release 4.14.x e precedenti ha raggiunto l'end of life prima che questo problema fosse risolto e non riceverà una correzione, quindi i deployment su tali linee devono passare a una release supportata. Per i deployment che non possono aggiornare immediatamente, non instradare corpi di messaggi che provengono dall'esterno del deployment verso un endpoint docling, e passare il documento tramite un corpo tipizzato come File, byte[] o InputStream, oppure tramite l'header CamelDoclingInputFilePath, in modo che il corpo non sia mai soggetto all'interpretazione del prefisso.
Utilizzo responsabile
Utilizza le informazioni sulla vulnerabilità solo sui sistemi che possiedi o che sei autorizzato a testare. Kitploit si collega ai metadati della ricerca pubblica e non memorizza codici exploit o payload dannosi.