Apache Camel vulnerabilities

Apache Camel versions 2.6.x through 2.14.x, 2.15.x before 2.15.5, and 2.16.x before 2.16.1, when using camel-jetty or camel-servlet as consumers in Camel routes, allow remote attackers to execute arbitrary commands via a crafted serialized Java object in an HTTP request.

The XSLT component in Apache Camel before 2.11.4 and 2.12.x before 2.12.3 allows remote attackers to read arbitrary files and possibly have other unspecified impact via an XML document containing an external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) issue.

A deserialization of untrusted data vulnerability in Apache Camel affects the camel-hazelcast component. Two configuration paths (ReplicatedHazelcastAggregationRepository and client mode in HazelcastDefaultComponent) fail to apply the JavaSerializationFilterConfig, allowing an attacker to achieve remote code execution by injecting a malicious Java object into the Hazelcast cluster.

Vulnerability in Apache Camel Atmosphere Websocket component due to improper input validation of Exchange headers outside the Camel namespace (websocket.connectionKey, websocket.connectionKey.list, websocket.sendToAll, websocket.eventType, websocket.errorType). An external attacker can supply the list header via HTTP and take over the producer's dispatch decision, potentially suppressing or redirecting notifications to a different client.

Relative path traversal vulnerability in Apache Camel Azure Storage Blob component allows writing files outside the configured directory during downloadBlobToFile operation. Blob names with parent-directory segments are not normalized, enabling overwriting arbitrary files with Camel process privileges.

The Apache Camel AWS SNS component lacks an inbound filter rule in the Sns2HeaderFilterStrategy. However, the vulnerability is not exploitable because the component is producer-only (does not support consumers), so an attacker cannot supply external message attributes to the Camel Exchange. A defense-in-depth filter was added for consistency with other strategies.

A vulnerability in the camel-keycloak component of Apache Camel allows bypassing access token verification in the default configuration. When required roles or permissions are empty, the token is not cryptographically verified, allowing access to protected routes with any Authorization header.

A vulnerability in the Apache Camel DNS component allows SSRF attacks via improper input validation of message headers. An attacker can set dns.server, dns.name, and dns.domain headers in an HTTP request, redirecting DNS queries to a controlled server and disclosing internal hostnames.

Vulnerability in Apache Camel's mongodb-gridfs component allows an attacker to manipulate GridFS operations via HTTP headers. Improper input validation and access control enable unauthorized file deletion, reading, enumeration, and NoSQL operator injection.

Vulnerability in Apache Camel Solr component allows SSRF and injection of Solr parameters and fields. Exchange headers with SolrParam. and SolrField. prefixes are passed unfiltered from HTTP requests to the Solr producer, enabling attackers to manipulate queries and indexed documents.

Vulnerability in Apache Camel AWS2-SQS component allows attackers to inject Camel control headers (e.g., CamelHttpUri, CamelFileName) via SQS messages. Missing inbound filtering in Sqs2HeaderFilterStrategy enables modification of downstream producer behavior in the route.

The camel-keycloak component in Apache Camel lacks validation of the access token's validity window. The helper function does not check whether the token is expired or not yet valid, accepting tokens outside their intended lifetime.

Vulnerability in Apache Camel Cometd component allows an attacker to inject arbitrary Camel control headers into the message exchange. Missing HeaderFilterStrategy causes client-supplied headers, including internal Camel headers (e.g., CamelHttpUri, CamelFileName), to be copied unmodified. Default lack of authentication (Bayeux SecurityPolicy) lets any client publish such messages.

A deserialization vulnerability in the Apache Camel PQC component allows untrusted data deserialization from AWS Secrets Manager. The flaw stems from missing input filtering during Java object deserialization, potentially leading to remote code execution.

A vulnerability in the camel-docling component of Apache Camel allows CLI argument injection and directory traversal due to insufficient validation of exchange headers. Attackers can supply unauthorized flags or paths that escape the intended directory, leading to unexpected operations by the external docling tool.

Apache Camel vulnerability allows injection of internal headers via untrusted HTTP requests to CXF and Knative endpoints. Missing inbound header filtering lets an attacker override critical Camel headers, potentially leading to remote code execution or arbitrary file writes.

A vulnerability in the Apache Camel Camel-Coap component allows an unauthenticated attacker to achieve remote code execution by sending a single CoAP UDP packet. Lack of header filtering causes query parameters to be directly mapped to Camel headers, enabling injection of headers that control system command execution.

The Camel-Mail component in Apache Camel fails to filter MIME headers in the 'in' direction, allowing an attacker to inject Camel-specific headers by delivering a crafted email. The vulnerability affects versions from 3.0.0 to 4.14.5 and from 4.15.0 to 4.18.0.

A vulnerability in Apache Camel allows remote code execution via deserialization of untrusted data from JMS ObjectMessage. The issue affects camel-jms, camel-sjms, camel-sjms2, camel-amqp, camel-activemq, and camel-activemq6 components.

The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy but not to five other HeaderFilterStrategy implementations in Apache Camel. An attacker with JMS broker access can inject case-variant Camel headers, leading to remote code execution and arbitrary file write.

Apache Camel's unmarshalling operations using Jackson and JacksonXML are vulnerable to Remote Code Execution attacks.

The vulnerability in Apache Camel's OAuth component stems from a static token cache shared by every resolver instance in the JVM, keyed only on the token endpoint and client ID. Profiles that share an endpoint and client ID but differ in scope or client secret therefore receive each other's tokens, potentially granting broader authority or reaching a service the token was not issued for.

FopProducer transforms the incoming XSL-FO body by creating a TransformerFactory via TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, that feature alone does not restrict external resource access, so an external DTD or entity declared in the XSL-FO document is resolved and expanded. An external sender can therefore read files readable by the Camel process and cause it to issue requests to hosts the document names.

Improper Restriction of XML External Entity Reference (XXE) vulnerability in the Smooks component (camel-smooks) of Apache Camel. The default Woodstox SAX parser resolves external entities and loads external DTDs, allowing an attacker to read local files or issue requests to internal network locations via the XML body. Affects versions from 4.7.0 before 4.18.5 and from 4.19.0 before 4.22.1.

A use of cache containing sensitive information vulnerability exists in the Apache Camel HTTP component. The JVM-global OAuth2 token cache key omitted the requested scope, resource indicator and token endpoint, so two endpoints differing only in those fields shared a cache entry and an endpoint could be served a token minted for a different scope, resource or authorization server.

An insufficient granularity of access control vulnerability exists in the Apache Camel Platform HTTP component. The component decided proxy mode by testing whether the configured path started with the string "proxy" rather than matching exactly, so endpoints such as proxyStatus or proxy-config became proxies without the route author's intent and forwarded requests onward.

A generation of error message containing sensitive information vulnerability exists in the Apache Camel gRPC component. When a route behind a gRPC consumer failed, the exception message was placed into the gRPC status description, which is transmitted to the calling client, so an external caller could read internal error messages including class and package names, paths, host names and connection details.

An improper input validation vulnerability exists in the Apache Camel Mail component. The MimeMultipart data format retained an unfiltered path where unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied, so an external sender could set them and influence how a downstream mail producer connects and sends.

A permissive cross-domain policy with untrusted domains vulnerability exists in the Apache Camel Jetty component. Setting enableCORS installed Jetty's CrossOriginFilter with stock defaults accepting every origin and allowing credentials, so a page on any origin could make credentialed cross-origin requests and read responses.

An improper input validation vulnerability exists in the Apache Camel Core component. The saga processor consulted a header named Long-Running-Action without a Camel prefix, so an external sender could supply it on an inbound message and name the saga the exchange joined, attaching their request to a long-running action started by someone else.

An improper authentication vulnerability exists in the Apache Camel Keycloak component. The security processor validated the token issuer only when the introspection response contained an iss claim; when absent, the check was skipped rather than treated as a failure, potentially allowing tokens from an unintended issuer to be accepted.

An incorrect default permissions vulnerability exists in the Apache Camel PQC component. When writing generated key material to disk, the component used the process default umask rather than restricting the file to its owner, potentially allowing other local accounts to read the private key.

An exposure of data element to wrong session vulnerability exists in the Apache Camel AS2 component. Signing material for an individual request was stored in state shared across requests, so with multiple trading partners a Message Disposition Notification could be signed with another partner's key.

An improper handling of case sensitivity vulnerability exists in the Apache Camel Platform HTTP component. The guard preventing request header reflection into the response compared header names case sensitively, while HTTP header names are case insensitive, allowing bypass by varying case; under HTTP/2 the suppression was inert for every request.

A sensitive information exposure vulnerability in the Apache Camel HTTP component. With followRedirects=true, credentials (OAuth2 Bearer token and basic/digest credentials) were re-attached to requests sent to the host named in the redirect Location header rather than the host configured in the route. A remote endpoint could therefore collect the credentials by responding with a redirect to a host it controls.

XML External Entity (XXE) vulnerability in the Apache Camel XPath component. With documentType set to InputSource, XPathBuilder passed the payload directly to javax.xml.xpath, which built its own DocumentBuilder using JDK defaults, bypassing Camel's hardening. An external sender whose XML reached such an expression could read files readable by the Camel process and cause it to issue requests to named hosts.

An improper input validation vulnerability exists in the Apache Camel Tika component. The Tika producer mapped every metadata key parsed from the submitted document onto the Exchange as a header without filtering, allowing attacker-controlled document content to set Camel namespace headers such as CamelFileName.

A race condition vulnerability exists in the Apache Camel PQC component due to concurrent execution using a shared resource with improper synchronization. The producer held a single java.security.Signature instance for every exchange without synchronization, causing interleaved update and verify calls under concurrent traffic.

Improper Certificate Validation vulnerability in Apache Camel Knative component. When SSL was enabled on the Knative HTTP client but no truststore was configured, the client fell back to trusting every presented certificate instead of the JVM's default trust anchors. An attacker positioned on the network path can terminate and read the encrypted connection.

A vulnerability in the Apache Camel Thrift component causes incoming data to be unmarshalled into the shared defaultInstance of the target type rather than a fresh copy. As a result, state from one message remains visible to subsequent messages of the same type, potentially leading to data disclosure between different senders.

A vulnerability in the Apache Camel Shiro component skips credential verification when the subject already bound to the current thread carries the same principal as the incoming exchange. Because threads are pooled and reused, a subject left bound by an earlier authenticated exchange can satisfy the check for a later exchange that presents no valid credentials.

A vulnerability in the Apache Camel Platform HTTP Vertx component involves improper CORS handling: the Access-Control-Allow-Credentials: true header is sent regardless of the origin check result, and when camel.server.cors.origins is unset the handler reflects any origin in Access-Control-Allow-Origin. As a result, any page can make credentialed cross-origin requests to the Camel endpoint and read the responses.

A Code Injection and Expression Language Injection vulnerability in Apache Camel (versions 4.4.0–4.18.4, 4.19.0–4.22.0) affects the dynamic-router-control endpoint. DynamicRouterControlProducer took the subscription predicate and expression language name from the incoming message (body fields or CamelDynamicRouterPredicate and CamelDynamicRouterExpressionLanguage headers) and compiled them without an allow-list or opt-in. This allowed arbitrary expressions to be evaluated with the privileges of the Camel process.

The AS2 component in Apache Camel (versions 4.0.0–4.18.4 and 4.19.0–4.22.0) lets the message sender choose the asynchronous MDN notification address that Camel then connects to. This results in SSRF from the AS2 receiver's position, including reaching hosts routable only from the internal network, and configured MDN credentials may be exposed to the attacker.

The Netty HTTP component in Apache Camel (versions 4.0.0–4.18.4 and 4.19.0–4.22.0) compares the request path against the security context path case-sensitively, while routing does not. Changing the case of a path segment bypasses the security constraint and reaches the protected route without satisfying it.

A vulnerability in the Apache Camel OAuth component causes camel-oauth processors guarding a route to not stop the exchange when authentication cannot be completed. As a result, an unauthenticated caller can reach the protected endpoint as though authentication had succeeded (fail-open). This affects Apache Camel from 4.11.0 before 4.18.5 and from 4.19.0 before 4.22.1.

A path traversal vulnerability in the Apache Camel FTP component allows reading, deleting, or renaming files outside the configured remote directory. This is due to missing normalization and containment checks when concatenating the directory with the file name from the server's listing. It affects versions 4.0.0–4.18.4, 4.19.0–4.22.0, and the ftp, ftps, and sftp schemes.

A vulnerability in Apache Camel HTTP, Netty HTTP, Undertow and Vert.x HTTP components allows an inbound message sender to override the endpoint URI via the CamelHttpUri and CamelRestHttpUri headers, after which property placeholders in that string are resolved (environment variables, system properties, secret functions, bean invocations). This can lead to exposure of sensitive information and unexpected bean method invocation. The issue affects Apache Camel from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1.

An improper authentication vulnerability was found in Apache Camel Platform HTTP Main. When neither jwtIssuer nor jwtAudience was configured, the server only checked token signature and expiry, completely skipping validation of iss and aud claims. Affects versions 4.8.0 through 4.21.x; fixed in 4.22.0.

A Relative Path Traversal vulnerability in Apache Camel Google Storage component allows writing files outside the configured download directory. The camel-google-storage consumer does not normalize paths or verify that the destination stays within the allowed folder when downloadFileName is set. An attacker able to influence object names in the consumed bucket can cause Camel to create or overwrite arbitrary files with the privileges of the Camel process.