Apache Camel
Monthly
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remote senders smuggle legacy 'websocket.' dispatch headers across the undertow transport boundary. Because UndertowEndpoint overwrote the UndertowHeaderFilterStrategy with the base HttpHeaderFilterStrategy, undertow-specific filtering never ran on endpoint-configured routes, so an undertow HTTP consumer maps attacker-controlled 'websocket.*' wire headers onto the Exchange and a downstream undertow WebSocket producer can be steered to deliver to a peer other than the one the route selected. No public exploit identified at time of analysis, EPSS is low (0.16%, 5th percentile), and the fix is available from Apache.
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket message dispatch in routes that bridge an HTTP consumer into the producer. Because the dispatch headers (websocket.connectionKey, websocket.connectionKey.list, websocket.sendToAll, websocket.eventType, websocket.errorType) use dotted names outside the filtered Camel namespace, the inherited HttpHeaderFilterStrategy admits them in both directions, so an attacker-supplied header overrides the recipient the route selected - suppressing a notification meant for one client or redirecting it to another client whose connection key the sender knows. No public exploit identified at time of analysis; EPSS is low (0.23%, 13th percentile) and it is not in CISA KEV, though the vendor rates it CVSS 9.8.
Header injection via structured-mode CloudEvents in Apache Camel's Knative consumer enables unauthenticated SSRF, path traversal, and message-dispatch redirection against routes that forward to header-driven components. The flaw exists because CloudEvent extension fields in structured content mode (Content-Type: application/cloudevents+json) are copied directly into Camel Exchange headers without applying the KnativeHttpHeaderFilterStrategy that correctly guards the binary content-mode path - an incomplete fix of the same filter-bypass pattern addressed across multiple related CVEs (CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453, CVE-2026-47323). No public exploit or CISA KEV listing has been identified at time of analysis, but the attack surface - unauthenticated HTTP POST to a Knative endpoint - requires no special tooling.
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constraints when neither jwtIssuer nor jwtAudience is configured, causing the embedded Vert.x HTTP server to accept any unexpired token signed by any key in the trusted keystore. Affected are Apache Camel versions 4.8.0 through 4.21.x across both the application server and management server paths. An attacker who possesses a valid JWT from any identity provider trusted by the configured keystore - such as a token legitimately issued for a different service in a shared IdP environment - can authenticate to the Camel HTTP endpoints without holding credentials intended for that service. No public exploit has been identified at time of analysis, and CISA KEV listing is absent.
Arbitrary file write via path traversal in the Apache Camel Google Cloud Storage consumer component affects versions 4.0.0 through 4.21.x, allowing anyone who can influence GCS bucket object names to cause the Camel process to create or overwrite files outside the configured download directory. The consumer appends blob names verbatim to the local path using the unsanitized ${file:name} token without directory containment checks, and the filter option that could restrict object names is disabled by default. No public exploit is identified at time of analysis; SSVC rates the flaw automatable once malicious object names are present in the consumed bucket, and vendor-released patches are available at 4.14.9, 4.18.4, and 4.22.0.
Arbitrary file write via path traversal in the Apache Camel camel-azure-storage-blob component lets an attacker who can influence blob names in a consumed Azure Storage container force Camel to create or overwrite files outside the configured download directory, with the privileges of the Camel process. It affects Apache Camel 4.0.0 before 4.14.9, 4.15.0 before 4.18.4, and 4.19.0 before 4.22.0, where BlobOperations.downloadBlobToFile joined the fileDir option with the raw remote blob name without normalization or containment checks. No public exploit has been identified at time of analysis and the CVSS is 9.1, but EPSS is low (0.18%, 7th percentile), indicating no observed exploitation activity yet.
Path traversal in Apache Camel's camel-azure-storage-datalake component allows anyone with write access to a consumed Azure Data Lake Storage Gen2 filesystem to direct the Camel process to write or overwrite files at arbitrary locations on the local filesystem. The downloadToFile operation constructs local paths by joining the configured fileDir with the remote file name exactly as returned by the Azure SDK - without lexical normalization or any boundary check - meaning a remote path name containing parent-directory segments (e.g., '../../etc/cron.d/payload') resolves outside fileDir. Depending on what the Camel process can write, this integrity violation can escalate to code execution or service disruption. No active exploitation has been identified at time of analysis, and vendor-released patches are available in versions 4.14.9, 4.18.4, and 4.22.0.
MIME header injection in Apache Camel's camel-mail MimeMultipart data format allows unauthenticated network senders to plant Camel-internal namespace headers onto the Camel Exchange when headersInline is set to true, potentially redirecting what downstream route components - such as camel-sql - execute. Versions 2.17.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.x are affected across all release lines until the current fixes. No public exploit code or active exploitation has been identified; EPSS sits at 0.16% and SSVC rates exploitation status as none, making this a patch-priority rather than emergency-response item for most organizations.
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.
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize) lets an attacker who can write to the backing Consul KV store achieve arbitrary code execution inside the Camel process. Any deployment using a Consul-backed Camel registry on versions 3.0.0 up to 4.14.6 or 4.15.0 up to 4.18.1 is affected. There is no public exploit identified at time of analysis, EPSS is low (0.08%), and this is a missed instance of the same deserialization class fixed in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747.
Remote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0) allows an unauthenticated attacker to inject arbitrary internal Camel headers via CoAP URI query parameters, achieving OS command execution when a route forwards to a header-sensitive producer such as camel-exec. The component maps incoming CoAP query parameters straight into Exchange message headers with no HeaderFilterStrategy, so a single UDP packet to port 5683 can override the executable and arguments of a downstream exec producer and return command output in the CoAP response. Rated CVSS 10.0 with publicly available exploit code, though EPSS remains modest (0.55%, 68th percentile) and CISA SSVC records no observed exploitation, indicating opportunity rather than confirmed mass exploitation.
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an attacker who can email a monitored mailbox smuggle Camel-prefixed MIME headers into the Exchange. Because MailHeaderFilterStrategy filters only the outbound direction and never sets an inbound filter, inbound Camel headers reach downstream components such as camel-bean, camel-exec, or camel-sql where they can alter route behavior, potentially reaching command or query execution. There is no public exploit identified at time of analysis and EPSS is very low (0.02%), but the vendor rates it CVSS 9.4 and SSVC marks it automatable.
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoStream-based remote aggregation repository reads objects from an Infinispan cache using java.io.ObjectInputStream with no ObjectInputFilter applied. Any attacker able to write to the backing Infinispan cache can plant a malicious serialized gadget that executes in the application context during routine get/recover operations. Publicly available exploit code exists, though EPSS is low (0.08%) and there is no evidence of active exploitation.
Header-filter bypass in the Apache Camel Undertow component (4.11.0-4.14.8, 4.15.0-4.18.3, and 4.19.0-4.21.x) lets remote senders smuggle legacy 'websocket.' dispatch headers across the undertow transport boundary. Because UndertowEndpoint overwrote the UndertowHeaderFilterStrategy with the base HttpHeaderFilterStrategy, undertow-specific filtering never ran on endpoint-configured routes, so an undertow HTTP consumer maps attacker-controlled 'websocket.*' wire headers onto the Exchange and a downstream undertow WebSocket producer can be steered to deliver to a peer other than the one the route selected. No public exploit identified at time of analysis, EPSS is low (0.16%, 5th percentile), and the fix is available from Apache.
Header-injection in the Apache Camel camel-atmosphere-websocket producer lets an external sender hijack WebSocket message dispatch in routes that bridge an HTTP consumer into the producer. Because the dispatch headers (websocket.connectionKey, websocket.connectionKey.list, websocket.sendToAll, websocket.eventType, websocket.errorType) use dotted names outside the filtered Camel namespace, the inherited HttpHeaderFilterStrategy admits them in both directions, so an attacker-supplied header overrides the recipient the route selected - suppressing a notification meant for one client or redirecting it to another client whose connection key the sender knows. No public exploit identified at time of analysis; EPSS is low (0.23%, 13th percentile) and it is not in CISA KEV, though the vendor rates it CVSS 9.8.
Header injection via structured-mode CloudEvents in Apache Camel's Knative consumer enables unauthenticated SSRF, path traversal, and message-dispatch redirection against routes that forward to header-driven components. The flaw exists because CloudEvent extension fields in structured content mode (Content-Type: application/cloudevents+json) are copied directly into Camel Exchange headers without applying the KnativeHttpHeaderFilterStrategy that correctly guards the binary content-mode path - an incomplete fix of the same filter-bypass pattern addressed across multiple related CVEs (CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453, CVE-2026-47323). No public exploit or CISA KEV listing has been identified at time of analysis, but the attack surface - unauthenticated HTTP POST to a Knative endpoint - requires no special tooling.
JWT claim validation in Apache Camel's Platform HTTP Main component silently fails to enforce issuer and audience constraints when neither jwtIssuer nor jwtAudience is configured, causing the embedded Vert.x HTTP server to accept any unexpired token signed by any key in the trusted keystore. Affected are Apache Camel versions 4.8.0 through 4.21.x across both the application server and management server paths. An attacker who possesses a valid JWT from any identity provider trusted by the configured keystore - such as a token legitimately issued for a different service in a shared IdP environment - can authenticate to the Camel HTTP endpoints without holding credentials intended for that service. No public exploit has been identified at time of analysis, and CISA KEV listing is absent.
Arbitrary file write via path traversal in the Apache Camel Google Cloud Storage consumer component affects versions 4.0.0 through 4.21.x, allowing anyone who can influence GCS bucket object names to cause the Camel process to create or overwrite files outside the configured download directory. The consumer appends blob names verbatim to the local path using the unsanitized ${file:name} token without directory containment checks, and the filter option that could restrict object names is disabled by default. No public exploit is identified at time of analysis; SSVC rates the flaw automatable once malicious object names are present in the consumed bucket, and vendor-released patches are available at 4.14.9, 4.18.4, and 4.22.0.
Arbitrary file write via path traversal in the Apache Camel camel-azure-storage-blob component lets an attacker who can influence blob names in a consumed Azure Storage container force Camel to create or overwrite files outside the configured download directory, with the privileges of the Camel process. It affects Apache Camel 4.0.0 before 4.14.9, 4.15.0 before 4.18.4, and 4.19.0 before 4.22.0, where BlobOperations.downloadBlobToFile joined the fileDir option with the raw remote blob name without normalization or containment checks. No public exploit has been identified at time of analysis and the CVSS is 9.1, but EPSS is low (0.18%, 7th percentile), indicating no observed exploitation activity yet.
Path traversal in Apache Camel's camel-azure-storage-datalake component allows anyone with write access to a consumed Azure Data Lake Storage Gen2 filesystem to direct the Camel process to write or overwrite files at arbitrary locations on the local filesystem. The downloadToFile operation constructs local paths by joining the configured fileDir with the remote file name exactly as returned by the Azure SDK - without lexical normalization or any boundary check - meaning a remote path name containing parent-directory segments (e.g., '../../etc/cron.d/payload') resolves outside fileDir. Depending on what the Camel process can write, this integrity violation can escalate to code execution or service disruption. No active exploitation has been identified at time of analysis, and vendor-released patches are available in versions 4.14.9, 4.18.4, and 4.22.0.
MIME header injection in Apache Camel's camel-mail MimeMultipart data format allows unauthenticated network senders to plant Camel-internal namespace headers onto the Camel Exchange when headersInline is set to true, potentially redirecting what downstream route components - such as camel-sql - execute. Versions 2.17.0 through 4.14.8, 4.15.0 through 4.18.3, and 4.19.0 through 4.21.x are affected across all release lines until the current fixes. No public exploit code or active exploitation has been identified; EPSS sits at 0.16% and SSVC rates exploitation status as none, making this a patch-priority rather than emergency-response item for most organizations.
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.
Unsafe Java deserialization in Apache Camel's camel-consul component (ConsulRegistry / ConsulRegistryUtils.deserialize) lets an attacker who can write to the backing Consul KV store achieve arbitrary code execution inside the Camel process. Any deployment using a Consul-backed Camel registry on versions 3.0.0 up to 4.14.6 or 4.15.0 up to 4.18.1 is affected. There is no public exploit identified at time of analysis, EPSS is low (0.08%), and this is a missed instance of the same deserialization class fixed in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747.
Remote code execution in Apache Camel's camel-coap component (versions 4.14.0-4.14.5, 4.18.0 before 4.18.1, and 4.19.0) allows an unauthenticated attacker to inject arbitrary internal Camel headers via CoAP URI query parameters, achieving OS command execution when a route forwards to a header-sensitive producer such as camel-exec. The component maps incoming CoAP query parameters straight into Exchange message headers with no HeaderFilterStrategy, so a single UDP packet to port 5683 can override the executable and arguments of a downstream exec producer and return command output in the CoAP response. Rated CVSS 10.0 with publicly available exploit code, though EPSS remains modest (0.55%, 68th percentile) and CISA SSVC records no observed exploitation, indicating opportunity rather than confirmed mass exploitation.
Message header injection in Apache Camel's camel-mail component (3.0.0 before 4.14.6 and 4.15.0 before 4.18.1) lets an attacker who can email a monitored mailbox smuggle Camel-prefixed MIME headers into the Exchange. Because MailHeaderFilterStrategy filters only the outbound direction and never sets an inbound filter, inbound Camel headers reach downstream components such as camel-bean, camel-exec, or camel-sql where they can alter route behavior, potentially reaching command or query execution. There is no public exploit identified at time of analysis and EPSS is very low (0.02%), but the vendor rates it CVSS 9.4 and SSVC marks it automatable.
Unsafe Java deserialization in Apache Camel's camel-infinispan component allows arbitrary code execution when the ProtoStream-based remote aggregation repository reads objects from an Infinispan cache using java.io.ObjectInputStream with no ObjectInputFilter applied. Any attacker able to write to the backing Infinispan cache can plant a malicious serialized gadget that executes in the application context during routine get/recover operations. Publicly available exploit code exists, though EPSS is low (0.08%) and there is no evidence of active exploitation.