{"answers":{"affected":"2 open source packages ship an affected version, including org.apache.camel:camel-platform-http-main. It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-66908 in the wild and no public exploit code.","fix":"Upgrade org.apache.camel:camel-platform-http-main to 4.22.0 or later.","what":"CVE-2026-66908 is a high-severity authentication bypass vulnerability in Apache Camel, published on 24 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-66908 and fix it if it is affected.\n\nWhat it is: CVE-2026-66908 is a high-severity authentication bypass vulnerability in Apache Camel, published on 24 Aug 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-66908 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- org.apache.camel:camel-platform-http-main (Maven): affected from 4.8.0; fixed in 4.22.0\n- org.apache.camel:camel-platform-http-main (Maven): affected from 4.8.0; fixed in 4.22.0\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-66908/ (Markdown: https://insights.sbomify.com/CVE-2026-66908/index.md)","id":"CVE-2026-66908","markdown":"https://insights.sbomify.com/CVE-2026-66908/index.md","name":"CVE-2026-66908","record":{"aliases":["GHSA-fpm2-m4qq-wghr"],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":true,"product_category":"Apache Camel HTTP component","requires_auth":"none","summary":"Apache Camel HTTP server accepts unexpired JWTs without validating issuer or audience claims if configured with a keystore but no specific issuer/audience settings.","user_interaction":"not_required","vuln_class":"auth_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"apache","cpe":[{"product":"camel","vendor":"apache"}],"cvss":{"score":7.5,"severity":"high","source":"cisa-adp","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","version":"3.1"},"cwes":[{"id":"CWE-287","name":"Improper Authentication"}],"description":"Improper Authentication vulnerability in Apache Camel Platform HTTP Main component.\n\nThis issue affects Apache Camel: from 4.8.0 before 4.22.0.\n\nThe camel-main embedded HTTP server can protect its endpoints with JWT authentication, configured through authenticationEnabled together with the JWT keystore properties. JWTAuthenticationConfigurer.buildJwtOptions returned null when neither jwtIssuer nor jwtAudience was configured, and the caller then skipped the JWTAuthOptions.setJWTOptions call entirely, so the Vert.x JWTAuth instance was built from the keystore alone. The result was that inbound tokens were checked only for signature and expiry: the iss and aud claims were not validated at all. Nothing signalled this - the server started normally and reported no warning - so a deployment configured the documented way silently enforced less than the operator believed it had enabled, and the component documentation itself presented signature and expiry checking as the default with issuer and audience as an optional extra. Both the application server and the management server were affected, because the omission was in each of the two configureAuthentication paths. Any unexpired token signed by any key the configured keystore trusts was therefore accepted, regardless of which issuer minted it or which audience it was intended for. How far that reaches depends on the trust set of the keystore: where the signing key belongs to a shared or multi-tenant identity provider, a token legitimately issued for an entirely different audience is accepted, while a keystore holding a dedicated signer narrows it to reuse of tokens minted for other services within the same trust domain. The jwtIssuer and jwtAudience options did not exist before 4.21.0, so on earlier releases there was no supported way to have these claims enforced at all.\n\nUsers are recommended to upgrade to version 4.22.0, which fixes the issue. From 4.22.0 the server refuses to start when a JWT keystore is configured but neither jwtIssuer nor jwtAudience is set, naming the properties involved, and a deployment that genuinely wants signature and expiry validation only must say so explicitly with the new jwtAllowMissingIssuerAndAudience option, which defaults to false. This behaviour is fixed only on 4.22.0. The 4.14.9 and 4.18.4 releases do not change the default: they add the jwtIssuer and jwtAudience options so that operators on those maintenance lines can enforce the claims by configuration, and an installation that upgrades to 4.14.9 or 4.18.4 without also setting at least one of those two properties is still accepting any unexpired token signed by a trusted key. Users on 4.14.x or 4.18.x should therefore upgrade to 4.14.9 or 4.18.4 and then set jwtIssuer, jwtAudience, or both. Releases from 4.8.0 up to and including 4.21.x offer no way to enforce these claims and should be moved to a version that does. Independently of version, restrict the JWT keystore to the smallest possible trust set - ideally a signer dedicated to this service rather than a shared identity-provider key - and where a gateway already validates issuer and audience in front of the server, ensure it cannot be bypassed.\n\nNotes:\n\nThe JIRA ticket:  https://issues.apache.org/jira/browse/CAMEL-24281  refers to the various commits that resolved the issue, and has more details.\n\nThe fail-closed guard could not be backported. The jwtIssuer and jwtAudience options were themselves only introduced in 4.21.0 by CAMEL-23525, so on camel-4.18.x and camel-4.14.x there was nothing an operator could set to satisfy the requirement and the guard would have broken every JWT deployment on those branches with no remedy available.","ecosystems":["Maven"],"exploits":{"exploitdb":0,"first_seen":"2026-08-24","github_poc":1,"max_poc_stars":0,"metasploit":0,"nuclei":0,"refs":[{"date":"2026-08-24T15:04:38Z","kind":"github_poc","ref":"https://github.com/oscerd/CVE-2026-66908","stars":0,"title":"Reproducer for CVE-2026-66908 (Apache Camel camel-platform-http-main JWT iss/aud not validated) — standalone camel-main"}],"tier":"poc_unverified"},"has_fix":true,"headline":"Apache Camel-platform-http-main: when JWT authentication was configured with a keystore but no issuer or audience, the iss and aud claims were never validated, so any unexpired token signed by a trusted key was accepted","id":"CVE-2026-66908","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"Maven","product":"apache:camel","products":["apache:camel"],"type":"auth_bypass","year":"2026"},"n_packages":2,"n_references":1,"next":{"headline":"Apache CXF: Unsafe deserialization of inbound JMS ObjectMessage","id":"CVE-2026-66909"},"packages":[{"ecosystem":"Maven","fixed":["4.22.0"],"introduced":["4.8.0"],"last_affected":[],"package":"org.apache.camel:camel-platform-http-main","purl":null,"source":"GHSA-fpm2-m4qq-wghr"},{"ecosystem":"Maven","fixed":["4.22.0"],"introduced":["4.8.0"],"last_affected":[],"package":"org.apache.camel:camel-platform-http-main","purl":"pkg:maven/org.apache.camel/camel-platform-http-main","source":"GHSA-fpm2-m4qq-wghr"}],"prev":{"headline":"Apache Camel-Google-Storage: the consumer appended the remote object name to the configured downloadFileName directory without constraining the result","id":"CVE-2026-66907"},"products":["Apache Camel"],"published":"2026-08-24","related":[{"cvss_score":10,"headline":"Apache camel-coap allows header injection that can lead to remote code execution","id":"CVE-2026-33453","kev_date_added":null,"published":"2026-04-27"},{"cvss_score":9.9,"headline":"Apache Camel has an incomplete fix for CVE-2025-27636","id":"CVE-2026-40453","kev_date_added":null,"published":"2026-04-27"},{"cvss_score":9.8,"headline":"Apache Camel K: Camel K Tenant repositories reach Maven execution inside operator pod","id":"CVE-2026-80351","kev_date_added":null,"published":"2026-09-10"},{"cvss_score":9.8,"headline":"Apache Camel K: Camel K Master trait serviceAccountName YAML injection lets CR author apply arbitrary objects","id":"CVE-2026-80352","kev_date_added":null,"published":"2026-09-10"},{"cvss_score":9.8,"headline":"Apache Camel: Camel-Atmosphere-Websocket: WebSocket dispatch header injection","id":"CVE-2026-71300","kev_date_added":null,"published":"2026-08-24"},{"cvss_score":9.8,"headline":"Apache Camel-Undertow: the endpoint discarded the undertow-specific header filter strategy in favour of the base HTTP one, so the undertow filtering never ran on endpoint-configured routes","id":"CVE-2026-78329","kev_date_added":null,"published":"2026-08-24"},{"cvss_score":9.8,"headline":"Apache Camel-PQC: The AWS Secrets Manager key-lifecycle manager deserializes persisted key metadata with java.io.ObjectInputStream and no ObjectInputFilter","id":"CVE-2026-43867","kev_date_added":null,"published":"2026-07-06"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"},{"class":"open","licence":"CC0","name":"PoC-in-GitHub"}],"ssvc":{"automatable":"yes","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-25","vendors":["Apache Software Foundation"]},"summary":"Apache Camel HTTP server accepts unexpired JWTs without validating issuer or audience claims if configured with a keystore but no specific issuer/audience settings.","url":"https://insights.sbomify.com/CVE-2026-66908/"}