Updated 4 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,769exploited flaws on CISA’s list

35added in the last 30 days

356new WordPress flaws this week

394,273entries in the database

394,273 results · page 205 of 7886

Oct 19, 2026Use of Cache Containing Sensitive Information vulnerability in Apache Camel HTTP component.CVE-2026-85317 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.8
Use 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
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Insufficient Granularity of Access Control vulnerability in Apache Camel Platform HTTP component.CVE-2026-85316 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.8
Insufficient 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.
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel gRPC component.CVE-2026-85315 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Generation 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 c
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Input Validation vulnerability in Apache Camel Mail component.CVE-2026-85314 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 6.5
Improper 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
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Jetty component.CVE-2026-85313 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.3
Permissive 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 expl
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Input Validation vulnerability in Apache Camel Core component.CVE-2026-85312 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 4.8
Improper 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-A
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Authentication vulnerability in Apache Camel Keycloak component.CVE-2026-85301 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.8
Improper 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 retu
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Incorrect Default Permissions vulnerability in Apache Camel PQC component.CVE-2026-85300 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.5
Incorrect 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 w
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Exposure of Data Element to Wrong Session vulnerability in Apache Camel AS2 component.CVE-2026-85296 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 6.5
Exposure 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 ResponseMD
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Insertion of Sensitive Information into Log File vulnerability in Apache Camel MLLP component.CVE-2026-85260 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.5
Insertion 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=tr
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CXF component.CVE-2026-85257 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Generation 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 o
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Handling of Case Sensitivity vulnerability in Apache Camel Platform HTTP component.CVE-2026-85254 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 6.5
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 de
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP component.CVE-2026-85251 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.5
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 str
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component.CVE-2026-85250 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.5
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 thro
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Input Validation vulnerability in Apache Camel Tika component.CVE-2026-85249 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 6.5
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
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Camel PQC component.CVE-2026-85248 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.9
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
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Certificate Validation vulnerability in Apache Camel Knative component.CVE-2026-85247 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.9
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 askin
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Mina component.CVE-2026-85246 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Mina component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. When processing of an exchange failed, the Mina consumer wrote exchange.getException() straight back over the socket to the remote peer. Over a textline codec that hands the peer the exception's class name and message; over the object codec it hands over the serialised exception, cause chain included. A remote peer able to provoke a failure could therefore read internal detail about the deployment - class and package names, and whatever a message or nested cause happens to carry, which in practice can include paths, host names and connection detail. The consumer had no option to suppress this, unlike the HTTP-family consumers aligned by CAMEL-23651. 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 the route exception with a generic one carrying no class name, message or stack trace, while stil
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Exposure of Data Element to Wrong Session vulnerability in Apache Camel Thrift component.CVE-2026-85245 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.9
Exposure of Data Element to Wrong Session vulnerability in Apache Camel Thrift component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Thrift data format unmarshalled incoming data into the shared defaultInstance of the target type rather than into a fresh copy, and returned that shared object as the exchange body. Because the instance is shared process-wide, state written while unmarshalling one message stayed on the object and was visible to every later message that used the same type. Fields absent from a later payload retained the previous message's values, so content belonging to one sender could be read while processing another sender's message, and concurrent exchanges could observe each other's partially written state. In a deployment that serves more than one tenant or user through the same route, that is disclosure of one party's data to another. 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. Unmarshalling now deserializes into a copy, so each exchange gets its own instance and no stat
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component.CVE-2026-85243 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.9
Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted. 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 requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerifica
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Authentication vulnerability in Apache Camel Shiro component.CVE-2026-84181 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.9
Improper Authentication vulnerability in Apache Camel Shiro component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Shiro security processor skipped credential verification when the subject already bound to the current thread carried the same principal as the incoming exchange. Because the thread that carries a Camel exchange is drawn from a pool and reused across exchanges, a subject left bound by an earlier authenticated exchange could satisfy the check for a later one that presented no valid credentials of its own. The password on the incoming exchange was, in that case, never verified. The condition depends on thread reuse and on the principal matching, which is why it is not reached on every request, but it requires nothing of the attacker beyond sending a request naming a principal that is in active use. 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 processor now verifies the presented credentials on every exchange rather than accepting a subject already bound to the thread. Setting a
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel Knative component.CVE-2026-84180 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Generation of Error Message Containing Sensitive Information 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 processing of an exchange failed on the consumer side, the Knative HTTP consumer wrote the resulting exception back to the remote caller as the response body, including its class name, message and stack trace. An external sender could therefore provoke a failure and read internal detail about the deployment: class and package names, file system or host names carried in exception messages, and the shape of the route. That detail is useful for building a more targeted attack, and where an exception message embeds configuration or connection strings it is disclosure in its own right. camel-knative was the remaining HTTP-family consumer that had not been aligned with the muteException behaviour established for the other HTTP consumers by CAMEL-23651. 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 consumer now honours a muteException option that
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Cross-Site Request Forgery (CSRF) vulnerability in Apache Camel OAuth component.CVE-2026-84178 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 6.1
Cross-Site Request Forgery (CSRF) 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 authorization code callback did not carry a state parameter binding it to the authorization request that started the flow, and the callback did not verify one. An authorization code obtained in any browser could therefore be redeemed at the callback and associated with whichever session presented it, which is login cross-site request forgery: a victim can be silently signed in as an identity the attacker controls, so that actions the victim then performs, and data they then submit, land in the attacker's account. The same unvalidated callback handling also allowed the post-authentication redirect target to be influenced, giving an open redirect from a trusted origin. The state check runs before the authorization code is redeemed, so these paths are reachable without any interaction with the identity provider. 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 authorizati
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Platform HTTP Vertx component.CVE-2026-84176 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 6.5
Permissive Cross-domain Policy with Untrusted Domains vulnerability in Apache Camel Platform HTTP Vertx component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. createCorsHandler() set Access-Control-Allow-Credentials: true outside the origin check, so the header went out on every response to a request carrying an Origin header, including responses to origins the handler had just decided not to allow. When camel.server.cors.origins is unset, the handler treats every origin as allowed and echoes the caller's own Origin back as Access-Control-Allow-Origin. Together those produce the credentialed any-origin configuration that the fetch specification refuses to express as a literal wildcard, which is precisely why reflecting the origin is the usual way around that rule. A page on any origin could therefore make credentialed cross-origin requests to the Camel endpoint and read the responses. 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. Access-Control-Allow-Credentials is now sent only when the request
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Control of Generation of Code ('Code Injection'), Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression LanCVE-2026-83531 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 8.8
Improper Control of Generation of Code ('Code Injection'), Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') vulnerability in Apache Camel. This issue affects Apache Camel: from 4.4.0 before 4.18.5, from 4.19.0 before 4.22.1. The dynamic-router-control endpoint, introduced in 4.4.0, lets routing participants manage Dynamic Router subscriptions by sending control messages. When it handled a subscribe or update request, DynamicRouterControlProducer took the subscription predicate and the name of the language used to compile it from the incoming message, either from the predicate and expressionLanguage fields of a DynamicRouterControlMessage body or from the CamelDynamicRouterPredicate and CamelDynamicRouterExpressionLanguage headers. DynamicRouterControlService then resolved that language from the CamelContext and compiled the expression into a Predicate, with no allow-list and no opt-in. The compiled predicate was added to the channel's rule base and evaluated against every exchange routed through the corresponding dynamic-router endpoint for as long as the subscription existed. A route that forwards messages
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Server-Side Request Forgery (SSRF) vulnerability in Apache Camel AS2 component.CVE-2026-80344 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.2
Server-Side Request Forgery (SSRF) 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. In the AS2 protocol the sender of a message may request that the Message Disposition Notification be returned asynchronously to an address the sender supplies. camel-as2 took that address from the inbound message and used it as the destination for the outgoing receipt without constraining it to anything the deployment had configured. A remote partner therefore chose the host the Camel instance would connect to when delivering the MDN. That gives server-side request forgery from the position of the AS2 receiver, including reaching hosts that are only routable from inside the deployment's network, and where the outbound connection carries credentials configured for MDN delivery those credentials are presented to the attacker-chosen destination. 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 asynchronous MDN destination is now constrained rather than taken verbatim from the inb
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Handling of Case Sensitivity vulnerability in Apache Camel Netty HTTP component.CVE-2026-80343 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.2
Improper Handling of Case Sensitivity vulnerability in Apache Camel Netty HTTP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The camel-netty-http security constraint compared the request path against the configured context path using a case-sensitive match, while the routing that dispatches the request to the endpoint did not apply the same rule. The two comparisons therefore disagreed for any path whose case differed from the configured value. An external caller could alter the case of a character in a path segment so that the security constraint no longer recognised the path as protected, while the request still dispatched to the same endpoint. The result is that the constraint is skipped and the protected route is reached without satisfying it. No credential, prior access or special configuration is required beyond being able to send a request to the consumer. 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 constraint now matches the request path with the same case rules the disp
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Authentication vulnerability in Apache Camel OAuth component.CVE-2026-80312 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 8.2
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
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Azure Files component.CVE-2026-79986 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.4
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Azure Files component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server's directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel SMB component.CVE-2026-79985 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.4
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel SMB component. This issue affects Apache Camel: from 4.2.0 before 4.18.5, from 4.19.0 before 4.22.1. The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server's directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a singl
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Mina SFTP component.CVE-2026-79984 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.4
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Mina SFTP component. This issue affects Apache Camel: from 4.18.0 before 4.18.5, from 4.19.0 before 4.22.1. The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server's directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel FTP component.CVE-2026-79983 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.4
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel FTP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Camel remote-file consumers poll a directory on a remote server and build the absolute remote path of each file by concatenating the configured directory with the file name reported in the server's directory listing. That concatenation (FtpUtils.absoluteFilePath and GenericFileConsumer) applied no lexical normalization and no check that the result stayed inside the directory being polled, and the resulting path became the operand for every subsequent remote operation on the file: retrieval (FtpOperations.retrieveFile / SftpOperations, reached from GenericFileConsumer where the retrieve name is taken verbatim from GenericFile.getAbsoluteFilePath), deletion when delete=true (GenericFileDeleteProcessStrategy), and renaming when move, preMove, moveFailed or readLock=rename is configured (GenericFileProcessStrategySupport and GenericFileRenameExclusiveReadLockStrategy). Neither isValidFile nor isMatched performed any containment check. A listing entry that is not a singl
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Deserialization of Untrusted Data vulnerability in Apache Camel Spring Redis component.CVE-2026-78165 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 8.8
Deserialization of Untrusted Data vulnerability in Apache Camel Spring Redis component. This issue affects Apache Camel: from 2.11.0 before 4.18.5, from 4.19.0 before 4.22.1. RedisConfiguration.getSerializer lazily built a bare JdkSerializationRedisSerializer whenever no serializer option was configured, and that instance was used for every read the component performs. Spring's implementation delegates through DeserializingConverter to DefaultDeserializer, which reads the bytes with a ConfigurableObjectInputStream and installs no java.io.ObjectInputFilter on the stream, so an arbitrary serialized class graph was materialised and its readObject method executed. RedisConsumer.setBody applied that serializer to the raw bytes of every message published to the subscribed channels, before the Exchange was constructed and therefore before any route logic could inspect the message, so an actor able to issue PUBLISH on a subscribed channel reached the deserialization sink directly. The same default serializer backed the RedisTemplate built by RedisConfiguration.createDefaultTemplate, so the producer read commands GET, HGET, HGETALL and HVALS deserialized whatever was stored in the Red
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Improper Neutralization of Special Elements Used in a Template Engine and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache CamCVE-2026-78164 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 8.2
Improper Neutralization of Special Elements Used in a Template Engine and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel HTTP, Netty HTTP, Undertow and Vert.x HTTP components. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Camel HTTP producer families let an inbound message override the endpoint URI through the CamelHttpUri and CamelRestHttpUri headers, and then passed that message-supplied string through CamelContext.resolvePropertyPlaceholders() before using it. Property-placeholder resolution is a configuration-resolution facility, not a URI-parsing step: it reaches operating-system environment variables, JVM system properties, every PropertiesFunction registered on the classpath - including the secret functions - and, through camel-bean, the invocation of a no-argument method on any bean in the registry. Applying it to Exchange content therefore turned a URI string into a configuration- and bean-evaluation context. A route author opted into none of this: a plain static to("http://backend/api") was sufficient. Seven call sites were affected: HttpHelper.createURL and HttpHelper.createMethod
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Server-Side Request Forgery (SSRF), Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') and Exposure of Sensitive Information to an UCVE-2026-78163 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.9
Server-Side Request Forgery (SSRF), Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1. DoclingProducer decided what a String message body meant by inspecting its prefix. A body starting with http:// or https:// was handed to Docling as a remote URL to fetch, a body starting with / or containing a backslash was read from the local filesystem, and anything else was written to a temporary file and converted as document content. The mode was chosen implicitly and no endpoint option allowed a route author to pin the component to a single interpretation, so a route that means convert whatever text arrives in the body silently became a fetcher of remote resources or a reader of local files whenever the text happened to begin with one of those prefixes. The only guard applied to the derived value was a size check, and that check was wrapped in an existence test, so a path that resolved to nothing, or to a pseudo-file reporting a size of zero, passed without bei
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org github.com
Oct 19, 2026Deserialization of Untrusted Data vulnerability in Apache Camel.CVE-2026-78162 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 10
Deserialization of Untrusted Data vulnerability in Apache Camel. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The camel-hazelcast component applies a default Hazelcast JavaSerializationFilterConfig to the instances it creates from its own configuration, a protection introduced by CVE-2026-43865. That change did not reach two of the configuration paths Camel builds itself, so those paths continued to create Hazelcast instances whose Java deserialization is unrestricted. ReplicatedHazelcastAggregationRepository extends HazelcastAggregationRepository but overrides doStart() without calling super.doStart(), keeping its own copy of the bootstrap block, and therefore never received the filter: a route using it without supplying a hazelcastInstance starts a Hazelcast member that deserializes values read from the backing ReplicatedMap with no class restriction. HazelcastDefaultComponent#getOrCreateHzClientInstance() builds its own ClientConfig when hazelcastMode=client is selected and neither a referenced ClientConfig nor hazelcastConfigUri is supplied, and likewise applied no filter, so client-mode endpoints behaved differently from node-mode
Product
Apache Camel
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record camel.apache.org camel.apache.org
Oct 19, 2026Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Apache Johnzon.CVE-2026-71253 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Apache Johnzon. ClassConverter loads & static-initializes an attacker-named class from untrusted JSON. This issue affects Apache Johnzon: from 1.0.0 before 2.2.0. Users are recommended to upgrade to version 1.3.1 (javax namespace) or 2.2.0 (jakarta specification namespace), which fixes the issue.
Product
Apache Johnzon
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 19, 2026A security vulnerability has been detected in TufayelLUS TikTok-Video-Downloader-PHP up to c4230497bb23dd9c1f81456fe8a982d951feac0d.CVE-2026-112106 · Other software · TufayelLUS · reported by VulDBMedium 6.3
A security vulnerability has been detected in TufayelLUS TikTok-Video-Downloader-PHP up to c4230497bb23dd9c1f81456fe8a982d951feac0d. Affected by this issue is some unknown functionality of the file index.php of the component TLS Handler. Such manipulation leads to improper certificate validation. It is possible to launch the attack remotely. The attack requires a high level of complexity. The exploitation is known to be difficult. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The name of the patch is 64c0155abb88e714198241d41b918cefc0d5a42a. It is advisable to implement a patch to correct this issue.
Product
TikTok-Video-Downloader-PHP
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 19, 2026A vulnerability has been found in GlitterWare Passy up to 1.10.1.CVE-2026-112105 · Other software · GlitterWare · reported by VulDBMedium 6.3
A vulnerability has been found in GlitterWare Passy up to 1.10.1. The affected element is the function MyHttpOverrides in the library lib/main.dart of the component TLS Handler. Such manipulation leads to improper certificate validation. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is described as difficult. Upgrading to version 1.10.2 is sufficient to fix this issue. The name of the patch is 3d48df7cce05e39fa4de1e42768492307f26882e. The affected component should be upgraded.
Product
Passy
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 19, 2026A flaw has been found in eremef bandcamp-player up to 1.8.33-beta.CVE-2026-112104 · Other software · eremef · reported by VulDBMedium 6.9
A flaw has been found in eremef bandcamp-player up to 1.8.33-beta. The impacted element is an unknown function of the file database.ts of the component Remote Control Server. Executing a manipulation of the argument remoteEnabled can lead to missing authentication. The attack may be launched remotely. Upgrading to version 1.8.34-beta is sufficient to resolve this issue. This patch is called ccba99b66bc61acf46e4a332034799d7452ddea6. Upgrading the affected component is advised.
Product
bandcamp-player
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 19, 2026A vulnerability has been found in f3-factory fatfree-core up to 3.9.2.CVE-2026-112103 · Other software · f3-factory · reported by VulDBMedium 6.3
A vulnerability has been found in f3-factory fatfree-core up to 3.9.2. This vulnerability affects the function _curl of the file web.php of the component HTTP Client. Such manipulation leads to improper certificate validation. The attack may be performed from remote. Attacks of this nature are highly complex. It is stated that the exploitability is difficult. Upgrading to version 3.9.3 is able to resolve this issue. The name of the patch is a2c755c8dc9ad0eb7d5fd261b09aff90f649433c. You should upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.
Product
fatfree-core
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 19, 2026Missing authentication for critical function vulnerability in Apache Answer.CVE-2026-90910 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Missing authentication for critical function vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. The reaction API did not enforce content visibility controls, allowing unauthorized users to read reaction metadata from restricted content or add and remove their own reactions. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026Incorrect implementation of authentication algorithm vulnerability in Apache Answer.CVE-2026-86589 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.4
Incorrect implementation of authentication algorithm vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. A flaw in the User Center login integration can cause a newly created external user session to omit its external identity, allowing subsequent requests to bypass central account suspension or deletion checks until the session expires or is revoked. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026vulnerability in Apache Answer.CVE-2026-79633 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.1
vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Missing authorization checks allowed authenticated users to perform actions on non-public content they were not permitted to access. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026Insufficient session expiration vulnerability in Apache Answer.CVE-2026-79624 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Insufficient session expiration vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Insufficient session invalidation allowed revoked users to continue accessing known private uploaded files with a stale visit token. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026Exposure of sensitive information through data queries vulnerability in Apache Answer.CVE-2026-79620 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.3
Exposure of sensitive information through data queries vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. An improper authorization check in the similar-question search allowed authenticated users to view metadata of non-public questions. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026vulnerability in Apache Answer.CVE-2026-79613 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.3
vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Unauthenticated attackers could access comments associated with non-public content through public user profiles. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Answer.CVE-2026-76994 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.5
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Unauthenticated attackers could obtain metadata associated with hidden questions through public answer profiles. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026Missing Authorization vulnerability in Apache Answer.CVE-2026-71563 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.3
Missing Authorization vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. An authorization flaw in the MCP answer retrieval tool allows holders of a global API key to access answer content associated with hidden, deleted, or pending-review questions. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com
Oct 19, 2026Missing Authorization vulnerability in Apache Answer.CVE-2026-68482 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Missing Authorization vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. An unauthenticated or unauthorized user can retrieve the invited-user list associated with a non-public question due to missing visibility authorization checks. Users are recommended to upgrade to version 2.0.3, which fixes the issue.
Product
Apache Answer
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record lists.apache.org openwall.com

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Vulnerability database

The flaws that hit local websites, every Friday.

Tell us what you're building.