Andrea Cosentino

An issue in the Apache Camel A2A component allows for Server-Side Request Forgery (SSRF). The `WebhookUrlValidator` inconsistently classified push notification webhook hosts. Specifically, hosts provided as IP literals were checked against a prefix list for the IPv6 unique local range fc00::/7, while hosts provided as names were resolved and checked using `InetAddress` predicates. Because these predicates did not cover the fc00::/7 range, a webhook URL resolving to that range could bypass security guards. This allows an attacker to control the `TaskPushNotificationConfig.url` variable to trigger blind outbound HTTPS requests from the Camel process to internal addresses, potentially including Authorization headers. Additionally, the pre-check incorrectly blocked any hostnames starting with fc or fd, such as fcm.googleapis.com, regardless of whether they were IP literals.

The OAuth component contains an issue where the `OAuthClientCredentialsTokenResolver` stores OAuth 2.0 bearer tokens in a static cache shared across all resolver instances and `CamelContext` within the JVM. The cache is keyed only by the token endpoint and the client ID, ignoring the client secret and requested scope. Consequently, if multiple profiles share the same token endpoint and client ID but use different scopes or secrets, they may receive a token intended for a different profile. This can result in outbound requests carrying tokens with broader authority than intended or tokens meant for a different service. A compromised or hostile service receiving such a token could potentially replay it within its scope.

Improper restriction of XML External Entity (XXE) references in the Apache Camel Saxon component occurs because the `XQueryBuilder` in `camel-saxon` uses a default Saxon Configuration that accepts DOCTYPE declarations and resolves external entities. While Camel's XML type converters protect bodies of type String, byte[], or InputStream, bodies that are already a `javax.xml.transform.Source` (such as those created via `convertBodyTo(Source.class)`) are passed to Saxon unchanged. This allows an external sender to provide a crafted XML body that can be used to read local files accessible by the Camel process or force the process to make requests to external hosts.

The CoAP component in Apache Camel contains an issue where the `CamelCoapResource` catches exceptions occurring after a route completes and sends the exception message back to the CoAP client as a 5.00 Internal Server Error response. This typically happens during type conversion failures when the consumer converts the final message body to a `byte[]` payload or processes `CamelCoapMaxAge` and `CamelCoapETag` headers. Consequently, a remote client may obtain sensitive internal deployment details, including class and package names, file body paths, host names, and backend connection details. This occurs because the consumer lacks a mechanism to suppress these exceptions, unlike HTTP consumers.

Path Traversal issue in the Apache Camel Docling component. The `DoclingProducer` runs the external docling tool in CLI mode and uses the `--output` flag to specify the output directory. When the `CamelDoclingOutputFilePath` header is set, the `addOutputDirectoryArguments` function passes the value to the flag without normalization. This allows absolute paths or paths containing `..` segments, enabling an attacker who can set the header to create conversion output files in any directory accessible to the Camel process. The issue occurs when routes forward externally influenced values into the header or when consumers map incoming headers without filtering the Camel header namespace. The `docling-serve` mode is not affected.

Insufficient session expiration in the Apache Camel Keycloak component occurs when token introspection is enabled via `useTokenIntrospection=true`. The `KeycloakSecurityProcessor` validates access tokens by querying Keycloak's OAuth 2.0 token introspection endpoint. By default, results are cached using `ConcurrentMapTokenCache` or `CaffeineTokenCache` based on the `introspectionCacheTtl` setting. These caches expire entries after a fixed duration without considering the `exp` (expiration) claim of the token. Consequently, a token that expires shortly after being cached may still be accepted as active until the cache entry expires, allowing requests to be admitted with the expired token's roles and permissions. This behavior violates RFC 7662, which prohibits caching introspection responses beyond the `exp` time. This issue only affects the introspection path and does not impact local JWT verification.

A path traversal issue exists in the Apache Camel Docling component. The `DoclingProducer` constructs a command line for an external docling tool using arguments from the `CamelDoclingCustomArguments` header. While a safety check `validatePathSafety()` was implemented to prevent relative path traversal (e.g., using `../`), it fails to check for absolute paths. Consequently, an attacker who can control the custom arguments can provide an absolute path to point the docling process to any directory accessible by the Camel process, bypassing the intended directory restrictions. This occurs in the default CLI mode. The issue is exploitable if a route forwards external values into the header or if a consumer maps incoming headers without filtering the Camel header namespace.

Improper validation of the integrity check value in the Crypto PGP component occurs because the `unmarshal()` function only verified modification detection code for OpenPGP symmetrically encrypted integrity protected data packets. Older symmetrically encrypted data packets lack this code, and since OpenPGP's CFB mode is malleable without it, messages using these packets bypassed the integrity check. Because the sender determines the packet type, an attacker could rewrite messages in transit to avoid the check. Previously, the integrity option only applied to marshalling and lacked a decryption-side equivalent, preventing deployments from enforcing integrity protection on accepted messages.

An improper certificate validation issue exists in the Knative component. When SSL is enabled on the Knative HTTP client without a configured truststore, the client defaults to trusting all presented certificates instead of using the JVM default trust anchors. This results in an encrypted connection lacking peer authentication, allowing a network-positioned attacker to terminate and read the traffic. This state occurs by omission, meaning enabling TLS inadvertently disables certificate validation.

A race condition exists in the PQC component where the producer uses a single `java.security.Signature` instance for every exchange without proper synchronization. Because the `Signature` class is stateful and not thread-safe, the `update()` function (which accumulates data) and the `verify()` function (which consumes the state) can interleave when multiple exchanges occur concurrently. This non-deterministic behavior can lead to a verification reporting success for a message whose signature was not actually checked, compromising the security guarantees of the component. This issue is triggered by concurrent traffic through the same endpoint.

The Knative HTTP consumer in the Apache Camel Knative component fails to properly handle exchange processing failures on the consumer side. In such cases, the consumer writes the resulting exception—including the class name, message, and stack trace—directly back to the remote caller as the response body. This allows an external sender to trigger failures and obtain internal deployment details, such as class and package names, file system or host names, and the route structure. Additionally, if exception messages contain configuration or connection strings, this information is disclosed.

Apache Camel HTTP, Netty HTTP, Undertow, and Vert.x HTTP components contain an issue where inbound messages can override the endpoint URI using the `CamelHttpUri` and `CamelRestHttpUri` headers. These headers are processed through `CamelContext.resolvePropertyPlaceholders()`, which is a configuration-resolution facility. This allows an attacker to access operating-system environment variables, JVM system properties, registered `PropertiesFunction` secret functions (including AWS, Azure, GCP, HashiCorp, IBM, CyberArk, and Kubernetes), and invoke no-argument methods on any bean in the registry via `camel-bean`. Seven call sites are affected: - `HttpHelper.createURL()` and `HttpHelper.createMethod()` in camel-http-common - `HttpMethodHelper.createMethod()` in camel-http - `VertxHttpHelper.resolveHttpURI()` in camel-vertx-http - `UndertowHelper.createURL()` and `UndertowHelper.createMethod()` in camel-undertow - `NettyHttpHelper.createURL()` in camel-netty-http Certain HTTP consumers may automatically populate `CamelHttpUri` from the request line. Additionally, unresolvable placeholders can trigger a `RuntimeExchangeException` that echoes the URI, potentially revealing whether a configuration key is set.

A Cross-Site Request Forgery (CSRF) issue exists in the OAuth component. The authorization code callback lacks a state parameter to bind it to the initial authorization request and fails to verify one. This allows an attacker to associate an authorization code with a victim's session, leading to login CSRF where a victim is signed into an account controlled by the attacker. Additionally, the unvalidated callback handling enables an open redirect from a trusted origin by allowing the post-authentication redirect target to be influenced. These paths are accessible without interaction with the identity provider because the state check occurs before the authorization code is redeemed.

A path traversal issue exists in the Apache Camel FTP component affecting ftp, ftps, and sftp schemes. The remote-file consumers build absolute remote paths by concatenating the configured directory with file names from the server's directory listing without lexical normalization or containment checks. This allows a malicious or compromised remote server, or an on-path attacker manipulating the LIST response, to force Camel to read, delete, or rename files outside the intended polling directory using the endpoint's credentials. The issue occurs within `FtpUtils.absoluteFilePath` and `GenericFileConsumer`, affecting operations such as retrieval via `FtpOperations.retrieveFile` and `SftpOperations`, deletion via `GenericFileDeleteProcessStrategy`, and renaming via `GenericFileProcessStrategySupport` and `GenericFileRenameExclusiveReadLockStrategy`. The `jailStartingDirectory` option failed to constrain these remote operands.

The `camel-hazelcast` component fails to apply a `JavaSerializationFilterConfig` to Hazelcast instances created through specific configuration paths. This occurs when `ReplicatedHazelcastAggregationRepository` overrides the `doStart()` function without calling the super method, and when `HazelcastDefaultComponent#getOrCreateHzClientInstance()` builds a `ClientConfig` while `hazelcastMode` is set to `client` without a referenced `ClientConfig` or `hazelcastConfigUri`. Consequently, Java deserialization remains unrestricted. An attacker capable of publishing data to the connected Hazelcast cluster can trigger the deserialization of a crafted Java object within the serialization layer, leading to remote code execution. This risk is heightened as Hazelcast clusters do not enable authentication or TLS by default.

The Thrift component unmarshalled incoming data into a shared `defaultInstance` of the target type instead of a fresh copy, returning this shared object as the exchange body. Since the instance is shared process-wide, state from one message remained on the object and became visible to subsequent messages using the same type. This allows content from one sender to be read during the processing of another sender's message, or for concurrent exchanges to observe partially written state, leading to data disclosure in multi-tenant or multi-user deployments.

The Mina component fails to suppress sensitive information when an exchange processing failure occurs. The Mina consumer sends the result of `exchange.getException()` directly to the remote peer via the socket. Depending on the codec used, this may expose the exception class name, message, or the entire serialized exception and cause chain. An attacker capable of triggering a failure can obtain internal deployment details, including package names, file paths, host names, and connection details.

An improper authentication issue exists in the Apache Camel OAuth component. The `camel-oauth` processors designed to guard routes fail to stop the exchange when authentication cannot be completed. Instead of terminating the routing process and returning an error, the processors allow the request to proceed to the protected endpoint as if authentication had succeeded. This creates a fail-open authentication guard, allowing unauthenticated callers to access protected resources via the ordinary request path of a route configured for OAuth.

The HTTP Vertx component contains a permissive cross-domain policy. The `createCorsHandler()` function sets the Access-Control-Allow-Credentials header to true regardless of whether the origin check passed. When the `camel.server.cors.origins` variable is unset, the handler allows any origin and reflects the caller's Origin in the Access-Control-Allow-Origin header. This configuration allows pages from any origin to make credentialed cross-origin requests to the endpoint and read the responses.

An improper limitation of a pathname to a restricted directory, known as Path Traversal, exists in the Apache Camel Azure Files component. The issue occurs because remote-file consumers build absolute remote paths by concatenating the configured directory with file names from the server's directory listing without lexical normalization or containment checks. This allows a malicious or compromised remote server, or an on-path attacker, to provide a listing entry that resolves to a path outside the configured polling directory. Consequently, the application may read, delete, or rename files outside the intended directory using the endpoint's credentials. This flaw affects operations handled by `FtpUtils.absoluteFilePath` and `GenericFileConsumer`, impacting functions such as `FtpOperations.retrieveFile`, `GenericFileDeleteProcessStrategy`, and `GenericFileProcessStrategySupport`. The `jailStartingDirectory` option failed to constrain these remote operands.