Improper Handling of Case Sensitivity vulnerability in Apache Camel Platform HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The guard that prevents a request header being reflected into the response compared header names case sensitively, while HTTP header names are case insensitive. A caller could therefore defeat the suppression simply by varying the case of the header name. HTTP/2 makes the problem unconditional rather than optional: the protocol requires header names to be lowercase on the wire, so the comparison never matched and the suppression was inert for every request on an HTTP/2 connection. The consequence is that content the caller chose is echoed back in the response, which is the basis for response-splitting and cache-poisoning style attacks against whatever sits in front of the Camel endpoint.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Request header names are now compared case insensitively, so the suppression holds regardless of casing and works under HTTP/2. For deployments that cannot upgrade immediately, strip the headers in question in front of the Camel endpoint, or remove them from the response in the route rather than relying on the built-in suppression.
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Two paths handed credentials to a redirect target, which is a host chosen by the remote server rather than by the route, once followRedirects=true. OAuth2ClientConfigurer registers its interceptor with addRequestInterceptorFirst, and HttpClient runs protocol-level request interceptors inside ProtocolExec, which sits below RedirectExec in the exec chain; the interceptor therefore ran again for every redirect hop and re-attached Authorization: Bearer to whatever host the Location header named. Separately, credentials were registered against an AuthScope matching any host, so basic and digest credentials were presented to a redirect target as well. A remote endpoint - or anyone who can influence its responses - could therefore collect the bearer token or the configured credentials simply by answering with a redirect to a host it controls.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Credentials are now sent only to the authority the endpoint was configured with, and are not re-attached when a redirect crosses to another host. For deployments that cannot upgrade immediately, set followRedirects=false on endpoints that carry credentials, and handle any redirect explicitly in the route so that the destination is chosen by the route rather than by the remote server.
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
With documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel's default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type's documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design. For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE.
Improper Input Validation vulnerability in Apache Camel Tika component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The Tika producer mapped every metadata key parsed out of the submitted document onto the Exchange as a header, with no filter applied. Document metadata is attacker-controlled content: the party that supplies the file chooses the metadata keys it carries. A crafted document could therefore set Exchange headers that the rest of the route depends on, including headers in the Camel namespace such as CamelFileName, which downstream components use to decide where content is written. The pattern is the same header-injection class as the consumer advisories published previously, reached here through parsed file content rather than through a protocol header.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing. For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders("Camel*") before any component that acts on those headers.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Camel PQC component.
This issue affects Apache Camel: from 4.12.0 before 4.18.5, from 4.19.0 before 4.22.1.
The producer held a single java.security.Signature instance and used it for every exchange without synchronizing access. Signature is stateful and is not thread safe: update() accumulates the data to be signed or verified, and verify() consumes that accumulated state. With concurrent exchanges sharing one instance the update and verify calls of different messages interleave, so a verification can complete against data that belongs to another exchange, or against a partially accumulated buffer. The outcome is non-deterministic and includes a verification reporting success for a message whose signature was never actually checked, which defeats the guarantee the component exists to provide. Reaching it requires concurrent traffic through the same endpoint, which is the ordinary condition for a Camel route under load.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The Signature instance is no longer shared across concurrent exchanges. For deployments that cannot upgrade immediately, restrict the affected route to a single concurrent consumer so that no two exchanges use the instance at once.
Improper Certificate Validation vulnerability in Apache Camel Knative component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When SSL was enabled on the Knative HTTP client but no truststore was configured, the client options fell back to trusting every presented certificate rather than to the JVM's default trust anchors. A deployment that switched TLS on without also configuring a truststore therefore obtained an encrypted connection with no peer authentication, which an attacker positioned on the network path can terminate and read. The dangerous state is reached by omission rather than by an explicit opt-in, which is what makes it a framework defect: turning TLS on should not be the thing that turns certificate validation off.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. With no truststore configured the trust options are now left unset so the JVM default trust anchors apply, the same fallback SSLContextParameters and the rest of Camel use. Trusting every certificate is now reached only by asking for it explicitly through the trust.all property, which remains available for development against a cluster with a self-signed certificate. For deployments that cannot upgrade immediately, configure a truststore explicitly wherever SSL is enabled. After upgrading, a deployment that was relying on the implicit trust-all behaviour must either configure a truststore or set the trust.all property deliberately.
CVE-2026-85245 is a vulnerability in Apache Camel's Thrift component where unmarshalling incoming data uses a shared instance, causing data from one message to be exposed to others. This affects Apache Camel versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. The flaw allows data from one tenant or user to be visible to another when served through the same route. The issue is fixed in Apache Camel 4.23.0, 4.18.5, and 4.22.1. Users unable to upgrade immediately should copy the unmarshalled body to a new instance to avoid data leakage.
CVE-2026-85243 is a vulnerability in Apache Camel's Crypto PGP component affecting versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. The issue arises because the unmarshal() function only verifies the modification detection code for OpenPGP symmetrically encrypted integrity protected data packets, but older packet types lack this integrity check. This allows an attacker who can modify messages in transit to bypass integrity validation. Apache Camel 4.23.0, 4.18.5, and 4.22.1 include fixes that add a requireIntegrityProtection option to enforce integrity checks on incoming messages.
CVE-2026-84178 is a Cross-Site Request Forgery (CSRF) vulnerability in the Apache Camel OAuth component affecting versions from 4.11.0 before 4.18.5 and from 4.19.0 before 4.22.1. The flaw allows an attacker to redeem an authorization code obtained in any browser at the callback, associating it with the victim's session, which can silently sign the victim in as the attacker-controlled identity. This also enables an open redirect from a trusted origin due to unvalidated post-authentication redirect targets. The issue is fixed in Apache Camel versions 4.18.5 and 4.22.1 and later.
CVE-2026-83531 is a code injection vulnerability in Apache Camel affecting versions from 4.4.0 before 4.18.5 and from 4.19.0 before 4.22.1. It arises from the dynamic-router-control endpoint allowing untrusted expressions to be compiled and evaluated with Camel process privileges. Exploitation requires the ability to send messages to a transport routed to this endpoint, with no additional authentication needed. The issue is fixed in versions 4.18.5, 4.22.1, and later 4.23.0.
CVE-2026-80344 is a Server-Side Request Forgery (SSRF) vulnerability in the Apache Camel AS2 component. The flaw allows a remote attacker to specify an arbitrary host for asynchronous Message Disposition Notification (MDN) delivery, potentially causing the server to connect to internal or unauthorized hosts. This can expose internal network resources and leak credentials used for MDN delivery. The vulnerability affects Apache Camel versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. Fixed versions are 4.18.5 and 4.22.1, and 4.23.0 is the latest version that addresses the issue. Mitigation includes upgrading to fixed versions or restricting outbound connectivity and credential usage for MDN delivery.
CVE-2026-80343 is a high-severity vulnerability in Apache Camel's Netty HTTP component affecting versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. The issue arises from inconsistent case sensitivity handling between the security constraint and request routing, allowing an attacker to bypass security constraints by altering the case of characters in the request path. This bypass enables access to protected routes without credentials or special configuration. Fixed versions are 4.18.5 and 4.22.1, which align case sensitivity rules between the constraint and routing. Until upgrading, users should place authorization checks before the Camel consumer, such as in a reverse proxy that normalizes request paths.
Improper Authentication vulnerability in Apache Camel OAuth component.
This issue affects Apache Camel: from 4.11.0 before 4.18.5, from 4.19.0 before 4.22.1.
The camel-oauth processors that guard a route did not stop the exchange when authentication could not be completed. Where a failure to establish an authenticated session should have terminated routing and returned an error to the caller, the processors fell through and returned control to the route, so the request continued to the protected endpoint as though authentication had succeeded. The effect is a fail-open authentication guard: an unauthenticated caller reached whatever the route did next. The condition is reached on the ordinary request path of a route configured to require OAuth, and needs no special configuration or prior access on the caller's part.
Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The processors now stop the exchange and set the appropriate error status whenever an authenticated session cannot be established, so a failed authentication no longer reaches the protected part of the route. For deployments that cannot upgrade immediately, place an explicit authorization check after the OAuth processor rather than relying on it to halt the exchange, and verify that the route stops on failure.
CVE-2026-79986 is a path traversal vulnerability in Apache Camel's Azure Files component and other remote-file consumers. The flaw allows an attacker controlling the remote server or an on-path attacker to craft directory listings with path segments that escape the configured polling directory. This enables unauthorized reading, deletion, or renaming of files outside the intended directory using the endpoint's credentials. The vulnerability affects Apache Camel versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. Fixed versions are 4.18.5 and 4.22.1, with 4.23.0 recommended for later streams.
CVE-2026-79983 is a path traversal vulnerability in the Apache Camel FTP component affecting versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. The vulnerability allows an attacker controlling the FTP server or an on-path attacker to craft directory listings with file names that escape the configured polling directory. This leads to unauthorized read, delete, or rename operations on files outside the intended directory using the endpoint's credentials. The issue affects ftp, ftps, and sftp schemes. The vulnerability is fixed in Apache Camel versions 4.18.5 and 4.22.1.
CVE-2026-78165 is a deserialization of untrusted data vulnerability in the Apache Camel Spring Redis component affecting versions from 2.11.0 before 4.18.5 and from 4.19.0 before 4.22.1. The vulnerability arises because the component uses a default Java serialization mechanism without applying any object input filtering, allowing arbitrary serialized objects to be deserialized and their readObject methods executed. This occurs before any route logic can inspect the message, exposing the system to potential remote code execution if an attacker can publish messages to subscribed Redis channels. The issue is fixed in Apache Camel versions 4.18.5, 4.22.1, and later 4.23.0. Mitigations include upgrading to fixed versions, setting JVM-wide serialization filters, configuring non-Java serializers, and restricting Redis access.
CVE-2026-78164 is a high-severity vulnerability in Apache Camel HTTP, Netty HTTP, Undertow, and Vert.x HTTP components. It involves improper neutralization of special elements used in a template engine, allowing inbound messages to override endpoint URIs via headers that are processed through a property-placeholder resolution mechanism. This can lead to exposure of sensitive information and unintended configuration or bean method invocation. The issue affects Apache Camel versions from 4.0.0 before 4.18.5 and from 4.19.0 before 4.22.1. Fixed versions are 4.18.5 and 4.22.1, with 4.23.0 recommended for the latest fixes. Mitigations include upgrading to fixed versions or stripping override headers at the trust boundary, or setting skipControlHeaders=true on camel-http endpoints. The vulnerability is not mitigated by bridgeEndpoint=true or percent-encoding placeholder delimiters.
CVE-2026-78163 is a Server-Side Request Forgery (SSRF) vulnerability in the Apache Camel Docling component affecting versions from 4.15.0 before 4.18.5 and from 4.19.0 before 4.22.1. The vulnerability arises because the DoclingProducer interprets message body prefixes to decide how to process them, allowing untrusted input to trigger remote URL fetches or local file reads without explicit configuration. This implicit mode selection can lead to unauthorized access to remote or local resources. The issue is fixed in Apache Camel versions 4.18.5 and 4.22.1. Users unable to upgrade immediately should avoid routing external message bodies into Docling endpoints or use typed bodies or headers to prevent prefix interpretation.
This update for google-osconfig-agent fixes the following issue:
- CVE-2026-63209: github.com/klauspost/compress: signed integer overflow in s2.NewDict() allows an attacker to bypass
repeat index validation and cause a process crash (bsc#1283672).
Changes for google-osconfig-agent:
- Update to version 20260928.01
* scalibr linux new metadata support (#1038)
* Fix failing to report REBOOTING state during postPatchReboot
due to context canceled for Windows VMs (#1055)
* Fix os/snap extractor usage (#1053)
- Update github.com/klauspost/compress to v1.18.7
(bsc#1283672, CVE-2026-63209)
* bump grpc package to new version (#1057)
* bump some dependencies across few modules (#1056)
Red Hat OpenShift Container Platform 4.22.18 includes a security update addressing a denial of service vulnerability in the Go HTTP/2 implementation. The flaw (CVE-2026-33814) involves processing a malformed SETTINGS_MAX_FRAME_SIZE frame, which can cause a denial of service. Users of OpenShift Container Platform 4.22 are advised to upgrade to the updated packages and container images provided in this release to mitigate the issue.