Loading vulnerability…
CVE-2026-66908 is an improper authentication vulnerability in Apache Camel Platform HTTP Main JWT-protected embedded HTTP endpoints. When JWT authentication is enabled with a JWT keystore but neither jwtIssuer nor jwtAudience is configured, the JWT option-building path omits issuer and audience settings. The resulting Vert.x JWT authentication instance validates token signatures and expiry only, without validating the iss or aud claims. The condition affects both the application and management HTTP server authentication paths. It affects Apache Camel Platform HTTP Main from 4.8.0 before 4.22.0 under the affected configuration.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a runnable Java proof-of-concept for CVE-2026-66908 affecting Apache Camel's camel-platform-http-main component used by camel-main. It is not part of a common exploit framework. The repo contains a top-level README plus a single runnable subproject under camel-main/ with Maven build files, Docker artifacts, and three Java classes implementing the vulnerable server and exploit flow. Structure and purpose: MainApp.java starts a standalone camel-main embedded HTTP server on 0.0.0.0:8080 with JWT authentication enabled from a JKS keystore, but intentionally omits jwtIssuer and jwtAudience. AppRoutes.java defines two platform-http routes: /protected, which is JWT-protected, and /exploit, which is left open and invokes the exploit processor. ExploitProcessor.java is the core exploit logic: it loads the same trusted keystore, generates JWTs via Vert.x JWTAuth with attacker-controlled claims (iss=https://attacker.example, aud=some-unrelated-service), then sends HTTP requests to http://localhost:8080/protected with no token, a forged valid token, and an expired token. Main exploit capability: authentication bypass of issuer/audience validation. On affected Camel versions, the embedded HTTP server validates only JWT signature and expiry when configured from a keystore alone, so a token signed by the trusted key but intended for a different issuer/audience is still accepted. The exploit demonstrates this by obtaining HTTP 200 from /protected using a token with foreign iss/aud, while no-token and expired-token requests return 401. Operational characteristics: this is an operational PoC rather than a weaponized exploit. It includes a working payload (forged JWTs) and self-tests the vulnerable condition locally. It does not provide remote code execution or persistence; its outcome is unauthorized access to a protected HTTP resource under a specific misconfiguration/vulnerable-version combination. The Dockerfile and docker-compose.yml make the reproducer easy to build and run in a containerized environment.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
3 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.