Yu Bao

**Name of the Vulnerable Software and Affected Versions** mwiede jsch versions prior to 2.28.6 **Description** A security flaw exists in the `getRevokedKeys()` function within the `src/main/java/com/jcraft/jsch/KnownHosts.java` file. A remote attacker can manipulate the `known hosts` argument to cause an improper check for certificate revocation. This attack is characterized by high complexity and is difficult to exploit. **Recommendations** Upgrade to version 2.28.6.

**Name of the Vulnerable Software and Affected Versions** LatencyUtils versions prior to 2.0.4 **Description** Local manipulation of the `recordDetectedPause()` function within the `PauseDetector` component can lead to memory corruption. This issue occurs in the file src/main/java/org/LatencyUtils/LatencyStats.java. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability. As a temporary workaround, consider restricting the use of the `recordDetectedPause()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Spring Integration versions 6.4.0 through 6.4.12 Spring Integration versions 6.5.0 through 6.5.10 Spring Integration versions 7.0.0 through 7.0.5 Spring Integration version 7.1.0 **Description** The `UnZipTransformer` does not limit the decompressed entry size or the entry count when processing archives. This allows an attacker to send a specially crafted zip archive, known as a zip-bomb, which can exhaust the JVM heap memory and lead to a denial-of-service outage. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Spring Authorization Server versions 1.4.0 through 1.4.11 Spring Authorization Server versions 1.5.0 through 1.5.8 **Description** The default consent page renders user-controlled values without HTML entity encoding. When using the `DefaultConsentPage`, an attacker can craft an OAuth2 authorization request containing a malicious value that is stored server-side and subsequently rendered unencoded in the consent page presented to the end user. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Spring Security versions 7.0.0 through 7.0.6 Spring Security version 7.1.0 **Description** The default consent page of the Spring Security Authorization Server renders user-controlled values without applying HTML entity encoding. This lack of encoding can lead to the execution of malicious scripts in the user's browser. **Recommendations** Update Spring Security versions 7.0.0 through 7.0.6 to a patched version. Update Spring Security version 7.1.0 to a patched version.

**Name of the Vulnerable Software and Affected Versions** Spring Security version 7.1.0 Spring Security versions 7.0.0 through 7.0.6 Spring Security versions 6.5.0 through 6.5.11 Spring Security versions 6.4.0 through 6.4.18 **Description** An application using WebAuthn support may be vulnerable to user verification bypass when utilizing a distributed HTTP session store. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Reactor Netty versions 1.0.0 through 1.0.52 Reactor Netty versions 1.1.0 through 1.2.18 Reactor Netty versions 1.3.0 through 1.3.6 **Description** An issue exists where the Reactor Netty HTTP server consumes an excessive amount of memory when a client sends HTTP/1.1 pipelined requests over a single connection. Pipelining is a technique where multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Spring Integration versions 7.0.0 through 7.0.5 Spring Integration versions 6.5.0 through 6.5.10 Spring Integration versions 6.4.0 through 6.4.12 Spring Integration versions 5.5.x and earlier Spring Integration version 7.1.0 **Description** The `RFC6587SyslogDeserializer`, utilized by the Spring Integration syslog TCP inbound adapter to decode RFC 6587 and RFC 5424 frames, contains a flaw where it trusts the octet count provided by the sender. This allows the system to allocate a byte array of the specified size without an upper bound, potentially leading to a heap overflow (a condition where a program writes more data to a heap-allocated memory block than it can hold). **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Spring Security version 7.1.0 Spring Security versions 7.0.0 through 7.0.6 Spring Security versions 6.5.0 through 6.5.11 **Description** An authentication bypass issue exists in the `DPoPProofJwtDecoderFactory` due to a cache-based replay attack. The internal cache used for storing JWT ID claims has a strict size limit. An attacker can flood the server with dummy requests to evict legitimate entries from the cache, enabling the replay of intercepted valid DPoP proofs. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache HttpComponents Client versions 5.0-alpha1 through 5.6.2 **Description** HttpClient based on the classic i/o model fails to correctly release the underlying connection back to the connection manager when it encounters an invalid or unsupported `Content-Encoding` header value in the response message. This failure can lead to connection pool exhaustion, resulting in a Denial of Service (DoS). This issue does not affect HttpClient based on the async i/o model. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation in the Apache Camel Mail Component allows for the exposure of sensitive information. The `MailProducer.getSender()` function scans outgoing exchanges for message headers within the `mail.smtp.` and `mail.smtps.` namespaces. If present, these values are applied as JavaMail session properties, overriding the endpoint configuration. Since this namespace is not blocked by any `HeaderFilterStrategy`, untrusted input from protocols such as HTTP query parameters, request headers, JMS, or Kafka can be used to manipulate the producer. In versions prior to 4.19.0, an attacker can set the `mail.smtp.host` variable to redirect the SMTP connection to a malicious server, leading to the theft of configured usernames and passwords. In versions 4.19.0 and later, the impact is limited to weakening transport security via variables such as `mail.smtp.ssl.trust`, `mail.smtp.starttls.enable`, or `mail.smtp.socks.host`, potentially allowing the interception of outgoing messages. **Recommendations** Upgrade Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Upgrade Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. As a temporary workaround, use `removeHeaders('mail.smtp.*')` and `removeHeaders('mail.smtps.*')` to strip the namespace between any untrusted ingress and the smtp/smtps producer. Restrict the use of per-message overrides by ensuring `useJavaMailSessionPropertiesFromHeaders` is set to false, enabling it only on trusted endpoints.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation in the Apache Camel Lucene Component allows for authorization bypass through user-controlled keys. The `camel-lucene` producer reads search phrases from an Exchange header `LuceneConstants.HEADER QUERY` (with the value `QUERY`) and `HEADER RETURN LUCENE DOCS` (with the value `RETURN LUCENE DOCS`). Since these names lack the `Camel` or `camel` prefix, the `HttpHeaderFilterStrategy` allows them to pass from inbound HTTP requests into the Exchange. In routes exposing Lucene query operations via an HTTP consumer, an attacker can set the `QUERY` header to execute arbitrary queries against the full-text index, overriding intended filters. This can lead to unauthorized access to documents or high CPU consumption through expensive regular-expression queries. No credentials are required if the HTTP consumer is unauthenticated. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS stream. Upgrade to version 4.18.3 for those on the 4.18.x stream. After upgrading, routes setting the query via raw header names must use `CamelLuceneQuery` and `CamelLuceneReturnLuceneDocs` instead of `QUERY` and `RETURN LUCENE DOCS`. As a temporary mitigation, strip the `QUERY` and `RETURN LUCENE DOCS` headers before the Lucene producer and set the query from a trusted source.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.14.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** An issue exists where the default ObjectInputFilter pattern used for deserialization filtering in several components allows classes that perform network I/O, such as `java.net.URL` and `java.net.InetAddress`. An attacker can send a Java-serialized payload containing a `HashMap` with `java.net.URL` keys to an affected consumer. This triggers the JVM to issue DNS queries to an attacker-controlled host during deserialization, creating an out-of-band side channel. The risk is most significant in the `camel-jms` family because the `extractBodyFromJms()` function in `JmsBinding` unconditionally invokes `getObject()` when the `mapJmsMessage` variable is set to true. Affected components include `camel-jms`, `camel-sjms`, `camel-amqp`, `camel-mina`, `camel-netty`, `camel-netty-http`, `camel-vertx-http`, `camel-infinispan`, and aggregation repository components `camel-leveldb`, `camel-cassandraql`, `camel-consul`, and `camel-sql`. **Recommendations** Update Apache Camel versions 4.14.0 through 4.14.7 to version 4.14.8. Update Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Update Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. Configure a JMS-provider-side allow-list using `deserializationAllowList` or `deserializationDenyList` in Apache ActiveMQ Artemis, or `org.apache.activemq.SERIALIZABLE PACKAGES` in Apache ActiveMQ Classic. Override the default filter via the `deserializationFilter` option at the endpoint level or the `-Djdk.serialFilter` JVM system property using the pattern `!java.net.**;java.**;javax.**;org.apache.camel.**;!*` (or `!java.net.**;java.**;org.apache.camel.**;!*` for aggregation-repository components).

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation exists in the `camel-aws2-sns` component. The `Sns2HeaderFilterStrategy` originally lacked an inbound filter rule, only configuring an outbound filter via `setOutFilterPattern` to block `Camel*`, `breadcrumbId`, and `org.apache.camel.*` headers. While a similar gap in the `camel-aws2-sqs` component allowed the injection of Camel control headers through `HeaderFilterStrategy.applyFilterToExternalHeaders`, this is not exploitable in `camel-aws2-sns` because the `Sns2Endpoint` is producer-only and does not support consumers, as `createConsumer()` throws an `UnsupportedOperationException`. This update is a defense-in-depth hardening measure to align the configuration with other strategies by adding a `setInFilterStartsWith` rule for the Camel namespace. **Recommendations** Update Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Update Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Update Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. Apply least-privilege IAM permissions on SNS topics as a general best practice.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** An injection and Server-Side Request Forgery (SSRF) issue exists in the Apache Camel Solr component. The `camel-solr` producer copies Exchange message headers starting with the `SolrParam.` prefix into Solr request parameters and those starting with `SolrField.` into indexed Solr document fields. Because these prefixes do not start with the `Camel` or `camel` namespace, the `HttpHeaderFilterStrategy` allows them to pass from inbound HTTP requests into the Exchange. In routes bridging an HTTP consumer to a `solr:` producer, an unauthenticated attacker can inject arbitrary Solr request parameters via `SolrParam.*` headers—such as `shards` or `stream.url` to trigger SSRF toward internal services or cloud metadata endpoints, or `qt` to access administrative handlers—and inject arbitrary fields into documents via `SolrField.*` headers. **Recommendations** Upgrade Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Upgrade Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. After upgrading, update routes that set Solr parameters or fields to use `CamelSolrParam.` and `CamelSolrField.` instead of `SolrParam.` and `SolrField.`. As a temporary mitigation, strip `SolrParam.*` and `SolrField.*` headers from untrusted ingress before they reach the `solr:` producer and set required parameters from a trusted source within the route.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation in the Apache Camel Cometd component allows unauthenticated users to inject arbitrary Camel control headers. The `CometdBinding.populateExchangeFromMessage()` function copies the `ext.CamelHeaders` map from the CometD client directly into the Camel message without using a HeaderFilterStrategy. Since no Bayeux SecurityPolicy is installed by default, any client completing the Bayeux handshake can publish messages that modify internal control headers such as `CamelHttpUri`, `CamelFileName`, or `CamelJmsDestinationName`. This can lead to the redirection of HTTP producers, modification of file names, or overriding of JMS destinations, with the injected headers persisting across internal direct, seda, and vm hops. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS releases stream. Upgrade to version 4.18.3 for those on the 4.18.x releases stream. Strip Camel control headers from inbound CometD messages using `removeHeaders('Camel*')` and `removeHeaders('camel*')` at the start of the route. Install an explicit Bayeux SecurityPolicy on the CometdComponent to ensure only authenticated clients can publish messages.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.3.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** Improper input validation in the camel-elasticsearch-rest-client component allows for authorization bypass. The component uses unprefixed header constants—`SEARCH QUERY`, `OPERATION`, `INDEX NAME`, `INDEX SETTINGS`, and `ID`—which are not blocked by the `HttpHeaderFilterStrategy` because they lack the required 'Camel' or 'camel' prefix. When a route exposes an HTTP entry point before an elasticsearch-rest-client producer, an untrusted client can provide these headers to override configured queries and operations. This can lead to unauthorized actions such as reading all documents in an index, deleting documents, or exfiltrating specific fields without requiring credentials. **Recommendations** Upgrade to version 4.21.0. Upgrade to version 4.14.8 for those on the 4.14.x LTS stream. Upgrade to version 4.18.3 for those on the 4.18.x stream. As a temporary mitigation, strip the `SEARCH QUERY`, `OPERATION`, `INDEX NAME`, `INDEX SETTINGS`, and `ID` headers from untrusted inbound messages before they reach the producer. Apply a custom `HeaderFilterStrategy` that blocks the aforementioned header names.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.18.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.x **Description** Insufficient session expiration in the Apache Camel Keycloak Component occurs because the `KeycloakSecurityHelper.parseAndVerifyAccessToken()` function fails to apply the `IS ACTIVE` predicate. This predicate is responsible for validating the `exp` (expiration) and `nbf` (not-before) claims of a token. Consequently, while the helper verifies the token signature, subject, and issuer, it does not enforce the validity window, allowing expired or not-yet-valid access tokens to be accepted as valid for inbound request authentication. **Recommendations** Upgrade to version 4.18.3 for those on the 4.18.x release stream. Upgrade to version 4.21.0. As a temporary mitigation, validate the `exp` and `nbf` claims of the access token within the route before trusting it. Keep Keycloak access-token lifetimes short. Ensure any upstream gateway or resource server validates the token validity window.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.0.0 through 4.14.7 Apache Camel versions 4.15.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.9 **Description** An improper input validation issue exists in the Apache Camel CXF SOAP component, leading to a confused-deputy redirection. The `camel-cxf` producer determines which SOAP operation to invoke on a backend service using the `operationName` and `operationNamespace` Exchange headers. Because these headers lacked the required Camel prefix, the `HttpHeaderFilterStrategy` failed to block them at the HTTP boundary. Consequently, an unauthenticated HTTP client could manipulate these headers to force the `CxfProducer` to execute a different WSDL operation than intended, such as replacing a read-only operation with a destructive one. This issue also affects `camel-cxfrs` due to the shared `camel-cxf-common` module. **Recommendations** Upgrade Apache Camel versions 4.0.0 through 4.14.7 to version 4.14.8. Upgrade Apache Camel versions 4.15.0 through 4.18.2 to version 4.18.3. Upgrade Apache Camel versions 4.19.0 through 4.20.9 to version 4.21.0. As a temporary mitigation, strip the `operationName` and `operationNamespace` headers from untrusted ingress before they reach the `cxf:` producer and define the operation from a trusted source within the route.

**Name of the Vulnerable Software and Affected Versions** Apache Camel versions 4.18.0 through 4.18.2 Apache Camel versions 4.19.0 through 4.20.x **Description** Deserialization of untrusted data in the Apache Camel PQC component occurs when `HashicorpVaultKeyLifecycleManager`, `AwsSecretsManagerKeyLifecycleManager`, and `FileBasedKeyLifecycleManager` read key metadata from secret backends. These components use `java.io.ObjectInputStream.readObject()` to deserialize Base64-wrapped values without an `ObjectInputFilter` or class allow-list. An attacker with write access to the HashiCorp Vault KV path or AWS Secrets Manager secret can store a crafted serialized object. When the application performs normal key-lifecycle operations, the object is deserialized, potentially leading to remote code execution in the application context. **Recommendations** Upgrade to version 4.18.3 for those on the 4.18.x LTS release stream. Upgrade to version 4.21.0. Restrict write access to the key backend so only the application identity can write secrets using least-privilege HashiCorp Vault policies and `secretsmanager:PutSecretValue` IAM permissions. Store PQC key material in a backend separate from data accessible to less-trusted principals.