CVE-2026-59230
Apache Camel: Camel-Mail: il formato dati MimeMultipart copiava le intestazioni MIME sul messaggio Camel senza una strategia di filtro delle intestazioni durante l'unmarshalling con headersInline abilitato
- Pubblicato
- 24 ago 2026
- Aggiornato
- 25 ago 2026
- Assegnazione CNA
- apache
- Evidenza osservata
- 24 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:NBasso · prossimi 30 giorni
- Percentile
- 35,8%
- Data del modello
- 21 set 2026
L'EPSS è una stima statistica, non una certezza o una misura di impatto. Combinalo con CVSS, stato KEV, esposizione e ambiente.
Riepilogo
Vulnerabilità di convalida impropria dell'input in Apache Camel. Il problema riguarda Apache Camel: dalla versione 2.17.0 fino alla 4.14.9 esclusa, dalla versione 4.15.0 fino alla 4.18.4 esclusa, dalla versione 4.19.0 fino alla 4.22.0 esclusa. Il componente camel-mail include un formato dati MimeMultipart in grado di eseguire l'unmarshal di un messaggio MIME multipart. Quando è configurato con headersInline impostato su true, il percorso di unmarshal copia gli header MIME del messaggio in arrivo sul messaggio Camel: enumera ogni header che non sia uno dei tre standard che genera autonomamente - Message-ID, MIME-Version e Content-Type - e chiama setHeader per ciascuno, senza applicare alcuna HeaderFilterStrategy. I nomi di quegli header MIME provengono dal messaggio di cui viene eseguito l'unmarshal, quindi un mittente in grado di influenzare il messaggio potrebbe inserire un header il cui nome ricade nel namespace interno di Camel e farlo impostare sull'Exchange. I componenti Camel leggono gli header di controllo da quel namespace per sovrascrivere il comportamento configurato - il producer camel-sql, ad esempio, prende l'istruzione da eseguire da un header Camel quando presente - quindi un header iniettato potrebbe reindirizzare ciò che un passaggio successivo del route fa con dati che l'autore del route non ha mai inteso far derivare dal messaggio. Quali sink sono raggiungibili, e quali sono le conseguenze, dipende interamente da ciò che il route fa dopo il passaggio di unmarshal. Il consumer camel-mail applicava già una strategia di filtro degli header sul proprio percorso in entrata, quindi questo era il percorso in entrata parallelo nello stesso componente che il precedente hardening non copriva. La copia interessata viene eseguita solo quando headersInline è abilitato, che non è il valore predefinito: con l'impostazione predefinita gli header MIME vengono esposti come allegati piuttosto che come header del messaggio e non sono interessati. Il comportamento risale all'introduzione del formato dati nella versione 2.17.0 ed era presente su ogni linea di rilascio fino a questa correzione. Si consiglia agli utenti di aggiornare alla versione 4.22.0, che risolve il problema. Se gli utenti si trovano sul ramo di rilascio LTS 4.14.x, si suggerisce di aggiornare alla 4.14.9. Se gli utenti si trovano sul ramo di rilascio 4.18.x, si suggerisce di aggiornare alla 4.18.4. Per le implementazioni che non possono aggiornare immediatamente, lasciare headersInline al suo valore predefinito false dove gli header inline non sono necessari, poiché la copia viene eseguita solo quando è abilitato. Dove deve rimanere abilitato, rimuovere gli header interni di Camel immediatamente dopo il passaggio di unmarshal, ad esempio con removeHeaders(“Camel*”) posizionato prima di qualsiasi processor o producer che legga header di controllo, e non eseguire l'unmarshal di contenuto MIME proveniente da un mittente non attendibile in un route che smista in base ai valori degli header. Come difesa in profondità, trattare i nomi degli header di qualsiasi messaggio MIME proveniente dall'esterno del perimetro di fiducia come input non attendibile.
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.