Apache Camel

Improper input validation in Apache Camel (versions through 4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.0) allows remote attackers to trigger information disclosure and limited integrity/availability effects against exposed Camel integration endpoints. The CVSS 3.1 base score is 7.3 (High) with a fully remote, unauthenticated vector, and the Apache-issued advisory tags the flaw as Information Disclosure. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the network-reachable, no-privilege vector warrants prompt patching.

Improper input validation in Apache Camel - the open-source Java integration framework - affects versions through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.0, and per the Apache-published advisory carries partial (Low) impact to confidentiality, integrity, and availability. Tagged as an Information Disclosure issue, it is remotely reachable per the CVSS network vector and appears to let a remote attacker submit malformed input that the framework fails to properly validate, potentially exposing limited data or perturbing message processing. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Improper input validation in Apache Camel versions 4.8.0 through 4.18.2 and 4.19.0 through 4.20.0 allows remote unauthenticated attackers to send crafted input that the framework fails to validate, yielding limited information disclosure and partial integrity/availability impact per the CVSS vector. The flaw is reported directly by the Apache Software Foundation and is fixed in 4.18.3 and 4.21.0; there is no public exploit identified at time of analysis and it is not on the CISA KEV list. The moderate 7.3 (High) score reflects easy network reachability but limited per-impact severity (C:L/I:L/A:L).

Untrusted JMS deserialization in Apache Camel's JMS-family components (camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, camel-activemq6) lets an attacker who can publish an ObjectMessage to a consumed queue or topic inject arbitrary Exchange state - body, IN/OUT headers, properties, variables, exchange id and exception - into a Camel route. It affects 3.0.0 through 4.14.7, 4.15.0 through 4.18.2, and 4.19.0 through 4.20.x when mapJmsMessage (the default) is enabled and Camel acts as a JMS consumer. This is a bypass of the earlier CVE-2026-40860 hardening, requires no gadget chain (only java.lang/java.util types), carries CVSS 7.3, and has no public exploit identified at time of analysis (EPSS 0.18%).

Java object deserialization in the Apache Camel camel-pqc component allows code execution in the key-management application when an attacker who can write to the backing AWS Secrets Manager secret stores a malicious serialized payload. The flaw affects Apache Camel 4.18.0-4.18.2 and 4.19.0-4.20.x, where AwsSecretsManagerKeyLifecycleManager.deserializeMetadata() calls a raw ObjectInputStream.readObject() with no class filter, so gadget side effects fire before the KeyMetadata cast. Rated CVSS 9.8 by Apache, but exploitation genuinely requires IAM write access to the specific secret; there is no public exploit identified at time of analysis and EPSS is low at 0.19% (8th percentile).

Confused-deputy operation redirection in the Apache Camel camel-cxf SOAP component (versions 4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0) lets an attacker steer which backend SOAP operation gets invoked. Because the operationName / operationNamespace selection headers lacked the Camel/camel prefix, HttpHeaderFilterStrategy failed to strip them at the HTTP boundary, so in any route bridging an HTTP consumer (e.g. platform-http) into a cxf: producer, an HTTP client could inject these headers and force CxfProducer to call a different WSDL operation than intended - for example swapping a read for a destructive write. No public exploit is identified at time of analysis, EPSS is low (0.15%), and it is not in CISA KEV.

Cypher injection in Apache Camel's camel-neo4j producer allows attackers who control JSON key names in the CamelNeo4jMatchProperties map to execute arbitrary Cypher queries against the connected Neo4j database, enabling unauthorized read, modification, or deletion of any node or relationship. The flaw exists across three release streams (4.10.0-4.14.7, 4.15.0-4.18.2, 4.19.0-4.20.x) and is a direct bypass of the partial fix introduced in CVE-2025-66169, which bound property values as query parameters but left property names (JSON keys) concatenated verbatim into the WHERE clause. No public exploit code or CISA KEV listing has been identified at time of analysis, though the prior related CVE in the same producer indicates recurring injection exposure in this component.

Remote code execution via unsafe Java deserialization affects the camel-pqc component of Apache Camel 4.18.0-4.18.2 and 4.19.0-4.20.x. The HashiCorp Vault and AWS Secrets Manager KeyLifecycleManager implementations (and a legacy-migration path in the file-based manager) read post-quantum key metadata back with a raw ObjectInputStream.readObject() lacking any ObjectInputFilter or allow-list, so a principal able to write to the key backend can plant a gadget object that executes during normal key-lifecycle operations. No public exploit has been identified at time of analysis and EPSS is low (0.19%), but SSVC rates technical impact as total; this is an incomplete-remediation follow-on to CVE-2026-40048.

Header injection in the Apache Camel camel-nats component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0-4.20.x) allows any NATS client that can publish to a consumed subject to inject arbitrary Camel-internal control headers into the Exchange because the consumer's default DefaultHeaderFilterStrategy has no inbound filter rules. An attacker can override headers such as CamelHttpUri, CamelFileName, or CamelSqlQuery to redirect HTTP producers, rename files, or alter queries in downstream route steps. No public exploit identified at time of analysis; EPSS is low (0.19%, 9th percentile) and CISA SSVC lists exploitation as none, but the flaw is remotely reachable without credentials when the NATS server runs with its default (no-auth) configuration.

Authentication token-lifetime bypass in the Apache Camel Keycloak component (camel-keycloak) affects versions 4.18.0-4.18.2 and 4.19.0-4.20.x, allowing expired or not-yet-valid Keycloak access tokens to be accepted as valid. The KeycloakSecurityHelper builds its TokenVerifier via withChecks() with only subject and issuer checks, so Keycloak's IS_ACTIVE exp/nbf validation is never installed, and any route relying on this helper will trust tokens outside their intended lifetime. NVD scores it CVSS 9.8, though EPSS is low (0.15%, 5th percentile) and there is no public exploit identified at time of analysis.

Unauthenticated Camel control-header injection in Apache Camel's camel-cometd component (4.0.0 before 4.14.8, 4.15.0 before 4.18.3, and 4.19.0 before 4.21.0) lets any client that completes a Bayeux/CometD handshake inject internal headers such as CamelHttpUri, CamelFileName or CamelJmsDestinationName into the Camel Exchange, hijacking the behaviour of downstream producers. Because a CometdComponent installs no Bayeux SecurityPolicy by default, no authentication is required (PR:N), and the injected headers survive internal direct/seda/vm hops. Reported by Apache with a fix in 4.21.0; there is no public exploit identified at time of analysis and EPSS is low at 0.19% (9th percentile).

Authorization bypass in Apache Camel's camel-elasticsearch-rest-client component allows unauthenticated remote attackers to override Elasticsearch query operations by injecting HTTP headers. Because the component uses unprefixed header constants ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') that are not blocked by Camel's inbound HttpHeaderFilterStrategy - which filters only 'Camel'-prefixed names - any HTTP client reaching a Camel route that fronts an elasticsearch-rest-client producer can substitute their own query body, operation type, or target index. Practical outcomes include full index enumeration via match_all, targeted document deletion, and field-level data exfiltration. No public exploit has been identified at time of analysis and this CVE is not listed in CISA KEV, but the attack requires no credentials and is trivially reproducible from the description alone.

Remote code execution in the Apache Camel camel-hazelcast component allows an attacker who can join or reach the Hazelcast cluster to run arbitrary code on every Camel node. The flaw exists because Camel-created Hazelcast instances apply no Java deserialization filter by default, so crafted serialized objects sent over the cluster protocol are deserialized (ObjectInputStream.readObject) before Camel processes them. It affects Camel 4.0.0-4.14.7, 4.15.0-4.18.2, and 4.19.0-4.20.x whenever a hazelcast consumer or repository uses Camel's own default configuration; there is no public exploit identified at time of analysis and EPSS is low (0.49%, 39th percentile).

Blind out-of-band data exfiltration in Apache Camel 4.14.0-4.20.x arises because the default ObjectInputFilter pattern bundled with several components ('java.**;javax.**;org.apache.camel.**;!*') uses a recursive java.** glob that allow-lists java.net.URL and java.net.InetAddress. Remote attackers who can deliver a Java-serialized payload to an affected Camel consumer - most notably the camel-jms family, where JmsBinding.extractBodyFromJms calls ObjectMessage.getObject() by default (mapJmsMessage=true) - can force the JVM to issue DNS queries to an attacker-controlled host during deserialization side-effects, yielding an observable out-of-band channel. Reported by Apache; there is no public exploit identified at time of analysis, EPSS is low (0.31%, 23rd percentile), and it is not listed in CISA KEV.

Remote code execution in Apache Camel's camel-vertx-http component (4.0.0-4.14.7, 4.15.0-4.18.2, 4.19.0) arises when a producer endpoint deserializes 5xx HTTP response bodies marked application/x-java-serialized-object through a raw java.io.ObjectInputStream with no class filtering. Exploitation is limited to non-default deployments where transferException=true or allowJavaSerializedObject=true is set and throwExceptionOnFailure remains true, letting an attacker who controls or intercepts the backend deliver a malicious serialized object and, given a gadget chain on the classpath, run code on the Camel host. This is a vendor-reported (Apache) issue with a publicly available advisory; there is no public exploit identified at time of analysis and EPSS is low at 0.39% (31st percentile).

Argument injection and directory traversal in Apache Camel's camel-docling component (4.15.0 before 4.18.3) let attackers who can influence the CamelDoclingCustomArguments or path-bearing exchange headers inject unintended docling CLI flags and traversal-laden path values into the externally executed docling tool. Because the original DoclingProducer validation relied on a flag denylist and only rejected literal '../' sequences, crafted arguments could reach the subprocess and resolve files outside the intended directory, yielding high confidentiality and integrity impact but no OS command injection (ProcessBuilder uses the list form, so no shell interprets the values). There is no public exploit identified at time of analysis and the flaw is not in CISA KEV; EPSS is low (0.79%, 52nd percentile).

Remote code execution in Apache Camel 3.18.0-4.14.5 and 4.15.0-4.18.1 stems from CXF and Knative HeaderFilterStrategy implementations filtering only outbound Camel-internal headers while leaving inbound traffic unfiltered, letting unauthenticated attackers inject control headers such as CamelExecCommandExecutable and CamelFileName through HTTP requests to CXF-RS, CXF-SOAP, or Knative HTTP endpoints. When such routes pipe into header-driven components like camel-exec or camel-file, the injected headers override configured values, yielding RCE or arbitrary file writes. No public exploit identified at time of analysis, but EPSS sits at only 0.04% despite the 9.8 CVSS - this is the fifth iteration of the same header-injection pattern (CVE-2025-27636, 2025-29891, 2025-30177, 2026-40453), so prior PoCs for sibling CVEs are likely portable.

The ConsulRegistry in the camel-consul component (class org.apache.camel.component.consul.ConsulRegistry and its inner ConsulRegistryUtils.deserialize method) read Java-serialized values from the Consul KV store and passed them to ObjectInputStream.readObject() without configuring an ObjectInputFilter. An attacker who can write to the Consul KV store backing a Camel ConsulRegistry instance could inject a malicious serialized Java object that is deserialized the next time Camel performs a lookup against that registry, leading to arbitrary code execution in the Camel process. The issue mirrors the class of vulnerability already addressed for other Camel components in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747, and was overlooked during the original remediation of those CVEs. This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1. Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.1.

Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Apache Camel Camel-Coap component. Apache Camel's camel-coap component is vulnerable to Camel message header injection, leading to remote code execution when routes forward CoAP requests to header-sensitive producers (e.g. camel-exec) The camel-coap component maps incoming CoAP request URI query parameters directly into Camel Exchange In message headers without applying any HeaderFilterStrategy.   Specifically, CamelCoapResource.handleRequest() iterates over OptionSet.getUriQuery() and calls camelExchange.getIn().setHeader(...) for every query parameter. CoAPEndpoint extends DefaultEndpoint rather than DefaultHeaderFilterStrategyEndpoint, and CoAPComponent does not implement HeaderFilterStrategyComponent; the component contains no references to HeaderFilterStrategy at all. As a result, an unauthenticated attacker who can send a single CoAP UDP packet to a Camel route consuming from coap:// can inject arbitrary Camel internal headers (those prefixed with Camel*) into the Exchange. When the route delivers the message to a header-sensitive producer such as camel-exec, camel-sql, camel-bean, camel-file, or template components (camel-freemarker, camel-velocity), the injected headers can alter the producer's behavior. In the case of camel-exec, the CamelExecCommandExecutable and CamelExecCommandArgs headers override the executable and arguments configured on the endpoint, resulting in arbitrary OS command execution under the privileges of the Camel process. The producer's output is written back to the Exchange body and returned in the CoAP response payload by CamelCoapResource, giving the attacker an interactive RCE channel without any need for out-of-band exfiltration.                                                                                                                                                                         Exploitation prerequisites are minimal: a single unauthenticated UDP datagram to the CoAP port (default 5683). CoAP (RFC 7252) has no built-in authentication, and DTLS is optional and disabled by default. Because the protocol is UDP-based, HTTP-layer WAF/IDS controls do not apply. This issue affects Apache Camel: from 4.14.0 through 4.14.5, from 4.18.0 before 4.18.1, 4.19.0. Users are recommended to upgrade to version 4.18.1 or 4.19.0, fixing the issue.

The Camel-Mail component is vulnerable to Camel message header injection. The custom header filter strategy used by the component (MailHeaderFilterStrategy) only filters the 'out' direction via setOutFilterStartsWith, while it does not configure the 'in' direction via setInFilterStartsWith. As a result, when a Camel application consumes mail through camel-mail (for example via from(\"imap://...\") or from(\"pop3://...\")) the inbound filter check is skipped and Camel-prefixed MIME headers are mapped unfiltered into the Exchange. An attacker who can deliver an email to a mailbox monitored by such a consumer can inject Camel-specific headers that, for some Camel components downstream of the mail consumer (such as camel-bean, camel-exec, or camel-sql), can alter the behaviour of the route. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177) and the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891). This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1. Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.1. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6.

The camel-infinispan component's ProtoStream-based remote aggregation repository deserializes data read from a remote Infinispan cache using java.io.ObjectInputStream without applying any ObjectInputFilter. An attacker who can write to the Infinispan cache used by a Camel application can inject a crafted serialized Java object that, when read during normal aggregation repository operations such as get or recover, results in arbitrary code execution in the context of the application. This issue affects Apache Camel: from 4.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2. The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23322 refers to the various commits that resolved the issue, and have more details. This issue follows the same class of vulnerability previously addressed in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747.