A newly disclosed vulnerability in Apache Camel’s Iggy component could allow an attacker with publish access to a message stream to hijack downstream HTTP requests and exfiltrate sensitive secrets, all without direct access to the affected server.
Tracked as CVE-2026-55994 and rated “important,” the flaw stems from a missing security control that most integration developers would assume was already in place.
The issue was disclosed on July 5, 2026, via the oss-security mailing list by Andrea Cosentino, with credit for discovery going to researcher Kamalpreet Singh.
Apache Camel is a widely used integration framework that routes data between systems using a component-based architecture. The camel-iggy component connects Camel routes to Iggy, a message streaming platform, acting as a consumer that pulls messages and feeds them into Camel’s internal processing pipeline, the Exchange.
The vulnerability lives in how that consumer handles message metadata. When IggyFetchRecords pulled messages from an Iggy stream, it copied the user-supplied headers directly into the Camel Exchange’s header map without running them through a HeaderFilterStrategy. This filtering mechanism is designed to prevent external data from masquerading as Camel’s internal control signals.
Without that filter, anyone able to publish messages to the consumed stream could set Camel-reserved headers, most critically CamelHttpUri, which controls where a downstream HTTP producer sends its request.
In a typical Camel route, data flows from a consumer into one or more processors and eventually to a producer that performs an action such as making an HTTP call.
If that route bridges an Iggy consumer to an HTTP producer, an attacker’s injected CamelHttpUri header overrides the intended destination.
This gives the attacker two attack primitives in one:
- Server-side request forgery: the compromised route can be redirected to internal-only services, admin interfaces, or cloud metadata endpoints (like AWS’s 169.254.169.254) that are normally unreachable from outside the network.
- Secret disclosure: Camel resolves property placeholders on the final URI before sending the request. If the attacker embeds a placeholder referencing an environment variable, application property, or vault secret, Camel dutifully resolves it and sends the real value to the attacker-controlled destination.
That second point is what elevates this beyond a standard SSRF bug; it’s a built-in exfiltration channel that requires no additional exploitation step.
The vulnerability affects:
- Apache Camel (org.apache.camel:camel-iggy) 4.17.0 through 4.18.2
- Apache Camel (org.apache.camel:camel-iggy) 4.19.0 through 4.20.x
Users should upgrade to 4.21.0, or 4.18.3 if staying on the 4.18.x branch. Both releases introduce a dedicated IggyHeaderFilterStrategy that case-insensitively blocks any externally-supplied Camel* or camel* headers from reaching the Exchange, along with a new headerFilterStrategy endpoint option for custom filtering needs.
Teams unable to patch right away can reduce exposure with these interim steps:
- Add
removeHeaders("Camel*")andremoveHeaders("camel*")at the start of the route, before any downstream processing occurs. - Restrict which identities or services can publish to the consumed Iggy stream or topic.
- Avoid architectures that bridge an untrusted Iggy consumer directly to an HTTP producer whose target URI can be influenced by message headers.
Given how common consumer-to-HTTP-producer patterns are in event-driven architectures, organizations running camel-iggy in production should treat this as a priority patch rather than a routine maintenance update, particularly if any part of the pipeline touches untrusted or externally-writable streams.
About the Author
