CVE-2026-66908
Apache Camel: Camel-platform-http-main: quando l'autenticazione JWT era configurata con un keystore ma senza issuer né audience, i claim iss e aud non venivano mai validati, quindi qualsiasi token non scaduto firmato da una chiave attendibile veniva accettato
- 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:N/I:H/A:NBasso · prossimi 30 giorni
- Percentile
- 34,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 autenticazione impropria nel componente HTTP Main di Apache Camel Platform. Il problema riguarda Apache Camel: dalla 4.8.0 fino alla 4.22.0 esclusa. Il server HTTP integrato di camel-main può proteggere i propri endpoint con l'autenticazione JWT, configurata tramite authenticationEnabled insieme alle proprietà del keystore JWT. JWTAuthenticationConfigurer.buildJwtOptions restituiva null quando non erano configurati né jwtIssuer né jwtAudience, e il chiamante saltava del tutto la chiamata JWTAuthOptions.setJWTOptions, quindi l'istanza Vert.x JWTAuth veniva costruita solo dal keystore. Il risultato era che i token in entrata venivano controllati solo per firma e scadenza: i claim iss e aud non venivano affatto validati. Niente lo segnalava: il server si avviava normalmente e non riportava alcun avviso, quindi una distribuzione configurata secondo la documentazione applicava silenziosamente meno di quanto l'operatore credeva di aver abilitato, e la documentazione del componente stessa presentava il controllo di firma e scadenza come predefinito, con issuer e audience come extra opzionale. Sia il server applicativo sia il server di gestione erano interessati, perché l'omissione era presente in ciascuno dei due percorsi configureAuthentication. Qualsiasi token non scaduto firmato da una chiave di cui il keystore configurato si fida veniva quindi accettato, indipendentemente dall'issuer che lo aveva emesso o dall'audience a cui era destinato. La portata del problema dipende dal trust set del keystore: se la chiave di firma appartiene a un identity provider condiviso o multi-tenant, viene accettato un token legittimamente emesso per un'audience completamente diversa, mentre un keystore che contiene un firmatario dedicato restringe la portata al riutilizzo di token emessi per altri servizi all'interno dello stesso dominio di fiducia. Le opzioni jwtIssuer e jwtAudience non esistevano prima della 4.21.0, quindi nelle versioni precedenti non esisteva alcun modo supportato per applicare questi claim. Si consiglia agli utenti di aggiornare alla versione 4.22.0, che risolve il problema. Dalla 4.22.0 il server rifiuta di avviarsi quando è configurato un keystore JWT ma non sono impostati né jwtIssuer né jwtAudience, indicando le proprietà coinvolte; una distribuzione che vuole davvero solo la validazione di firma e scadenza deve dichiararlo esplicitamente con la nuova opzione jwtAllowMissingIssuerAndAudience, il cui valore predefinito è false. Questo comportamento è corretto solo nella 4.22.0. Le release 4.14.9 e 4.18.4 non modificano il comportamento predefinito: aggiungono le opzioni jwtIssuer e jwtAudience così che gli operatori su questi rami di manutenzione possano applicare i claim tramite configurazione; un'installazione che aggiorna alla 4.14.9 o alla 4.18.4 senza impostare almeno una di queste due proprietà continua ad accettare qualsiasi token non scaduto firmato da una chiave attendibile. Gli utenti su 4.14.x o 4.18.x dovrebbero quindi aggiornare alla 4.14.9 o alla 4.18.4 e poi impostare jwtIssuer, jwtAudience, o entrambi. Le release dalla 4.8.0 fino alla 4.21.x inclusa non offrono alcun modo per applicare questi claim e dovrebbero essere portate a una versione che lo consenta. Indipendentemente dalla versione, limitare il keystore JWT al trust set più piccolo possibile - idealmente un firmatario dedicato a questo servizio piuttosto che una chiave condivisa dell'identity provider - e, dove un gateway valida già issuer e audience davanti al server, assicurarsi che non possa essere aggirato. Note: Il ticket JIRA: https://issues.apache.org/jira/browse/CAMEL-24281 fa riferimento ai vari commit che hanno risolto il problema e contiene ulteriori dettagli. Il controllo fail-closed non ha potuto essere backportato. Le opzioni jwtIssuer e jwtAudience sono state introdotte solo nella 4.21.0 da CAMEL-23525, quindi su camel-4.18.x e camel-4.14.x non c'era alcuna impostazione che un operatore potesse configurare per soddisfare il requisito, e il controllo avrebbe rotto ogni distribuzione JWT su quei rami senza alcun rimedio disponibile.
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.