WaratekVRT Sign in

CVE-2026-55994 Apache Camel

Affected softwareApache Camel
Severity7.5 High CVSS 3.1
Fixed in4.18.3, 4.21.0
WeaknessServer-side request forgery (CWE-918)
Published6 Jul 2026
Updated9 Jul 2026

Description

Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Iggy component. The camel-iggy consumer mapped the user-headers of inbound Iggy messages into the Camel Exchange header map without applying any HeaderFilterStrategy (IggyFetchRecords copied the message user-headers straight into the Exchange). Because nothing blocked the Camel header namespace, an actor able to publish to the consumed Iggy stream/topic could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as message user-headers. In a route where the Iggy consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets. This issue affects Apache Camel: from 4.17.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix adds a dedicated IggyHeaderFilterStrategy (and a headerFilterStrategy endpoint option) that filters the Camel header namespace case-insensitively on inbound mapping, so externally-supplied Camel* / camel* headers are no longer copied into the Exchange. For deployments that cannot upgrade immediately, strip the Camel control headers from the inbound message before they reach any downstream producer (for example removeHeaders('Camel*') and removeHeaders('camel*') at the start of the route), restrict who can publish to the consumed Iggy stream/topic, and avoid bridging an untrusted consumer directly into an HTTP producer whose target URI can be driven from message headers.

CWE-20 · Improper input validationCWE-200 · Information exposure

Exploitation status

No public exploit

No exploit has been reported in the sources we check. The 1 repository below are public GitHub repositories with fewer than 5 stars.

  • CISA KEV not listed
  • VulnCheck KEV not listed
  • CISA Vulnrichment exploitation: none
  • Indexed PoC 1 indexed, none at 5+ stars
  • EPSS 0.62% chance in 30 days

1 of these are GitHub repositories with fewer than 5 stars. They are listed for reference and don't count toward the exploitation status above.

IndexArtifactStarsFirst seen
GitHub PoC PoC reproducer for CVE-2026-55994 (Apache Camel camel-iggy): the consumer copies an Iggy message's user-headers onto the Exchange unfiltered, so an injected CamelHttpUri drives a server-side request (SSRF) and leaks resolved property placeholders. Fixed in 4.18.3/4.21.0. 2026-07-22

Waratek protection

No exploit published

Within Waratek scope. In the sources we check, nobody has published exploit code for this CVE or reported it being exploited.

A public code fix exists: apache/camel #23285.

  • Protection none
  • Action unverified
  • Review automated Upstream data
  • Record active
Decided by Exploit code for this candidate, published in a reviewed catalogue or a GitHub repository with 5 or more stars, or in use per CISA or VulnCheck; not only a CISA verdict, a forecast, or nothing at all
Finding This CVE is not listed in CISA KEV or VulnCheck KEV, CISA Vulnrichment records no active exploitation, no reviewed exploit catalogue carries an entry for it, and no GitHub PoC repository for it has 5 or more stars. Nobody has published exploit code worth tracing, so it is not a candidate for a rule ahead of the ones where somebody has; an upstream fix path does exist, so the remediation half of the candidacy still holds. This is a statement about what has been published, not about whether the defect is reachable or serious.

Affected software and releases

Maven packages

Affected and fixed versions, from OSV.dev
PackageIntroducedFixedLast affected
org.apache.camel:camel-iggy 4.17.0 4.18.3 unbounded
org.apache.camel:camel-iggy 4.19.0 4.21.0 unbounded

Products and versions

2 products, 4 version entries
SourceVendorProductSchemeAffected versions
nvd apache camel generic ≥ 4.17.0 and < 4.18.3 · ≥ 4.19.0 and < 4.21.0
osv org.apache.camel camel-iggy generic ≥ 4.17.0 and < 4.18.3 · ≥ 4.19.0 and < 4.21.0

References

URLTags
https://github.com/apache/camel/pull/23285 WEB
https://github.com/apache/camel/pull/23313 WEB
https://github.com/apache/camel/commit/1e776238202edb9d98972cff558e12b53e499647 WEB
https://github.com/apache/camel/commit/88c43e3af36013585b5483c671950f30e5833a5f WEB
https://camel.apache.org/security/CVE-2026-55994.html WEB
https://github.com/apache/camel PACKAGE
https://github.com/apache/camel/releases/tag/camel-4.18.3 WEB
https://github.com/apache/camel/releases/tag/camel-4.21.0 WEB
https://issues.apache.org/jira/browse/CAMEL-23532 WEB
http://www.openwall.com/lists/oss-security/2026/07/05/28 WEB

Timeline

Published2026-07-06By the CVE Program.
NVD record modified2026-07-09NVD's own last-modified date for this record.