Vulnerabilities exploitable today
14,862in current view
Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.
In KEV catalog1,748
New KEV · 24H0
Exploit Today ≥ 701,665
Distribution · last window
- Critical3,347
- High15,203
- Medium14,178
- Low1,360
Filters
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-1118296.5 MED—
——0Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in WP Mailster WP Mailster wp-mailster allows PHP Local File Inclusion.This issue affects WP Mailster: from n/a through 1.9.1.0.1dCVE-2026-1118284.3 MED—
——0Improper Validation of Specified Quantity in Input vulnerability in Mamunur Rashid Classified Listing classified-listing allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Classified Listing: from n/a through 6.1.5.1dCVE-2026-1109024.3 MED—
——0Authorization Bypass Through User-Controlled Key vulnerability in Liquid Web / StellarWP Event Tickets event-tickets allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Event Tickets: from n/a through 5.30.1.1dCVE-2026-1100084.2 MED—
——0@fastify/oauth2 is a Fastify wrapper for OAuth2 login flows. In versions 7.2.0 through 8.3.1, the state and code-verifier cookies are set without a Path attribute at a login route with two or more path segments, while the clearing step at the OAuth callback writes them with a root path, so the original cookies survive the callback and the documented single-use guarantee for the state value does not hold. A state value an attacker learns stays valid for the rest of the browser session, letting the attacker drive their own authorization flow in the victim's browser and sign the victim in to the attacker's account (login CSRF). The issue is fixed in @fastify/oauth2 8.3.2, and users should upgrade to 8.3.2 or later. As a workaround, set an explicit cookie path so the set and the clear name the same cookie.1dCVE-2026-386716.1 MED—
——0Cross Site Scripting vulnerability in Ellucian Banner Student Registration Self-Service (StudentRegistrationSsb) 9.23 and prior (no fixed version available) allows a remote attacker to execute arbitrary code via the mepCode parameter of the /ssb/registration endpoint1dCVE-2026-1122146.5 MED—
——0A flaw was found in the GStreamer ASF demuxer in gst-plugins-ugly. When parsing a Simple Index object, an attacker-controlled entry count is used to size a heap allocation without being limited to the payload available in the object. Processing a crafted ASF, WMV, or WMA file can cause a very large memory allocation request and lead to denial of service if the allocation fails or the process is memory-constrained.1dCVE-2026-1121996.5 MED—
——0Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in YITH YITH WooCommerce Wishlist yith-woocommerce-wishlist allows Stored XSS.This issue affects YITH WooCommerce Wishlist: from n/a through 4.18.1.1dCVE-2026-1121427.3 HIG—
——0A vulnerability was identified in satya-vinay Events-Management-System up to 437c77ceb69bf9fe2e3f4f46f7871b83f425383a. Affected by this vulnerability is an unknown functionality of the file dodelete.php of the component Registration-Delete Handler. Such manipulation of the argument ID leads to sql injection. The attack can be executed remotely. The exploit is publicly available and might be used. This product implements a rolling release for ongoing delivery, which means version information for affected or updated releases is unavailable. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-1121417.3 HIG—
——0A vulnerability was determined in satya-vinay Events-Management-System up to 437c77ceb69bf9fe2e3f4f46f7871b83f425383a. Affected is the function mysqli_query of the file doedit.php of the component Registration-Edit Handler. This manipulation of the argument id/name/title/year/gender/fromdate/todate/people causes sql injection. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-1118455.3 MED—
——0Missing Authorization vulnerability in YITH YITH WooCommerce Product Bundles yith-woocommerce-product-bundles allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects YITH WooCommerce Product Bundles: from n/a through 2.29.0.1dCVE-2026-1118395.3 MED—
——0Missing Authorization vulnerability in VideoWhisper.com Broadcast Live Video videowhisper-live-streaming-integration allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Broadcast Live Video: from n/a through 7.3.7.1dCVE-2026-1118364.3 MED—
——0Missing Authorization vulnerability in WP ManageNinja LLC FluentCommunity fluent-community allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects FluentCommunity: from n/a through 2.11.0.1dCVE-2026-1118315.3 MED—
——0Missing Authorization vulnerability in WP ManageNinja LLC FluentForm fluentform allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects FluentForm: from n/a through 6.2.15.1dCVE-2026-1114146.5 MED—
——0Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Crocoblock JetElements For Elementor jet-elements allows Stored XSS.This issue affects JetElements For Elementor: from n/a through 2.9.2.4.1dCVE-2026-1114106.5 MED—
——0Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in E2Pdf.com e2pdf e2pdf allows Stored XSS.This issue affects e2pdf: from n/a through 1.32.57.1dCVE-2026-1103635.4 MED—
——0Missing Authorization vulnerability in ThimPress LearnPress learnpress allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects LearnPress: from n/a through 4.4.10.1dCVE-2026-1033147.4 HIG—
——0A flaw was found in Red Hat Advanced Cluster Security for Kubernetes (RHACS). The Central SAML authentication ACS endpoint does not retain used SAML assertion or response identifiers to prevent replay. An attacker who obtains a valid, unexpired signed SAML response can submit it multiple times and receive distinct Central authentication tokens for the mapped identity.8hCVE-2026-889008.8 HIG—
——0Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster's multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel's receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster's multicast group or bind port, which with the default UDP multicast transport means a host on an adjacent network, and a usable gadget chain on the classpath, which is why the severity is assessed as high rather than critical.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release.17hCVE-2026-1122106.0 MED—
——0A flaw was found in the rhc-canonical-facts.service systemd unit shipped with rhc. The service runs as root and operates on a file inside a directory owned by an unprivileged system user without verifying that the file is not a symbolic link. A local attacker who has already compromised the privileged yggdrasil system service account can exploit this to gain ownership of arbitrary files, leading to privilege escalation to root.1dCVE-2026-1121406.3 MED—
——0A vulnerability was found in llSourcell Doctor-Dignity up to 3f2ffb6c892f13b50a708d05900d3227acb40ded. This impacts the function _get_lib_module of the file python/mlc_chat/chat_module.py. The manipulation of the argument model_lib results in code injection. The attack may be launched remotely. The exploit has been made public and could be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-1121397.3 HIG—
——0A vulnerability has been found in subhajitkhan online-clinic-management-system up to e9ee77a8827a1446220fa07ee693dc4d9a29a578. This affects an unknown function of the file admindocview.php of the component Administrative Mutation Handler. The manipulation of the argument docid leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. This product uses a rolling release model to deliver continuous updates. As a result, specific version information for affected or updated releases is not available. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-1121384.7 MED—
——0A flaw has been found in diem-project diem up to 5.1.3. The impacted element is the function dmOs::join of the file dmFrontPlugin/modules/dmCodeEditor/actions/actions.class.php of the component dmCodeEditor. Executing a manipulation can lead to path traversal. The attack can be launched remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-1121086.3 MED—
——0A vulnerability was determined in ztxz16 fastllm up to 0.1.8.2. This impacts the function GGUFBuffer::ReadString of the file third_party/gguf/gguf.cpp of the component String Parsing. This manipulation of the argument len causes buffer overflow. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-1121076.3 MED—
——0A flaw has been found in ztxz16 fastllm up to 1.8.2. Affected by this issue is the function SafeTensorItem::CreateBuffer of the file src/model.cpp of the component Safetensors Weight Loading. This manipulation of the argument data_offsets causes buffer overflow. The attack can be initiated remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.1dCVE-2026-918586.5 MED—
——0FopProducer transforms the incoming XSL-FO message body by creating a javax.xml.transform.TransformerFactory through TransformerFactory.newInstance() and enabling only FEATURE_SECURE_PROCESSING before running an identity transform over the body. On the JDK's built-in transformer, that feature alone already empties the accessExternalDTD and accessExternalStylesheet limits, so an external DTD or entity is refused. When a third-party JAXP TransformerFactory such as Saxon-HE is on the classpath, for example because the application also uses camel-xslt-saxon or camel-saxon, TransformerFactory.newInstance() returns that implementation instead, and FEATURE_SECURE_PROCESSING on its own does not restrict external resource access on it. A DOCTYPE with an external subset, or an external general entity, declared in the XSL-FO document is then resolved and expanded while the body is transformed. An external sender whose XSL-FO reaches a fop producer could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. camel-fop does not bring such a factory itself, and excludes Xalan, so a default deployment using the JDK transformer is not affected; the issue is reachable only where another component has placed an alternative JAXP TransformerFactory on the classpath. Releases on the 4.14.x line and earlier reached end of life before this issue was resolved and do not receive a fix.1dCVE-2026-889018.2 HIG—
——0Improper Restriction of XML External Entity Reference vulnerability in Apache Camel.
This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1.
Improper Restriction of XML External Entity Reference in the Smooks component (camel-smooks) in Apache Camel allows an attacker who supplies the XML message body to read local files or issue requests to internal network locations via an external entity declaration in that body. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. The Smooks data format (.unmarshal().smooks(...)) and the Smooks component (smooks:) parse the incoming XML body with the reader Smooks resolves by default, which is the Woodstox SAX parser. That reader resolves external general and parameter entities and loads external DTDs, and camel-smooks applied none of the parser hardening that the other Camel XML components apply. A DOCTYPE with an external subset, or an external general entity, declared in the XML document is therefore resolved and expanded while the body is unmarshalled, and the resolved content is bound into the unmarshalled result and returned on InOut routes. An external sender whose XML reaches a camel-smooks data format or endpoint could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since resolving external entities was the default behaviour. Configurations that declare their own reader - EDI, CSV, JSON, or a custom reader - do not use the XML reader and are not affected. Users are recommended to upgrade to version 4.18.5, 4.22.1 or 4.23.0, which fixes the issue.
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. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders.1dCVE-2026-853174.8 MED—
——0Use of Cache Containing Sensitive Information 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.
The OAuth2 client token cache is global to the JVM, and its key omitted several of the fields that determine what a token actually authorises: the requested scope, the resource indicator, and the token endpoint the token was obtained from. Two endpoints differing only in those fields therefore shared a cache entry, and an endpoint could be served a token minted for a different scope, a different resource, or by a different authorization server. The consequence is a request carrying broader authority than the endpoint was configured for, or a token presented to a party it was not issued for. Reaching it requires a deployment that configures more than one OAuth2 endpoint differing in exactly those fields, which is why the severity is assessed low.
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 cache key now includes every field that shapes the token, so entries are no longer shared between endpoints that differ in any of them. For deployments that cannot upgrade immediately, run endpoints that differ in scope, resource indicator or token endpoint in separate JVMs so that they do not share the cache.1dCVE-2026-853164.8 MED—
——0Insufficient Granularity of Access Control 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 component decided whether an endpoint ran in proxy mode by testing whether its configured path started with the string proxy, rather than by matching the path exactly. Any endpoint whose path merely begins with those characters - proxyStatus, proxy-config, proxying and so on - therefore became a proxy endpoint without the route author asking for it. A proxy endpoint forwards requests onward, so an endpoint that was intended to serve its own content instead relays traffic on behalf of whoever calls it, which is both a request forgery primitive and an exposure of whatever the forwarding path can reach.
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. Proxy mode is now selected by an exact path match rather than by prefix. For deployments that cannot upgrade immediately, rename any endpoint path that begins with proxy but is not intended to be a proxy.1dCVE-2026-853155.3 MED—
——0Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel gRPC component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When a route behind a gRPC consumer failed, the exception's message was placed into the gRPC status description. Unlike the status cause, which stays local to the server, the description is transmitted to the calling client, so an external caller able to provoke a failure could read the internal error message. What that discloses depends on the exception, and in practice includes class and package names, paths, host names and connection detail carried in messages. This is the gRPC member of the same unmuted-consumer-exception family as the knative, mina and CXF advisories published alongside it.
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. A muteException consumer option, defaulting to true, puts a generic description in the status instead of the route exception's message. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, map failures onto an explicit status in an onException handler so the framework never copies the exception message into the description.1dCVE-2026-853146.5 MED—
——0Improper Input Validation vulnerability in Apache Camel Mail component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
CVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path.
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 MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders("mail.smtp*") before any mail producer.1dCVE-2026-853134.3 MED—
——0Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Setting enableCORS on a Jetty endpoint installed Jetty's CrossOriginFilter with its stock defaults, which accept every origin and allow credentials. An operator asking for CORS therefore obtained a policy that lets a page on any origin make credentialed cross-origin requests to the endpoint and read the responses, without any indication that turning the option on had chosen an allow-all policy rather than an empty one to be filled in. This is the same defect class as the platform-http-vertx advisory published alongside it, in a different component.
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. enableCORS no longer grants credentials to an origin the operator did not name. A deployment that relied on any origin being accepted must now list its origins explicitly. For deployments that cannot upgrade immediately, configure the CrossOriginFilter parameters explicitly rather than relying on what enableCORS installs, naming the allowed origins.1dCVE-2026-853124.8 MED—
——0Improper Input Validation vulnerability in Apache Camel Core component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator.
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 header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders("Long-Running-Action") on every consumer that accepts messages from an untrusted sender.1dCVE-2026-853014.8 MED—
——0Improper Authentication vulnerability in Apache Camel Keycloak component.
This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1.
The security processor validated the issuer of an introspected token only when the introspection response actually carried an iss claim. When the claim was absent the check was skipped rather than treated as a failure, so a token that the configured issuer did not mint could be accepted provided the introspection endpoint answered without naming an issuer. Reaching this requires an introspection endpoint that omits iss and accepts tokens from more than one issuer, which is not the default Keycloak arrangement, hence the low severity; where that arrangement exists the consequence is that the deployment authenticates a caller it should have rejected.
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. An absent iss claim is now treated as a validation failure rather than as a reason to skip the check. For deployments that cannot upgrade immediately, ensure the introspection endpoint returns the iss claim, and that it serves exactly one issuer.1dCVE-2026-853005.5 MED—
——0Incorrect Default Permissions 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.
When the component wrote generated key material to disk it did so with the permissions the process default umask produced, rather than restricting the file to its owner. On a host whose umask allows group or world read, the private key was therefore readable by other local accounts. The exposure is to a local party rather than to the remote sender that the Camel threat model treats as the primary adversary, which is why the severity is assessed low, but the consequence where it applies is complete: possession of the private key defeats every signature and key exchange the deployment performs with it.
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. Key material is now written with owner-only permissions. For deployments that cannot upgrade immediately, place the key directory on a path only the service account can traverse, and tighten the process umask. Key material already written with permissive permissions should be treated as exposed and rotated.1dCVE-2026-852966.5 MED—
——0Exposure of Data Element to Wrong Session vulnerability in Apache Camel AS2 component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
Signing material belonging to an individual request was stored in state that is shared across requests rather than confined to the request being processed. Where a deployment serves more than one trading partner, concurrent or successive requests could therefore observe each other's material, and a Message Disposition Notification could be signed with the key of a partner other than the one the receipt was for. The result is cross-partner key confusion: a receipt attributable to the wrong partner, and one partner's signing material used while handling another partner's exchange. AS2 deployments are typically multi-partner by design, so the condition is reached by ordinary concurrent traffic rather than by anything the attacker must arrange.
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. Per-request signing keys are now confined to the request being processed in ResponseMDN. For deployments that cannot upgrade immediately, run a separate Camel context per trading partner so that no signing material is shared between them.1dCVE-2026-852605.5 MED—
——0Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
The camel-mllp component carries a logPhi option that governs whether HL7 payload content may be written to the log. It defaulted to true, so a deployment that did nothing logged protected health information out of the box. Two further paths wrote payload content to the log regardless of the setting, so even an operator who had turned logPhi off was still exposed on those paths. MLLP is used to carry HL7 clinical messages, so the content concerned is patient data, and it reached ordinary application logs where it is subject to whatever retention, aggregation and access the deployment applies to logs generally rather than to clinical records.
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. logPhi now defaults to false and is honoured on the paths that previously ignored it. This is a changed default: a deployment that relied on payload logging must now set logPhi=true explicitly. Because the upgrade guide for a change like this lives on the main branch only, operators upgrading within the 4.18.x or 4.22.x lines should treat this advisory as the notice of that change. For deployments that cannot upgrade immediately, set logPhi=false and be aware that two paths will continue to log payload content until the fix is applied; restrict access to the logs accordingly.1dCVE-2026-852575.3 MED—
——0Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CXF component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1.
When a route behind a CXF SOAP consumer failed with an exception the service contract does not declare, the exception was described back to the SOAP client in the fault: CXF copies the message into the SOAP faultstring, and can be configured to place the stack trace in the fault detail. An external caller able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever the exception message carries. Declared faults, annotated @WebFault, are a different matter: those are part of the published contract that clients are written against, and suppressing them would break the service rather than protect anything.
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. A muteException consumer option, defaulting to true, replaces an undeclared route failure with a generic fault carrying no class name, message or stack trace. Faults the contract declares are reported exactly as before. Set muteException=false to restore the previous output. For deployments that cannot upgrade immediately, declare the exceptions the service is allowed to report and map every other failure onto one of them in an onException handler, so no undeclared exception reaches the fault.1dCVE-2026-852546.5 MED—
——0Improper 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.1dCVE-2026-852517.5 HIG—
——0Exposure 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.1dCVE-2026-852507.5 HIG—
——0Improper 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.1d