Loading vulnerability…
CVE-2026-66907 is a relative path traversal vulnerability in the Apache Camel camel-google-storage consumer. Affected consumers that set downloadFileName and use its implicit, non-expression destination handling append the Google Cloud Storage object name verbatim to the configured local destination. The resulting path is used for the download without lexical normalization or verification that it remains beneath the intended directory. Because object names are obtained verbatim from the consumed bucket, an attacker who can introduce object names containing parent-directory segments can cause writes outside the configured download location. The flaw affects versions 4.0.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.x. It is limited to the consumer download path; the producer is not affected.
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.
Repository contains two self-contained Java proof-of-concept reproducers for CVE-2026-66907 in Apache Camel's camel-google-storage consumer: one under camel-spring-boot/ and one under camel-quarkus/. Both variants use Docker Compose to start a fake-gcs-server emulator on port 4443 and an application on port 8080. The exploit logic is the same in both stacks: seed bucket victim-bucket with a benign object and a malicious object whose name is ../../../../../../tmp/pwned-66907.txt, then let a vulnerable Camel google-storage consumer poll the bucket with downloadFileName=/app/downloads. Because affected Camel versions append the object name verbatim to the configured directory without normalization or containment checks, the malicious object escapes /app/downloads and is written to /tmp/pwned-66907.txt. The repository is a real exploit/reproducer rather than a scanner: it actively seeds the target storage service, triggers the vulnerable consumer behavior, and verifies arbitrary file write via an HTTP endpoint. Structure-wise, each subproject includes a Dockerfile, docker-compose.yml, Maven pom.xml, route definition, storage/emulator setup, and an observation endpoint. Spring Boot variant files: Application.java entry point, StorageConfig.java for emulator client and bucket seeding, VictimRoute.java for the vulnerable consumer, and ExploitController.java for reporting. Quarkus variant files: Constants.java, StorageProducer.java for the storage client bean, Seeder.java for bucket seeding, VictimRoute.java for the vulnerable consumer, and ExploitResource.java for reporting. Main exploit capability is arbitrary file write on the host/container filesystem through attacker-controlled cloud object names processed by a vulnerable consumer route.
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.
4 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.