Apache Camel
Monthly
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to remote code execution in the Camel process. Any host that can reach the JGroups cluster's multicast group or bind port - adjacent network only, given the default UDP multicast stack - can join without credentials and deliver a crafted serialized object that JGroups deserializes on its own receive thread before Camel's routing logic ever runs. Code execution still depends on a usable gadget chain being present on the application classpath and on no JVM-wide -Djdk.serialFilter being configured, which is why the issue is assessed as high rather than critical; no public exploit code or confirmed active exploitation was identified at time of analysis. Deployments that explicitly configure a channel/channelProperties with AUTH and encryption, or that set a JVM-wide serialization filter, are not exploitable through this path.
XML external entity injection in the camel-smooks component of Apache Camel (versions 4.7.0 through 4.18.4 and 4.19.0 through 4.22.0) lets remote attackers who can supply or influence an XML message body that is unmarshalled by Smooks read files accessible to the Camel process and force it to issue requests to internal network hosts. No privileges or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N), and no non-default configuration is needed because external entity resolution was the default behaviour of the Woodstox SAX reader Smooks used; the confidentiality impact is high with a low availability impact, giving a base score of 8.2. The flaw is only reachable on routes that unmarshal XML through .unmarshal().smooks(...) or the smooks: component with its default reader, and full return of exfiltrated content depends on an InOut route binding the resolved entity into the reply, so no public exploit code or active exploitation has been identified at time of analysis, though the vendor has released fixed versions.
Credential disclosure in the Apache Camel camel-http component lets a malicious or compromised remote endpoint harvest OAuth2 bearer tokens and basic/digest credentials by answering a request with an HTTP redirect to a host it controls. The leak occurs because OAuth2ClientConfigurer's request interceptor sits in ProtocolExec, below RedirectExec, so 'Authorization: Bearer' headers are re-attached on every redirect hop, and because basic/digest credentials were registered against an AuthScope that matched any host. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0; exploitation requires an endpoint with credentials configured and followRedirects=true (not the default) plus an attacker positioned to influence the target server's responses, and no public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
XML external entity injection in the Apache Camel XPath component lets unauthenticated remote attackers read files accessible to the Camel process and induce it to make outbound requests to attacker-named hosts when an expression is configured with documentType=InputSource and evaluates XML from an untrusted sender. The flaw is configuration-gated rather than default: Camel's default document type already refuses a DOCTYPE, so stock deployments are not exposed, but a deployment that selected InputSource for streaming reasons unknowingly also selected a weaker parser. Fixed in 4.23.0, 4.18.5 and 4.22.1; no public exploit identified at time of analysis, and the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects confidentiality impact only.
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message on a transport feeding that endpoint to choose both the expression language and the predicate expression that Camel compiles and then evaluates against every exchange routed through the corresponding dynamic-router endpoint, running with the full privileges of the Camel process - effectively code execution. The issue affects Camel 4.4.0 through 4.18.4 and 4.19.0 through 4.22.0 (releases before 4.4.0 are not affected), scored CVSS 3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), so some access to the feeding transport is expected but no application-level authentication or user interaction is required. Exposure is limited to deployments that expose the control endpoint through a route forwarding messages from an external, shared or untrusted transport; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Unauthenticated remote AS2 partners can turn an Apache Camel camel-as2 receiver into a server-side request forgery pivot: the component reads the asynchronous Message Disposition Notification (MDN) return address out of the inbound message and dials it verbatim, so the sender chooses the host the Camel instance connects to, including addresses only routable from inside the deployment's network. Deployments running Apache Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 with an exposed camel-as2 receiver are affected; where mdnUserName, mdnPassword or mdnAccessToken are configured, the outbound receipt presents those MDN-delivery credentials to the attacker-chosen destination, which drives the high confidentiality component of the CVSS 3.1 score of 8.2 (CWE-918). No public exploit code has been identified at time of analysis, and vendor fixes are released in 4.23.0, 4.18.5 and 4.22.1; real-world urgency is moderated by whether the receiver is reachable by untrusted partners and whether credentials are attached to MDN delivery.
Authorization bypass in Apache Camel's camel-netty-http component allows remote unauthenticated attackers to reach protected routes by changing the case of characters in the request path so the security constraint no longer recognizes it while routing still dispatches to the endpoint. It affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1, with a CVSS score of 8.2; no public exploit identified at time of analysis.
Apache Camel's camel-oauth route guards fail open: when authentication cannot be completed, the OAuthBearerTokenProcessor and OAuthCodeFlow processors set an error status and body but never stop the exchange, so the request falls through and continues into the protected part of the route as if the caller had authenticated. Camel 4.11.0 through 4.18.4 and 4.19.0 through 4.22.0 are affected wherever camel-oauth is used to protect an HTTP-reachable endpoint, and exploitation needs no credentials, user interaction, or special configuration - simply omitting the Authorization header, sending a non-Bearer header, presenting an invalid token, or arriving without an authorization code is enough (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). The gap is a confidentiality problem first and foremost, exposing whatever the protected route returns, with limited integrity impact; no public exploit identified at time of analysis, and the vendor-released patch is 4.23.0, with backports in 4.18.5 and 4.22.1.
Path traversal in Apache Camel's remote-file consumers - the azure-files scheme named in this CVE plus the FTP/SFTP consumers sharing the RemoteFileConsumer base class - lets a malicious, compromised, or multi-tenant remote file server (or an on-path attacker on the integrity-free FTP control channel) cause Camel to read, delete, or rename files outside the directory it was configured to poll, using the endpoint's own credentials. Retrieval is reachable in the default consumer configuration because remote consumers download every listed file; deletion and renaming additionally require delete=true, move, preMove, moveFailed, or readLock=rename. The jailStartingDirectory option, enabled by default and documented as a boundary, did not constrain this remote operand before the fix, so it offered no protection; triggering the traversal requires control over a listing name returned by the server, and for azure-files specifically the Azure Files REST service does not normally return multi-segment names, making exploitation there impractical. No public exploit code or confirmed active exploitation was identified at time of analysis; vendor patches are available.
Path traversal in Apache Camel's remote-file consumers (including the SMB component's share-walking consumer) lets a directory listing entry that is not a single path segment resolve outside the polled remote directory, so Camel will retrieve, delete, or rename files outside that directory using the endpoint's own credentials. Affected are Camel 4.2.0 through 4.18.5-exclusive and 4.19.0 through 4.22.1-exclusive; file retrieval is reachable in a default consumer configuration, while deletion requires delete=true and renaming requires move, preMove, moveFailed, or readLock=rename. The CVSS 3.1 vector (7.4, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects unauthenticated reachability over the network with a high attack-complexity prerequisite: the remote server - or an on-path attacker rewriting an unprotected FTP LIST response, or a malicious, compromised, multi-tenant, or virtual-filesystem-backed server - must emit a qualifying listing name; for the SMB scheme a conforming SMB2 server will not do so, and no public exploit identified at time of analysis.
Path traversal in Apache Camel's remote-file consumers (the FTP, SFTP and mina-sftp schemes) lets a name reported in a remote server's directory listing resolve outside the directory Camel was configured to poll, so Camel will read, delete or rename files elsewhere using that endpoint's own credentials. Affected are Camel 4.18.0 through 4.18.4 and 4.19.0 through 4.22.0, with retrieval reachable in a default consumer configuration because remote consumers download every listed file (CVSS 3.1 base score 7.4, AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:N). The attacker must influence the LIST/SFTP listing output - via a malicious, compromised or multi-tenant server, a virtual-filesystem-backed server, or an on-path attacker against plaintext FTP whose control channel has no integrity protection - and no public exploit has been identified at time of analysis.
Apache Camel's ftp, ftps and sftp remote-file consumers build each file's remote path by concatenating the polled directory with the name returned in the server's directory listing, without any lexical normalization or containment check, so a listing entry containing parent-directory segments resolves outside the configured directory and is then read, deleted or renamed with the endpoint's own credentials. Affected are Camel 4.0.0 through 4.18.4, 4.19.0 through 4.22.0, and earlier; the 4.14.x stream is end-of-life and unfixed, while patches ship in 4.18.5, 4.22.1 and 4.23.0 (CPE: apache_software_foundation:apache_camel). Retrieval is reachable in a default consumer route, whereas deletion needs delete=true and renaming needs move, preMove, moveFailed or readLock=rename; the crucial caveat is that the jailStartingDirectory option, on by default and documented as confining Camel to the starting directory, does not constrain this remote path, so it cannot be used as a mitigation. There is confirmed no active exploitation tracked (not in CISA KEV) and no public exploit code identified at time of analysis, although the reporter privately demonstrated the issue end to end against an FTP endpoint; CVSS 7.4 with AC:H reflects that the attacker must first control or influence the remote server's LIST response rather than attack Camel directly.
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticated attacker who can either PUBLISH to a channel the route subscribes to, or write attacker-controlled bytes into a key the component later reads, to instantiate an arbitrary class graph in the application's JVM and execute its readObject method. Every release from 2.11.0 up to (but not including) 4.18.5 and 4.22.1 ships the affected default, which lazily builds a bare JdkSerializationRedisSerializer with no java.io.ObjectInputFilter whenever no serializer option is configured. No public exploit code was identified at time of analysis, but exploitation needs only a viable gadget on the classpath, which is why this carries CVSS 8.8 with high confidentiality and integrity impact.
Header-driven URI resolution in Apache Camel's HTTP producer components causes message-supplied CamelHttpUri and CamelRestHttpUri values to be expanded through CamelContext.resolvePropertyPlaceholders() before use, so an attacker who can influence those headers turns a URI string into a configuration-evaluation context and can read OS environment variables, JVM system properties, every registered secret-backend PropertiesFunction (AWS, Azure, GCP, HashiCorp, IBM, CyberArk, Kubernetes) and even invoke no-argument methods on beans in the registry. The flaw affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1 across camel-http, camel-http-common, camel-vertx-http, camel-undertow and camel-netty-http, and a plain static to(http://backend/api) route is enough to be exposed; no authentication is required where a route is reachable by untrusted senders (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). Exploitation yields a high-confidentiality but limited-integrity impact, and while no public exploit code or CISA KEV entry exists at time of analysis, the preconditions are ordinary and the vendor has shipped fixes, so this warrants prioritised patching.
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, where two self-built Hazelcast bootstrap paths create instances without the default JavaSerializationFilterConfig added for CVE-2026-43865. A route using ReplicatedHazelcastAggregationRepository without an injected hazelcastInstance, or a client-mode endpoint built by HazelcastDefaultComponent#getOrCreateHzClientInstance() when neither a ClientConfig nor hazelcastConfigUri is supplied, will accept and deserialize arbitrary Java objects published into the backing cluster, letting an attacker who can write into that cluster execute code before Camel ever processes the exchange. Hazelcast clusters ship without authentication or TLS by default, so the write prerequisite is often met in practice; no public exploit code or CISA KEV entry was identified at time of analysis, but the vendor has published fixed releases and the missing-filter condition requires no unsafe opt-in by the deployer.
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.
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.
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).
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.
External entity expansion (XXE) in Apache Camel's camel-fop component lets an unauthenticated remote sender who can deliver an XSL-FO body to a fop producer read files accessible to the Camel process and force that process to make outbound requests to attacker-named hosts. The flaw is conditional: FopProducer relies on TransformerFactory.newInstance() plus FEATURE_SECURE_PROCESSING, which is sufficient only for the JDK's built-in transformer, so exploitation requires a third-party JAXP factory such as Saxon-HE (typically pulled in via camel-xslt-saxon or camel-saxon) on the classpath - default camel-fop deployments are not affected. There is no public exploit code or CISA KEV entry identified at time of analysis, and the CVSS 6.5 score reflects high attack complexity and confidentiality-heavy impact (C:H/I:L) rather than easy mass exploitation; fixes are shipping via upstream PRs, but 4.14.x and earlier releases are end-of-life and will never receive one.
Apache Camel's camel-http OAuth2 client-credentials token cache is keyed only on the request URI, client ID and client secret, so two endpoints in the same JVM that differ solely in OAuth2 scope, resource indicator or token endpoint collide on one cache entry and one route can be served a token minted for another. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 with token caching enabled (oauth2CacheTokens=true) and at least two such OAuth2 endpoints configured; deployments with a single endpoint, or endpoints that also differ in URI or credentials, are not impacted. Rated CVSS 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, CWE-524), the practical consequence is authority confusion between the operator's own routes rather than an external attack path, and no public exploit identified at time of analysis; fixed in 4.23.0, 4.18.5 and 4.22.1.
Prefix confusion in Apache Camel's camel-platform-http component silently promotes ordinary HTTP endpoints to forwarding proxies, letting remote unauthenticated callers relay requests to targets they choose via the Host header and reach content the route author never intended to expose. Only Camel deployments running a platform-http route whose configured path begins with the five characters 'proxy' (for example proxyStats, proxy-health or proxying) while not intending the documented platform-http:proxy endpoint are affected - a developer-introduced naming condition that keeps attack complexity high and drives the modest CVSS 3.1 score of 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N). Default deployments without such endpoints are not exploitable, and no public exploit code or CISA KEV entry was identified at time of analysis.
Error responses from the Apache Camel gRPC consumer component can leak internal exception details to remote callers: when a route behind a gRPC consumer fails, the exception's message is copied into the gRPC status description, which is transmitted back across the wire rather than kept server-side like the status cause. Unauthenticated remote callers who can provoke a route failure on an affected deployment (Camel 4.0.0 before 4.18.5, or 4.19.0 before 4.22.1) may read class and package names, filesystem paths, host names and connection detail embedded in those messages, at CVSS 5.3 with confidential-impact-only. The leak is conditional on the exception text itself carrying sensitive content and on the gRPC consumer being reachable, so real-world exposure varies by route; there is no public exploit identified at time of analysis and no confirmed active exploitation. Vendor patches are published (4.23.0, plus LTS 4.18.5 and 4.22.1), and the fixed builds default a new muteException option to true so patched deployments stop leaking unless they explicitly opt out.
Unfiltered MIME headers in Apache Camel's camel-mail component (4.0.0 through 4.18.4 and 4.19.0 through 4.22.0) allow an external message sender to place mail.smtp.* / mail.smtps.* names onto the Camel Exchange when a multipart message is unmarshalled with the MimeMultipart data format and inline headers enabled. Because those names fall outside the Camel* namespace that consumer-side header filters block, they can steer how a downstream mail producer connects and sends, yielding low confidentiality and integrity impact (CVSS 6.5, network-reachable and unauthenticated per the CVSS:3.1/AV:N/AC:L/PR:N/UI:N vector). This is an incomplete fix of CVE-2026-46584 rather than a new defect class, so deployments that applied that earlier advisory and considered camel-mail settled remain exposed on this path; no public exploit code was identified at time of analysis and the vulnerable topology is a specific, non-default route configuration.
Apache Camel's Jetty HTTP component (camel-jetty / camel-jetty-common), in versions 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, installs Jetty's CrossOriginFilter with its stock defaults whenever an operator opts in with enableCORS=true, producing an allow-any-origin policy that also grants credentials instead of the empty policy operators expected to fill in. Unauthenticated remote attackers who lure a victim's browser to an attacker-controlled page (UI:R) can then perform credentialed cross-origin reads against the endpoint and read the responses, provided the victim already holds cookies or session credentials for that endpoint and the endpoint returns sensitive data. Exposure is configuration-dependent because it requires the non-default enableCORS=true opt-in on a Jetty endpoint; no public exploit code or active exploitation has been identified at time of analysis, and fixed versions 4.23.0, 4.18.5 and 4.22.1 have been released by the vendor.
Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 let a remote sender choose which saga their exchange joins by supplying the unprefixed 'Long-Running-Action' header, because the saga processor consulted that header on every exchange rather than only for saga services that participate in an external LRA protocol. The consequence is limited to deployments running sagas through the camel-lra component with a real LRA coordinator and a consumer that accepts inbound messages from untrusted senders: an attacker can attach a request to a long-running action started by someone else, or force compensation to be associated with an action they did not initiate, yielding low confidentiality and integrity impact (CVSS 4.8, AC:H). Vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1, and no public exploit has been identified at time of analysis.
The FileBasedKeyLifecycleManager in Apache Camel's PQC (post-quantum cryptography) component writes generated private key material to disk using whatever permissions the process umask produces instead of restricting the file to its owner, so on hosts with a permissive umask such as 022 the unencrypted private key is group- and world-readable. Affected are Apache Camel 4.12.0 through 4.18.4 and 4.19.0 through 4.22.0 that use this component to persist key material; an attacker who already holds a separate local account on the same host can read the key file and then forge signatures or break key exchanges performed by that deployment. The CVSS 3.1 vector (AV:L/PR:L/C:H) confines this to a local, authenticated party - no public exploit code has been identified at time of analysis and there is no CISA KEV listing - and the vendor assesses severity as low because the remote sender that Camel's threat model targets is not the exposure path.
Apache Camel's camel-keycloak security processor can accept a token minted by an issuer other than the configured one when token introspection is in use, the opt-in issuer validation is enabled, and the introspection endpoint returns an active response that omits the 'iss' claim - the check was skipped instead of failing. The flaw affects Apache Camel releases from 4.15.0 up to but not including 4.18.5, and from 4.19.0 up to but not including 4.22.1, specifically deployments using the camel-keycloak component with token introspection. Exploitation is unauthenticated per the CVSS vector (PR:N) but demands a non-default chain - introspection enabled, validateIssuer explicitly turned on, and a broker/gateway/minimal introspection endpoint that omits iss and serves multiple issuers - which caps the score at 4.8; no public exploit identified at time of analysis, and vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1.
Cross-partner signing-key confusion in the Apache Camel AS2 component (4.0.0 through 4.18.4 and 4.19.0 through 4.22.0) can cause a Message Disposition Notification to be signed with another trading partner's key when a multi-partner server handles concurrent or successive requests using dynamically fetched per-request keys. The issue is remotely reachable without authentication per the CVSS vector but has high attack complexity because exploitation depends on overlapping partner traffic through a shared ResponseMDN instance; it can expose signing material and misattribute receipts, with practical exposure limited to deployments serving multiple partners from one Camel context. No public exploit identified at time of analysis, and no KEV confirmation was provided in the supplied data.
Apache Camel's camel-mllp component writes HL7 clinical message payloads containing protected health information into ordinary application logs, because the logPhi option defaulted to true and two additional code paths logged payload content even when an operator had explicitly set logPhi=false. Deployments running Camel 4.0.0 through 4.18.4, or 4.19.0 through 4.22.0, that use the MLLP transport for healthcare integration are exposed out of the box; anyone who can read the resulting logs - local authenticated users per the CVSS vector (AV:L/PR:L, C:H) - can recover patient data that was never meant to land in general-purpose log storage with its broader retention, aggregation and access surface. This is a genuine data-exposure defect but a low-urgency one in attacker terms, since it is not remotely triggerable and merely requires pre-existing log read access; no public exploit code was identified at time of analysis, and vendor patches are available. Note that simply setting logPhi=false is not a complete workaround, as two code paths continue to log payloads until the fix is applied.
Apache Camel's CXF component leaks internal deployment detail back to SOAP clients when a route behind a CXF SOAP consumer fails with an exception that the service contract does not declare - CXF copies the exception message into the SOAP faultstring and, when configured to do so, the stack trace into the fault detail. Deployments running Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 with an exposed CXF SOAP consumer are affected; an external caller who can provoke an undeclared failure can read class and package names and whatever the exception message carries, at CVSS 3.1 base 5.3 (AV:N/AC:L/PR:N/UI:N/C:L/I:N/A:N, CWE-209). Declared @WebFault exceptions are intentionally unaffected because they are part of the published contract. No public exploit code has been identified at time of analysis, and the issue is a read-only disclosure rather than code execution or data modification.
Reflecting caller-chosen request headers back into responses is possible in Apache Camel's platform-http component (4.0.0 before 4.18.5, and 4.19.0 before 4.22.1) because the guard that suppresses sensitive headers compares names case-sensitively, so a caller can defeat it by changing header casing - and on HTTP/2, where field names must be lowercase on the wire, the suppression never fires at all. Unauthenticated remote attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N, 6.5) can therefore have content they control echoed into the response, which is the primitive behind response-splitting and cache-poisoning attacks against proxies or caches sitting in front of the Camel endpoint. Vendor patches are available in 4.23.0, 4.18.5 and 4.22.1; no public exploit code and no confirmed active exploitation were identified at time of analysis, and practical impact is gated by whether a fronting cache or proxy acts on the reflected content.
Header injection in the Apache Camel Tika producer (tika:parse) lets a crafted document write arbitrary names into the Camel Exchange header namespace, because every metadata key parsed out of the submitted file is mapped onto the message with no filter. Routes running Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 that parse untrusted files and then hand the message to a component that acts on Camel-namespace headers - most notably CamelFileName, which file endpoints use to decide the write path - can be steered by an attacker-chosen metadata name such as an HTML <meta name="CamelFileName" content="../../pwned"/>. Unauthenticated remote attackers can supply the document (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N as independently assessed; the vendor published 6.5 with AC:L, while the higher attack complexity reflects the non-universal route configuration required); no public exploit code or CISA KEV entry was identified at time of analysis, and vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1.
Signature verification in the Apache Camel PQC component can be silently defeated when concurrent exchanges share the producer's single stateful java.security.Signature instance, allowing a message to be reported as verified even though its signature was never actually checked against its own payload. Affected are Apache Camel releases from 4.12.0 before 4.18.5 and from 4.19.0 before 4.22.1 that use the camel-pqc sign/verify operations; remote, unauthenticated attackers who can drive concurrent traffic through such a route may interleave init/update/verify sequences. Exploitation is timing-dependent and non-deterministic (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), and no public exploit was identified at time of analysis; the practical prerequisite is a concurrently invoked PQC signing endpoint, which is the ordinary condition for a loaded Camel route. Vendor-released fixes exist in 4.23.0, 4.18.5 and 4.22.1.
Man-in-the-middle interception of Apache Camel's Knative HTTP client can expose traffic when TLS is enabled without a configured truststore, because affected versions (4.0.0 before 4.18.5 and 4.19.0 before 4.22.1) fall back to trusting every presented certificate instead of the JVM default trust anchors. Exploitation is conditional rather than universal: the deployment must set camel.knative.client.ssl.enabled=true while leaving both truststore.path and trust.cert.path unset, and a remote unauthenticated attacker must already hold a privileged network position to terminate the TLS session (CVSS 3.1 5.9, AC:H, C:H/I:N). No public exploit identified at time of analysis, and the vendor fix in 4.23.0 (plus 4.18.5 and 4.22.1 LTS) leaves trust options unset so JVM defaults apply and requires an explicit trust.all property to opt into trust-all.
Error messages written back over the socket by the Apache Camel camel-mina consumer leak internal deployment details to any remote peer that can provoke a processing failure. Affected deployments are Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 that use camel-mina as a consumer (socket server) in sync mode, where the peer is unauthenticated per the CVSS vector (AV:N/AC:L/PR:N/UI:N) and the impact is limited to confidentiality (C:L) with no integrity or availability effect. The exposure ranges from exception class and message text under the textline codec to a fully serialised exception with its cause chain under the object codec; exploitability depends on the attacker reaching the socket and triggering a failure, and no public exploit code or confirmed active exploitation was identified at time of analysis - treat this as moderate-severity hardening rather than an urgent threat.
In the camel-thrift data format, unmarshalled messages are deserialized into a process-wide shared defaultInstance and that same object is returned as the exchange body, so state from one message survives into the next. Senders who omit optional fields in a later payload inherit the previous sender's values, and concurrent exchanges can observe each other's partially written state - disclosing one tenant's data to another. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0; no public exploit identified at time of analysis, and exploitation requires a genuinely multi-tenant route using the Thrift data format plus attacker influence over message sequencing or timing (CVSS 5.9, AC:H, PR:N).
Undetected tampering with PGP-encrypted messages is possible in the Apache Camel Crypto PGP data format because unmarshal() only validated the OpenPGP modification detection code when the incoming message used the integrity-protected packet type, and the packet type is selected by the message producer. Deployments running Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 that decrypt externally supplied PGP ciphertext are affected; unauthenticated remote attackers who can produce those messages, or rewrite them in transit, can substitute the legacy symmetrically encrypted data packet and have malleated content accepted without any integrity failure. Impact is limited to integrity (silent forgery or modification of decrypted content) with no confidentiality or availability loss, so this is a genuine but moderate-severity flaw rather than an emergency; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV) - exploitation requires the attacker to control or intercept the message bytes, which is why the vector carries AC:H.
Improper credential verification in the Apache Camel camel-shiro security processor lets a remote attacker whose request names an already-in-use principal ride a thread-bound Shiro subject and skip the password check entirely. Affected are Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 that secure routes with ShiroSecurityPolicy, particularly when alwaysReauthenticate=false keeps subjects long-lived on pooled worker threads; the CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N (5.9), reflecting unauthenticated network reachability gated by high attack complexity. Because exploitation depends on thread-pool reuse timing and an exact principal-name match, it is non-deterministic rather than reliably reproducible, and no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis. Successful abuse yields access to protected routes and their data as the impersonated principal, with no integrity or availability impact assessed.
Apache Camel's camel-knative HTTP consumer writes the full exception - class name, message, and stack trace - back to the remote caller whenever an exchange fails on the consumer side, letting any external sender provoke a route failure and harvest internal deployment detail (package and class names, host names, file paths, route shape, and any configuration or connection strings embedded in exception messages). The flaw affects Camel from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1; camel-knative was the last HTTP-family consumer not yet aligned with the muteException behaviour introduced for the other HTTP consumers under CAMEL-23651. Rated CVSS 5.3 (AV:N/AC:L/PR:N/UI:N, C:L only), it requires the Knative HTTP consumer to be reachable by untrusted callers and an induced processing failure; no public exploit code was identified at time of analysis and there is no indication of active exploitation.
Login cross-site request forgery (CSRF) and open redirect in the Apache Camel OAuth component (camel-oauth) let an attacker silently sign a victim into an attacker-controlled identity: the authorization code callback in affected releases neither issued a session-bound state parameter nor validated one, so a code obtained in any browser can be redeemed against whatever session presents it. Affected are Apache Camel 4.11.0 before 4.18.5 and 4.19.0 before 4.22.1 - and only deployments that actually use the camel-oauth authorization code flow to authenticate users, since that component is optional. The CVSS 3.1 score is 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N): remote and unauthenticated from the attacker's side, but exploitation requires victim interaction (following a crafted callback link), and impact is confined to the OAuth login identity rather than the host. No public exploit code or confirmed active exploitation was identified at time of analysis; the vendor has released fixed versions (4.23.0, 4.18.5, 4.22.1).
Credentialed cross-origin data exposure in Apache Camel's platform-http-vertx component (4.0.0 through 4.18.4, and 4.19.0 through 4.22.0) lets a malicious page read authenticated responses from a Camel HTTP endpoint. The CORS handler sets Access-Control-Allow-Credentials: true outside its origin check, and when camel.server.cors.origins is left unset it reflects the caller's own Origin back - the combination browsers permit for credentialed requests even though a literal wildcard is forbidden. Rated CVSS 6.5 (AV:N/AC:L/PR:N/UI:R/C:H/I:N/A:N) because a victim with an active session must be lured to an attacker-controlled page; no public exploit code or confirmed active exploitation was identified at time of analysis, and an explicit origin allow-list fully prevents it.
Apache Camel's Docling component implicitly interprets String message bodies by prefix, letting attacker-influenced content trigger server-side request forgery (bodies beginning with http:// or https://) or local file disclosure (bodies beginning with / or containing a backslash) without any endpoint option to pin the interpretation mode. Affected are Camel 4.15.0 through 4.18.4 and 4.19.0 through 4.22.0; the flaw is unauthenticated from the component's perspective (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, 5.9) but requires that a route actually forward externally influenced String bodies into a docling endpoint, and confidentiality-only impact is rated High. No public exploit code or CISA KEV entry is associated at time of analysis; EPSS data was not provided. Vendor-released patches exist (4.23.0, 4.22.1, 4.18.5) along with new opt-in hardening options.
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.
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.
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.
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to remote code execution in the Camel process. Any host that can reach the JGroups cluster's multicast group or bind port - adjacent network only, given the default UDP multicast stack - can join without credentials and deliver a crafted serialized object that JGroups deserializes on its own receive thread before Camel's routing logic ever runs. Code execution still depends on a usable gadget chain being present on the application classpath and on no JVM-wide -Djdk.serialFilter being configured, which is why the issue is assessed as high rather than critical; no public exploit code or confirmed active exploitation was identified at time of analysis. Deployments that explicitly configure a channel/channelProperties with AUTH and encryption, or that set a JVM-wide serialization filter, are not exploitable through this path.
XML external entity injection in the camel-smooks component of Apache Camel (versions 4.7.0 through 4.18.4 and 4.19.0 through 4.22.0) lets remote attackers who can supply or influence an XML message body that is unmarshalled by Smooks read files accessible to the Camel process and force it to issue requests to internal network hosts. No privileges or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N), and no non-default configuration is needed because external entity resolution was the default behaviour of the Woodstox SAX reader Smooks used; the confidentiality impact is high with a low availability impact, giving a base score of 8.2. The flaw is only reachable on routes that unmarshal XML through .unmarshal().smooks(...) or the smooks: component with its default reader, and full return of exfiltrated content depends on an InOut route binding the resolved entity into the reply, so no public exploit code or active exploitation has been identified at time of analysis, though the vendor has released fixed versions.
Credential disclosure in the Apache Camel camel-http component lets a malicious or compromised remote endpoint harvest OAuth2 bearer tokens and basic/digest credentials by answering a request with an HTTP redirect to a host it controls. The leak occurs because OAuth2ClientConfigurer's request interceptor sits in ProtocolExec, below RedirectExec, so 'Authorization: Bearer' headers are re-attached on every redirect hop, and because basic/digest credentials were registered against an AuthScope that matched any host. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0; exploitation requires an endpoint with credentials configured and followRedirects=true (not the default) plus an attacker positioned to influence the target server's responses, and no public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
XML external entity injection in the Apache Camel XPath component lets unauthenticated remote attackers read files accessible to the Camel process and induce it to make outbound requests to attacker-named hosts when an expression is configured with documentType=InputSource and evaluates XML from an untrusted sender. The flaw is configuration-gated rather than default: Camel's default document type already refuses a DOCTYPE, so stock deployments are not exposed, but a deployment that selected InputSource for streaming reasons unknowingly also selected a weaker parser. Fixed in 4.23.0, 4.18.5 and 4.22.1; no public exploit identified at time of analysis, and the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects confidentiality impact only.
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message on a transport feeding that endpoint to choose both the expression language and the predicate expression that Camel compiles and then evaluates against every exchange routed through the corresponding dynamic-router endpoint, running with the full privileges of the Camel process - effectively code execution. The issue affects Camel 4.4.0 through 4.18.4 and 4.19.0 through 4.22.0 (releases before 4.4.0 are not affected), scored CVSS 3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), so some access to the feeding transport is expected but no application-level authentication or user interaction is required. Exposure is limited to deployments that expose the control endpoint through a route forwarding messages from an external, shared or untrusted transport; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Unauthenticated remote AS2 partners can turn an Apache Camel camel-as2 receiver into a server-side request forgery pivot: the component reads the asynchronous Message Disposition Notification (MDN) return address out of the inbound message and dials it verbatim, so the sender chooses the host the Camel instance connects to, including addresses only routable from inside the deployment's network. Deployments running Apache Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 with an exposed camel-as2 receiver are affected; where mdnUserName, mdnPassword or mdnAccessToken are configured, the outbound receipt presents those MDN-delivery credentials to the attacker-chosen destination, which drives the high confidentiality component of the CVSS 3.1 score of 8.2 (CWE-918). No public exploit code has been identified at time of analysis, and vendor fixes are released in 4.23.0, 4.18.5 and 4.22.1; real-world urgency is moderated by whether the receiver is reachable by untrusted partners and whether credentials are attached to MDN delivery.
Authorization bypass in Apache Camel's camel-netty-http component allows remote unauthenticated attackers to reach protected routes by changing the case of characters in the request path so the security constraint no longer recognizes it while routing still dispatches to the endpoint. It affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1, with a CVSS score of 8.2; no public exploit identified at time of analysis.
Apache Camel's camel-oauth route guards fail open: when authentication cannot be completed, the OAuthBearerTokenProcessor and OAuthCodeFlow processors set an error status and body but never stop the exchange, so the request falls through and continues into the protected part of the route as if the caller had authenticated. Camel 4.11.0 through 4.18.4 and 4.19.0 through 4.22.0 are affected wherever camel-oauth is used to protect an HTTP-reachable endpoint, and exploitation needs no credentials, user interaction, or special configuration - simply omitting the Authorization header, sending a non-Bearer header, presenting an invalid token, or arriving without an authorization code is enough (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). The gap is a confidentiality problem first and foremost, exposing whatever the protected route returns, with limited integrity impact; no public exploit identified at time of analysis, and the vendor-released patch is 4.23.0, with backports in 4.18.5 and 4.22.1.
Path traversal in Apache Camel's remote-file consumers - the azure-files scheme named in this CVE plus the FTP/SFTP consumers sharing the RemoteFileConsumer base class - lets a malicious, compromised, or multi-tenant remote file server (or an on-path attacker on the integrity-free FTP control channel) cause Camel to read, delete, or rename files outside the directory it was configured to poll, using the endpoint's own credentials. Retrieval is reachable in the default consumer configuration because remote consumers download every listed file; deletion and renaming additionally require delete=true, move, preMove, moveFailed, or readLock=rename. The jailStartingDirectory option, enabled by default and documented as a boundary, did not constrain this remote operand before the fix, so it offered no protection; triggering the traversal requires control over a listing name returned by the server, and for azure-files specifically the Azure Files REST service does not normally return multi-segment names, making exploitation there impractical. No public exploit code or confirmed active exploitation was identified at time of analysis; vendor patches are available.
Path traversal in Apache Camel's remote-file consumers (including the SMB component's share-walking consumer) lets a directory listing entry that is not a single path segment resolve outside the polled remote directory, so Camel will retrieve, delete, or rename files outside that directory using the endpoint's own credentials. Affected are Camel 4.2.0 through 4.18.5-exclusive and 4.19.0 through 4.22.1-exclusive; file retrieval is reachable in a default consumer configuration, while deletion requires delete=true and renaming requires move, preMove, moveFailed, or readLock=rename. The CVSS 3.1 vector (7.4, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects unauthenticated reachability over the network with a high attack-complexity prerequisite: the remote server - or an on-path attacker rewriting an unprotected FTP LIST response, or a malicious, compromised, multi-tenant, or virtual-filesystem-backed server - must emit a qualifying listing name; for the SMB scheme a conforming SMB2 server will not do so, and no public exploit identified at time of analysis.
Path traversal in Apache Camel's remote-file consumers (the FTP, SFTP and mina-sftp schemes) lets a name reported in a remote server's directory listing resolve outside the directory Camel was configured to poll, so Camel will read, delete or rename files elsewhere using that endpoint's own credentials. Affected are Camel 4.18.0 through 4.18.4 and 4.19.0 through 4.22.0, with retrieval reachable in a default consumer configuration because remote consumers download every listed file (CVSS 3.1 base score 7.4, AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:N). The attacker must influence the LIST/SFTP listing output - via a malicious, compromised or multi-tenant server, a virtual-filesystem-backed server, or an on-path attacker against plaintext FTP whose control channel has no integrity protection - and no public exploit has been identified at time of analysis.
Apache Camel's ftp, ftps and sftp remote-file consumers build each file's remote path by concatenating the polled directory with the name returned in the server's directory listing, without any lexical normalization or containment check, so a listing entry containing parent-directory segments resolves outside the configured directory and is then read, deleted or renamed with the endpoint's own credentials. Affected are Camel 4.0.0 through 4.18.4, 4.19.0 through 4.22.0, and earlier; the 4.14.x stream is end-of-life and unfixed, while patches ship in 4.18.5, 4.22.1 and 4.23.0 (CPE: apache_software_foundation:apache_camel). Retrieval is reachable in a default consumer route, whereas deletion needs delete=true and renaming needs move, preMove, moveFailed or readLock=rename; the crucial caveat is that the jailStartingDirectory option, on by default and documented as confining Camel to the starting directory, does not constrain this remote path, so it cannot be used as a mitigation. There is confirmed no active exploitation tracked (not in CISA KEV) and no public exploit code identified at time of analysis, although the reporter privately demonstrated the issue end to end against an FTP endpoint; CVSS 7.4 with AC:H reflects that the attacker must first control or influence the remote server's LIST response rather than attack Camel directly.
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticated attacker who can either PUBLISH to a channel the route subscribes to, or write attacker-controlled bytes into a key the component later reads, to instantiate an arbitrary class graph in the application's JVM and execute its readObject method. Every release from 2.11.0 up to (but not including) 4.18.5 and 4.22.1 ships the affected default, which lazily builds a bare JdkSerializationRedisSerializer with no java.io.ObjectInputFilter whenever no serializer option is configured. No public exploit code was identified at time of analysis, but exploitation needs only a viable gadget on the classpath, which is why this carries CVSS 8.8 with high confidentiality and integrity impact.
Header-driven URI resolution in Apache Camel's HTTP producer components causes message-supplied CamelHttpUri and CamelRestHttpUri values to be expanded through CamelContext.resolvePropertyPlaceholders() before use, so an attacker who can influence those headers turns a URI string into a configuration-evaluation context and can read OS environment variables, JVM system properties, every registered secret-backend PropertiesFunction (AWS, Azure, GCP, HashiCorp, IBM, CyberArk, Kubernetes) and even invoke no-argument methods on beans in the registry. The flaw affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1 across camel-http, camel-http-common, camel-vertx-http, camel-undertow and camel-netty-http, and a plain static to(http://backend/api) route is enough to be exposed; no authentication is required where a route is reachable by untrusted senders (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). Exploitation yields a high-confidentiality but limited-integrity impact, and while no public exploit code or CISA KEV entry exists at time of analysis, the preconditions are ordinary and the vendor has shipped fixes, so this warrants prioritised patching.
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, where two self-built Hazelcast bootstrap paths create instances without the default JavaSerializationFilterConfig added for CVE-2026-43865. A route using ReplicatedHazelcastAggregationRepository without an injected hazelcastInstance, or a client-mode endpoint built by HazelcastDefaultComponent#getOrCreateHzClientInstance() when neither a ClientConfig nor hazelcastConfigUri is supplied, will accept and deserialize arbitrary Java objects published into the backing cluster, letting an attacker who can write into that cluster execute code before Camel ever processes the exchange. Hazelcast clusters ship without authentication or TLS by default, so the write prerequisite is often met in practice; no public exploit code or CISA KEV entry was identified at time of analysis, but the vendor has published fixed releases and the missing-filter condition requires no unsafe opt-in by the deployer.
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.
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.
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).
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.
External entity expansion (XXE) in Apache Camel's camel-fop component lets an unauthenticated remote sender who can deliver an XSL-FO body to a fop producer read files accessible to the Camel process and force that process to make outbound requests to attacker-named hosts. The flaw is conditional: FopProducer relies on TransformerFactory.newInstance() plus FEATURE_SECURE_PROCESSING, which is sufficient only for the JDK's built-in transformer, so exploitation requires a third-party JAXP factory such as Saxon-HE (typically pulled in via camel-xslt-saxon or camel-saxon) on the classpath - default camel-fop deployments are not affected. There is no public exploit code or CISA KEV entry identified at time of analysis, and the CVSS 6.5 score reflects high attack complexity and confidentiality-heavy impact (C:H/I:L) rather than easy mass exploitation; fixes are shipping via upstream PRs, but 4.14.x and earlier releases are end-of-life and will never receive one.
Apache Camel's camel-http OAuth2 client-credentials token cache is keyed only on the request URI, client ID and client secret, so two endpoints in the same JVM that differ solely in OAuth2 scope, resource indicator or token endpoint collide on one cache entry and one route can be served a token minted for another. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 with token caching enabled (oauth2CacheTokens=true) and at least two such OAuth2 endpoints configured; deployments with a single endpoint, or endpoints that also differ in URI or credentials, are not impacted. Rated CVSS 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, CWE-524), the practical consequence is authority confusion between the operator's own routes rather than an external attack path, and no public exploit identified at time of analysis; fixed in 4.23.0, 4.18.5 and 4.22.1.
Prefix confusion in Apache Camel's camel-platform-http component silently promotes ordinary HTTP endpoints to forwarding proxies, letting remote unauthenticated callers relay requests to targets they choose via the Host header and reach content the route author never intended to expose. Only Camel deployments running a platform-http route whose configured path begins with the five characters 'proxy' (for example proxyStats, proxy-health or proxying) while not intending the documented platform-http:proxy endpoint are affected - a developer-introduced naming condition that keeps attack complexity high and drives the modest CVSS 3.1 score of 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N). Default deployments without such endpoints are not exploitable, and no public exploit code or CISA KEV entry was identified at time of analysis.
Error responses from the Apache Camel gRPC consumer component can leak internal exception details to remote callers: when a route behind a gRPC consumer fails, the exception's message is copied into the gRPC status description, which is transmitted back across the wire rather than kept server-side like the status cause. Unauthenticated remote callers who can provoke a route failure on an affected deployment (Camel 4.0.0 before 4.18.5, or 4.19.0 before 4.22.1) may read class and package names, filesystem paths, host names and connection detail embedded in those messages, at CVSS 5.3 with confidential-impact-only. The leak is conditional on the exception text itself carrying sensitive content and on the gRPC consumer being reachable, so real-world exposure varies by route; there is no public exploit identified at time of analysis and no confirmed active exploitation. Vendor patches are published (4.23.0, plus LTS 4.18.5 and 4.22.1), and the fixed builds default a new muteException option to true so patched deployments stop leaking unless they explicitly opt out.
Unfiltered MIME headers in Apache Camel's camel-mail component (4.0.0 through 4.18.4 and 4.19.0 through 4.22.0) allow an external message sender to place mail.smtp.* / mail.smtps.* names onto the Camel Exchange when a multipart message is unmarshalled with the MimeMultipart data format and inline headers enabled. Because those names fall outside the Camel* namespace that consumer-side header filters block, they can steer how a downstream mail producer connects and sends, yielding low confidentiality and integrity impact (CVSS 6.5, network-reachable and unauthenticated per the CVSS:3.1/AV:N/AC:L/PR:N/UI:N vector). This is an incomplete fix of CVE-2026-46584 rather than a new defect class, so deployments that applied that earlier advisory and considered camel-mail settled remain exposed on this path; no public exploit code was identified at time of analysis and the vulnerable topology is a specific, non-default route configuration.
Apache Camel's Jetty HTTP component (camel-jetty / camel-jetty-common), in versions 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, installs Jetty's CrossOriginFilter with its stock defaults whenever an operator opts in with enableCORS=true, producing an allow-any-origin policy that also grants credentials instead of the empty policy operators expected to fill in. Unauthenticated remote attackers who lure a victim's browser to an attacker-controlled page (UI:R) can then perform credentialed cross-origin reads against the endpoint and read the responses, provided the victim already holds cookies or session credentials for that endpoint and the endpoint returns sensitive data. Exposure is configuration-dependent because it requires the non-default enableCORS=true opt-in on a Jetty endpoint; no public exploit code or active exploitation has been identified at time of analysis, and fixed versions 4.23.0, 4.18.5 and 4.22.1 have been released by the vendor.
Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 let a remote sender choose which saga their exchange joins by supplying the unprefixed 'Long-Running-Action' header, because the saga processor consulted that header on every exchange rather than only for saga services that participate in an external LRA protocol. The consequence is limited to deployments running sagas through the camel-lra component with a real LRA coordinator and a consumer that accepts inbound messages from untrusted senders: an attacker can attach a request to a long-running action started by someone else, or force compensation to be associated with an action they did not initiate, yielding low confidentiality and integrity impact (CVSS 4.8, AC:H). Vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1, and no public exploit has been identified at time of analysis.
The FileBasedKeyLifecycleManager in Apache Camel's PQC (post-quantum cryptography) component writes generated private key material to disk using whatever permissions the process umask produces instead of restricting the file to its owner, so on hosts with a permissive umask such as 022 the unencrypted private key is group- and world-readable. Affected are Apache Camel 4.12.0 through 4.18.4 and 4.19.0 through 4.22.0 that use this component to persist key material; an attacker who already holds a separate local account on the same host can read the key file and then forge signatures or break key exchanges performed by that deployment. The CVSS 3.1 vector (AV:L/PR:L/C:H) confines this to a local, authenticated party - no public exploit code has been identified at time of analysis and there is no CISA KEV listing - and the vendor assesses severity as low because the remote sender that Camel's threat model targets is not the exposure path.
Apache Camel's camel-keycloak security processor can accept a token minted by an issuer other than the configured one when token introspection is in use, the opt-in issuer validation is enabled, and the introspection endpoint returns an active response that omits the 'iss' claim - the check was skipped instead of failing. The flaw affects Apache Camel releases from 4.15.0 up to but not including 4.18.5, and from 4.19.0 up to but not including 4.22.1, specifically deployments using the camel-keycloak component with token introspection. Exploitation is unauthenticated per the CVSS vector (PR:N) but demands a non-default chain - introspection enabled, validateIssuer explicitly turned on, and a broker/gateway/minimal introspection endpoint that omits iss and serves multiple issuers - which caps the score at 4.8; no public exploit identified at time of analysis, and vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1.
Cross-partner signing-key confusion in the Apache Camel AS2 component (4.0.0 through 4.18.4 and 4.19.0 through 4.22.0) can cause a Message Disposition Notification to be signed with another trading partner's key when a multi-partner server handles concurrent or successive requests using dynamically fetched per-request keys. The issue is remotely reachable without authentication per the CVSS vector but has high attack complexity because exploitation depends on overlapping partner traffic through a shared ResponseMDN instance; it can expose signing material and misattribute receipts, with practical exposure limited to deployments serving multiple partners from one Camel context. No public exploit identified at time of analysis, and no KEV confirmation was provided in the supplied data.
Apache Camel's camel-mllp component writes HL7 clinical message payloads containing protected health information into ordinary application logs, because the logPhi option defaulted to true and two additional code paths logged payload content even when an operator had explicitly set logPhi=false. Deployments running Camel 4.0.0 through 4.18.4, or 4.19.0 through 4.22.0, that use the MLLP transport for healthcare integration are exposed out of the box; anyone who can read the resulting logs - local authenticated users per the CVSS vector (AV:L/PR:L, C:H) - can recover patient data that was never meant to land in general-purpose log storage with its broader retention, aggregation and access surface. This is a genuine data-exposure defect but a low-urgency one in attacker terms, since it is not remotely triggerable and merely requires pre-existing log read access; no public exploit code was identified at time of analysis, and vendor patches are available. Note that simply setting logPhi=false is not a complete workaround, as two code paths continue to log payloads until the fix is applied.
Apache Camel's CXF component leaks internal deployment detail back to SOAP clients when a route behind a CXF SOAP consumer fails with an exception that the service contract does not declare - CXF copies the exception message into the SOAP faultstring and, when configured to do so, the stack trace into the fault detail. Deployments running Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 with an exposed CXF SOAP consumer are affected; an external caller who can provoke an undeclared failure can read class and package names and whatever the exception message carries, at CVSS 3.1 base 5.3 (AV:N/AC:L/PR:N/UI:N/C:L/I:N/A:N, CWE-209). Declared @WebFault exceptions are intentionally unaffected because they are part of the published contract. No public exploit code has been identified at time of analysis, and the issue is a read-only disclosure rather than code execution or data modification.
Reflecting caller-chosen request headers back into responses is possible in Apache Camel's platform-http component (4.0.0 before 4.18.5, and 4.19.0 before 4.22.1) because the guard that suppresses sensitive headers compares names case-sensitively, so a caller can defeat it by changing header casing - and on HTTP/2, where field names must be lowercase on the wire, the suppression never fires at all. Unauthenticated remote attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N, 6.5) can therefore have content they control echoed into the response, which is the primitive behind response-splitting and cache-poisoning attacks against proxies or caches sitting in front of the Camel endpoint. Vendor patches are available in 4.23.0, 4.18.5 and 4.22.1; no public exploit code and no confirmed active exploitation were identified at time of analysis, and practical impact is gated by whether a fronting cache or proxy acts on the reflected content.
Header injection in the Apache Camel Tika producer (tika:parse) lets a crafted document write arbitrary names into the Camel Exchange header namespace, because every metadata key parsed out of the submitted file is mapped onto the message with no filter. Routes running Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 that parse untrusted files and then hand the message to a component that acts on Camel-namespace headers - most notably CamelFileName, which file endpoints use to decide the write path - can be steered by an attacker-chosen metadata name such as an HTML <meta name="CamelFileName" content="../../pwned"/>. Unauthenticated remote attackers can supply the document (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N as independently assessed; the vendor published 6.5 with AC:L, while the higher attack complexity reflects the non-universal route configuration required); no public exploit code or CISA KEV entry was identified at time of analysis, and vendor-released patches exist in 4.23.0, 4.18.5 and 4.22.1.
Signature verification in the Apache Camel PQC component can be silently defeated when concurrent exchanges share the producer's single stateful java.security.Signature instance, allowing a message to be reported as verified even though its signature was never actually checked against its own payload. Affected are Apache Camel releases from 4.12.0 before 4.18.5 and from 4.19.0 before 4.22.1 that use the camel-pqc sign/verify operations; remote, unauthenticated attackers who can drive concurrent traffic through such a route may interleave init/update/verify sequences. Exploitation is timing-dependent and non-deterministic (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), and no public exploit was identified at time of analysis; the practical prerequisite is a concurrently invoked PQC signing endpoint, which is the ordinary condition for a loaded Camel route. Vendor-released fixes exist in 4.23.0, 4.18.5 and 4.22.1.
Man-in-the-middle interception of Apache Camel's Knative HTTP client can expose traffic when TLS is enabled without a configured truststore, because affected versions (4.0.0 before 4.18.5 and 4.19.0 before 4.22.1) fall back to trusting every presented certificate instead of the JVM default trust anchors. Exploitation is conditional rather than universal: the deployment must set camel.knative.client.ssl.enabled=true while leaving both truststore.path and trust.cert.path unset, and a remote unauthenticated attacker must already hold a privileged network position to terminate the TLS session (CVSS 3.1 5.9, AC:H, C:H/I:N). No public exploit identified at time of analysis, and the vendor fix in 4.23.0 (plus 4.18.5 and 4.22.1 LTS) leaves trust options unset so JVM defaults apply and requires an explicit trust.all property to opt into trust-all.
Error messages written back over the socket by the Apache Camel camel-mina consumer leak internal deployment details to any remote peer that can provoke a processing failure. Affected deployments are Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 that use camel-mina as a consumer (socket server) in sync mode, where the peer is unauthenticated per the CVSS vector (AV:N/AC:L/PR:N/UI:N) and the impact is limited to confidentiality (C:L) with no integrity or availability effect. The exposure ranges from exception class and message text under the textline codec to a fully serialised exception with its cause chain under the object codec; exploitability depends on the attacker reaching the socket and triggering a failure, and no public exploit code or confirmed active exploitation was identified at time of analysis - treat this as moderate-severity hardening rather than an urgent threat.
In the camel-thrift data format, unmarshalled messages are deserialized into a process-wide shared defaultInstance and that same object is returned as the exchange body, so state from one message survives into the next. Senders who omit optional fields in a later payload inherit the previous sender's values, and concurrent exchanges can observe each other's partially written state - disclosing one tenant's data to another. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0; no public exploit identified at time of analysis, and exploitation requires a genuinely multi-tenant route using the Thrift data format plus attacker influence over message sequencing or timing (CVSS 5.9, AC:H, PR:N).
Undetected tampering with PGP-encrypted messages is possible in the Apache Camel Crypto PGP data format because unmarshal() only validated the OpenPGP modification detection code when the incoming message used the integrity-protected packet type, and the packet type is selected by the message producer. Deployments running Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 that decrypt externally supplied PGP ciphertext are affected; unauthenticated remote attackers who can produce those messages, or rewrite them in transit, can substitute the legacy symmetrically encrypted data packet and have malleated content accepted without any integrity failure. Impact is limited to integrity (silent forgery or modification of decrypted content) with no confidentiality or availability loss, so this is a genuine but moderate-severity flaw rather than an emergency; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV) - exploitation requires the attacker to control or intercept the message bytes, which is why the vector carries AC:H.
Improper credential verification in the Apache Camel camel-shiro security processor lets a remote attacker whose request names an already-in-use principal ride a thread-bound Shiro subject and skip the password check entirely. Affected are Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0 that secure routes with ShiroSecurityPolicy, particularly when alwaysReauthenticate=false keeps subjects long-lived on pooled worker threads; the CVSS:3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N (5.9), reflecting unauthenticated network reachability gated by high attack complexity. Because exploitation depends on thread-pool reuse timing and an exact principal-name match, it is non-deterministic rather than reliably reproducible, and no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis. Successful abuse yields access to protected routes and their data as the impersonated principal, with no integrity or availability impact assessed.
Apache Camel's camel-knative HTTP consumer writes the full exception - class name, message, and stack trace - back to the remote caller whenever an exchange fails on the consumer side, letting any external sender provoke a route failure and harvest internal deployment detail (package and class names, host names, file paths, route shape, and any configuration or connection strings embedded in exception messages). The flaw affects Camel from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1; camel-knative was the last HTTP-family consumer not yet aligned with the muteException behaviour introduced for the other HTTP consumers under CAMEL-23651. Rated CVSS 5.3 (AV:N/AC:L/PR:N/UI:N, C:L only), it requires the Knative HTTP consumer to be reachable by untrusted callers and an induced processing failure; no public exploit code was identified at time of analysis and there is no indication of active exploitation.
Login cross-site request forgery (CSRF) and open redirect in the Apache Camel OAuth component (camel-oauth) let an attacker silently sign a victim into an attacker-controlled identity: the authorization code callback in affected releases neither issued a session-bound state parameter nor validated one, so a code obtained in any browser can be redeemed against whatever session presents it. Affected are Apache Camel 4.11.0 before 4.18.5 and 4.19.0 before 4.22.1 - and only deployments that actually use the camel-oauth authorization code flow to authenticate users, since that component is optional. The CVSS 3.1 score is 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N): remote and unauthenticated from the attacker's side, but exploitation requires victim interaction (following a crafted callback link), and impact is confined to the OAuth login identity rather than the host. No public exploit code or confirmed active exploitation was identified at time of analysis; the vendor has released fixed versions (4.23.0, 4.18.5, 4.22.1).
Credentialed cross-origin data exposure in Apache Camel's platform-http-vertx component (4.0.0 through 4.18.4, and 4.19.0 through 4.22.0) lets a malicious page read authenticated responses from a Camel HTTP endpoint. The CORS handler sets Access-Control-Allow-Credentials: true outside its origin check, and when camel.server.cors.origins is left unset it reflects the caller's own Origin back - the combination browsers permit for credentialed requests even though a literal wildcard is forbidden. Rated CVSS 6.5 (AV:N/AC:L/PR:N/UI:R/C:H/I:N/A:N) because a victim with an active session must be lured to an attacker-controlled page; no public exploit code or confirmed active exploitation was identified at time of analysis, and an explicit origin allow-list fully prevents it.
Apache Camel's Docling component implicitly interprets String message bodies by prefix, letting attacker-influenced content trigger server-side request forgery (bodies beginning with http:// or https://) or local file disclosure (bodies beginning with / or containing a backslash) without any endpoint option to pin the interpretation mode. Affected are Camel 4.15.0 through 4.18.4 and 4.19.0 through 4.22.0; the flaw is unauthenticated from the component's perspective (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, 5.9) but requires that a route actually forward externally influenced String bodies into a docling endpoint, and confidentiality-only impact is rated High. No public exploit code or CISA KEV entry is associated at time of analysis; EPSS data was not provided. Vendor-released patches exist (4.23.0, 4.22.1, 4.18.5) along with new opt-in hardening options.
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.
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.
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.