Updated 27 min 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,764exploited flaws on CISA’s list

36added in the last 30 days

479new WordPress flaws this week

390,525entries in the database

174 results · page 3 of 4

Jul 6, 2026Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel DNS component.CVE-2026-48205 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.1
Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel DNS component. The camel-dns producers read DNS operation parameters - the resolver to query, the name or domain to look up, the record type and class, and the search term - from Exchange message headers whose constant values (DnsConstants.DNS_SERVER, DNS_NAME, DNS_DOMAIN, DNS_TYPE, DNS_CLASS, TERM) were the plain strings dns.server, dns.name, dns.domain, dns.type, dns.class and term. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a dns: producer, any HTTP client could therefore set the dns.server header to make the dig producer build a SimpleResolver pointing at an attacker-controlled DNS server - a server-side request forgery via DNS, through which the attacker observes the queried name and can return poisoned responses - and set the dns.name / dns.domain headers to resolve arbitrary internal hostnames, disclosing whether they exist (in
Product
Apache Camel DNS
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 openwall.com
Jul 6, 2026Improper Input Validation, Improper Access Control vulnerability in Apache Camel in Camel Mongodb Gridfs component.CVE-2026-48204 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Improper Input Validation, Improper Access Control vulnerability in Apache Camel in Camel Mongodb Gridfs component. The camel-mongodb-gridfs producer selects the GridFS operation to perform from the gridfs.operation Exchange header when the endpoint's operation parameter is not set - which is the default. The control-header constants (GridFsConstants.GRIDFS_OPERATION, GRIDFS_OBJECT_ID, GRIDFS_METADATA, GRIDFS_CHUNKSIZE, GRIDFS_FILE_ID_PRODUCED) were the plain strings gridfs.operation, gridfs.objectid, gridfs.metadata, gridfs.chunksize and gridfs.fileid. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a mongodb-gridfs: producer with no explicit operation, any HTTP client could therefore set the gridfs.operation header to override the route's intended operation - switching, for example, a file upload to remove (deleting a file identified by the attacker-supplied gridfs.objectid), listAll (enumerating every file in the bucket) or fi
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 openwall.com
Jul 6, 2026Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Improper Input Validation, Server-Side Request Forgery (SSRFCVE-2026-48203 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.1
Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component. The camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam.* headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud met
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 openwall.com
Jul 6, 2026Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in VertxCVE-2026-46726 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 7.5
Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Vertx Websocket component. The camel-vertx-websocket consumer mapped inbound WebSocket query and path parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (VertxWebsocketConsumer.populateExchangeHeaders()). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to th
Product
Apache Camel Vertx Websocket
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 openwall.com
Jul 6, 2026Improper Input Validation, Unintended Proxy or Intermediary ('Confused Deputy') vulnerability in Apache Camel CXF SOAP component.CVE-2026-46592 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 7.5
Improper Input Validation, Unintended Proxy or Intermediary ('Confused Deputy') vulnerability in Apache Camel CXF SOAP component. The camel-cxf producer selects which SOAP operation to invoke on the backend service from the operationName (and operationNamespace) Exchange header, whose constant values (CxfConstants.OPERATION_NAME / OPERATION_NAMESPACE) were the plain strings operationName / operationNamespace. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a cxf: producer, any HTTP client could therefore set the operationName header and have CxfProducer resolve and invoke a different WSDL operation than the route intended - for example replacing a read operation with a destructive one - against the backend SOAP service (a confused-deputy redirection). The constant is defined in the shared camel-cxf-common module, so the same non-prefixed names also applied to camel-cxfrs. No credentials are required when the bridging consumer is
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 openwall.com
Jul 6, 2026Improper Neutralization of Special Elements in Data Query Logic vulnerability in Apache Camel Neo4J component.CVE-2026-46591 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.2
Improper Neutralization of Special Elements in Data Query Logic vulnerability in Apache Camel Neo4J component. The camel-neo4j producer builds the Cypher WHERE clause for its match/retrieve and delete operations from the CamelNeo4jMatchProperties map. CVE-2025-66169 addressed Cypher injection through the property values by binding them as query parameters ($paramN), but the property names (the JSON keys of that map) were still concatenated into the query string verbatim in Neo4jProducer.retrieveNodes() and deleteNode(). A property name containing Cypher syntax therefore alters the structure of the executed query. Where a route maps untrusted input into the CamelNeo4jMatchProperties map - for example by passing a request body as the match map, or from a consumer that does not filter inbound Camel* headers - an attacker who controls the JSON key names can inject arbitrary Cypher and read, modify or delete any node or relationship in the Neo4j database. The CamelNeo4jMatchProperties header is itself Camel-prefixed and is filtered by the HTTP header-filter strategy, so a plain HTTP client cannot set it directly; the issue is reachable through routes that deliberately or inadvertently
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
Jul 6, 2026Deserialization of Untrusted Data vulnerability in Apache Camel PQC component.CVE-2026-46590 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.8
Deserialization of Untrusted Data vulnerability in Apache Camel PQC component. The camel-pqc component persists post-quantum key metadata (KeyMetadata) through pluggable KeyLifecycleManager implementations. HashicorpVaultKeyLifecycleManager and AwsSecretsManagerKeyLifecycleManager read that metadata back from the configured secret backend by deserializing a Base64-wrapped value with a raw java.io.ObjectInputStream.readObject() and no ObjectInputFilter or class allow-list; the cast to KeyMetadata happens only after readObject() returns, so any readObject() side effects in a crafted object run before the type check. The same unfiltered legacy-migration read also remained in FileBasedKeyLifecycleManager (for the stored KeyPair and KeyMetadata). A principal who can write to the operator-controlled backend that holds these values - the HashiCorp Vault KV path, or the AWS Secrets Manager secret (requiring a Vault token or secretsmanager:PutSecretValue) - could store a crafted serialized object that is deserialized during normal key-lifecycle operations, potentially leading to code execution in the context of the application that manages the keys. This is an incomplete-remediation follow
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
Jul 6, 2026Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Lucene Component.CVE-2026-46585 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 7.5
Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel Lucene Component. The camel-lucene producer reads the search phrase from an Exchange header (LuceneConstants.HEADER_QUERY) whose value was the plain string QUERY (and RETURN_LUCENE_DOCS for HEADER_RETURN_LUCENE_DOCS). Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that exposes a Lucene query operation behind an HTTP consumer (for example platform-http), any HTTP client could therefore set the QUERY header and have its value executed against the full-text index, overriding the query the route intended to run. Depending on what is indexed, this allows reading documents the request should not have access to (for example a match-all query returns the entire index, or the route's intended per-user filter can be replaced), and expensive regular-expression queries can consume significant CPU. No credentials are required when the HTTP consumer is unauthenticated. This issue affects Apache Camel
Product
Apache Camel Lucene
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 openwall.com
Jul 6, 2026Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel Mail Component.CVE-2026-46584 · Email & office · Apache Software Foundation · reported by security@apache.orgLow 3.7
Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel Mail Component. The camel-mail producer (MailProducer.getSender) scanned the outgoing Exchange for message headers in the mail.smtp. / mail.smtps. namespace and, when any were present, built a per-message JavaMail sender with those values applied as JavaMail session properties, overriding the endpoint configuration. This namespace is Camel-internal - only MailProducer interprets it - and was not blocked by any HeaderFilterStrategy, so the values could originate from any inbound protocol (for example platform-http query parameters or request headers, or JMS / Kafka messages from untrusted producers) that feeds a route ending in an smtp / smtps producer without an intervening removeHeaders. The maximal impact is version-dependent: on releases before 4.19.0, setting mail.smtp.host redirects the SMTP connection to a server under the attacker's control, and because the producer then authenticates with the endpoint's configured username and password those credentials are transmitted to the attacker; on 4.19.0 and later the producer connects to the endpoint's configured hos
Product
Apache Camel Mail
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 openwall.com
Jul 6, 2026Improper Input Validation vulnerability in Apache Camel NATS component.CVE-2026-46457 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 7.5
Improper Input Validation vulnerability in Apache Camel NATS component. The camel-nats component maps inbound NATS message headers into the Camel Exchange but defaulted its headerFilterStrategy to a bare new DefaultHeaderFilterStrategy() with no inbound rules configured (NatsConfiguration). With no inFilter, inFilterPattern or inFilterStartsWith set, DefaultHeaderFilterStrategy.applyFilterToExternalHeaders returns not filtered for every header name, so NatsConsumer copies every NATS message header - including Camel-internal control headers such as CamelHttpUri, CamelFileName or CamelSqlQuery - unmodified onto the Camel message. A client able to publish to the consumed NATS subject can therefore inject arbitrary Camel control headers that influence the behaviour of downstream producers in the route (for example redirecting an HTTP producer, changing a file name, or overriding a query); the injected headers also persist across internal direct, seda and vm hops. The concrete downstream impact depends on which producers the route uses. NATS message headers require NATS 2.2 or later, and the issue is reachable without credentials when the NATS server is configured without authenticatio
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 openwall.com
Jul 6, 2026Improper Input Validation vulnerability in Apache Camel AWS2-SQS Component.CVE-2026-46456 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Improper Input Validation vulnerability in Apache Camel AWS2-SQS Component. The camel-aws2-sqs component map inbound message attributes into the Camel Exchange through a component-specific HeaderFilterStrategy. Sqs2HeaderFilterStrategy configured only an outbound filter (setOutFilterPattern, which blocks Camel*, breadcrumbId and org.apache.camel.* headers being written to the broker) but did not configure an inbound filter. As a result, when Sqs2Consumer copies each SQS MessageAttribute into the Exchange via HeaderFilterStrategy.applyFilterToExternalHeaders, DefaultHeaderFilterStrategy applied no inbound rule and treated every header name as not filtered - including Camel-internal control headers such as CamelHttpUri, CamelFileName or CamelSqlQuery - copying them unmodified onto the Camel message. Any principal able to send messages to the consumed SQS queue (for example a cross-account sender or a lower-privileged in-account component holding sqs:SendMessage) could therefore set arbitrary Camel control headers that influence the behaviour of downstream producers in the route (for example redirecting an HTTP producer, changing a file name, or overriding a query); the injected hea
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 openwall.com
Jul 6, 2026Insufficient Session Expiration vulnerability in Apache Camel Keycloak Component.CVE-2026-46455 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Insufficient Session Expiration vulnerability in Apache Camel Keycloak Component. The camel-keycloak security helper KeycloakSecurityHelper.parseAndVerifyAccessToken builds a Keycloak TokenVerifier using withChecks(...) with only the subject-exists check and the realm-URL (issuer) check. Keycloak's TokenVerifier.withChecks(...) appends to an initially empty check list - the upstream default checks are installed only when withDefaultChecks() is called - so the built-in IS_ACTIVE predicate, which validates the token's exp (expiration) and nbf (not-before) claims, is never applied. As a result the helper verifies the token signature, subject and issuer but does not enforce the token's validity window: an access token that is expired, or not yet valid, is accepted as valid. Routes that rely on this helper to authenticate inbound requests therefore accept access tokens that are outside their intended lifetime. This issue affects Apache Camel: from 4.18.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes KeycloakSecur
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 openwall.com
Jul 6, 2026Improper Input Validation vulnerability in Apache Camel Cometd Component.CVE-2026-46454 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Improper Input Validation vulnerability in Apache Camel Cometd Component. The camel-cometd component maps inbound Bayeux (CometD) message headers into the Camel Exchange without applying a HeaderFilterStrategy. CometdBinding.populateExchangeFromMessage copies the entire ext.CamelHeaders map supplied by the CometD client directly onto the Camel message (message.setHeaders), so any header name - including Camel-internal control headers such as CamelHttpUri, CamelFileName or CamelJmsDestinationName - is accepted unmodified. Because a CometdComponent installs no Bayeux SecurityPolicy by default, any client that can complete the Bayeux handshake against the CometD endpoint can publish such a message without authentication. An attacker can therefore inject arbitrary Camel control headers that influence the behaviour of downstream producers in the route (for example redirecting an HTTP producer, changing a file name, or overriding a JMS destination); the injected headers also persist across internal direct, seda and vm hops. The concrete downstream impact depends on which producers the route uses. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from
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 openwall.com
Jul 6, 2026Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client.CVE-2026-46453 · Email & office · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client. The camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') rather than the 'Camel'-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel's inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with 'Camel' or 'camel'. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading e
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 openwall.com
Jul 6, 2026Deserialization of Untrusted Data vulnerability in Apache Camel PQC Component.CVE-2026-43867 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Deserialization of Untrusted Data vulnerability in Apache Camel PQC Component. The camel-pqc component persists post-quantum key metadata (KeyMetadata) through pluggable KeyLifecycleManager implementations. AwsSecretsManagerKeyLifecycleManager.deserializeMetadata() reads that metadata back from the configured AWS Secrets Manager secret by Base64-decoding the stored value and deserializing it with a raw java.io.ObjectInputStream.readObject() and no ObjectInputFilter or class allow-list; the cast to KeyMetadata happens only after readObject() returns, so any readObject() side effects in a crafted object run before the type check. A principal who can write to the AWS Secrets Manager secret that holds this metadata (requiring secretsmanager:PutSecretValue on that secret) could store a crafted serialized object that is deserialized during normal key-lifecycle operations, potentially leading to code execution in the context of the application that manages the keys. This is the same underlying defect, in the same code path and remediated by the same fix, as CVE-2026-46590, which was reported independently and additionally covers the HashiCorp Vault and file-based sibling managers; both 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
Jul 6, 2026Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component.CVE-2026-43866 · Email & office · Apache Software Foundation · reported by security@apache.orgHigh 7.3
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component. JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms.ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support.DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. An
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
Jul 6, 2026Deserialization of Untrusted Data vulnerability in Apache Camel Hazelcast component.CVE-2026-43865 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.1
Deserialization of Untrusted Data vulnerability in Apache Camel Hazelcast component. The camel-hazelcast component creates and manages Hazelcast instances using a default configuration that applies no Java deserialization filter. When Camel builds the Hazelcast Config itself - that is, when no user-supplied HazelcastInstance, hazelcastConfigUri, or referenced Config bean is provided - neither Hazelcast's JavaSerializationFilterConfig nor a Camel-side ObjectInputFilter is configured, so objects received over the Hazelcast cluster protocol are deserialized inside Hazelcast's own serialization layer (ObjectInputStream.readObject) before Camel ever processes them. An attacker who can join or otherwise reach the Hazelcast cluster can publish a crafted serialized Java object that is then deserialized on every Camel node, resulting in remote code execution. The exposure is present by default and requires no opt-in endpoint configuration: any route using a hazelcast consumer (hazelcast-topic, hazelcast-queue, hazelcast-seda, hazelcast-map, hazelcast-multimap, hazelcast-replicatedmap, hazelcast-list, hazelcast-set), as well as the HazelcastAggregationRepository and HazelcastIdempotentRepos
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 openwall.com
Jul 6, 2026Deserialization of Untrusted Data vulnerability in Apache Camel.CVE-2026-42527 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.1
Deserialization of Untrusted Data vulnerability in Apache Camel. The default ObjectInputFilter pattern shipped with several Apache Camel components for defense-in-depth deserialization filtering ('java.**;javax.**;org.apache.camel.**;!*', or the no-'javax.**' variant in the aggregation-repository components) uses a recursive 'java.**' glob that admits classes whose hashCode/equals/readObject methods perform network I/O, notably java.net.URL and java.net.InetAddress. When an attacker can deliver a Java-serialized payload to an affected Camel consumer, deserialization of a HashMap (or any collection that calls hashCode on its elements) containing java.net.URL keys causes the JVM to issue DNS queries to the attacker-supplied host during the deserialization side-effect. The class-level filter check passes because the resulting object's class (HashMap) is allow-listed; the DNS query is observable on an attacker-controlled DNS server, providing an out-of-band side channel. The exposure is highest on the camel-jms family because JmsBinding.extractBodyFromJms invokes ObjectMessage.getObject() unconditionally when mapJmsMessage=true (default). Affected components: camel-jms, camel-sjms, ca
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 openwall.com
Jul 6, 2026Deserialization of Untrusted Data vulnerability in Apache Camel.CVE-2026-40859 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.1
Deserialization of Untrusted Data vulnerability in Apache Camel. The camel-vertx-http component deserializes HTTP response bodies carrying the Content-Type application/x-java-serialized-object using a raw java.io.ObjectInputStream, without applying any ObjectInputFilter (VertxHttpHelper.deserializeJavaObjectFromStream) This deserialization path is reached only when the producer endpoint is configured with transferException=true (or the component-level allowJavaSerializedObject=true) and throwExceptionOnFailure is left at its default value of true; in that case a backend HTTP response with a 5xx status and the application/x-java-serialized-object content type has its body deserialized with no class restrictions. An attacker who controls the backend the Camel producer talks to - through a man-in-the-middle position on an unencrypted (plain HTTP) connection, or by compromising the backend service - can return a crafted serialized Java object and, if a suitable gadget chain is present on the classpath, achieve remote code execution on the Camel application host. The path is not reachable in the default configuration, where transferException is false. This issue affects Apache Camel: f
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 openwall.com
Jul 6, 2026Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache Camel Docling component.CVE-2026-40047 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.1
Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability in Apache Camel Docling component. The camel-docling component invokes the external `docling` command-line tool by assembling an argument list in DoclingProducer and executing it through java.lang.ProcessBuilder. Custom CLI arguments supplied through the `CamelDoclingCustomArguments` exchange header (a List<String>) were appended to that argument list with insufficient validation: the original implementation relied on a denylist of disallowed flags and only rejected path values that contained a literal `../` sequence. As a result, a Camel route that forwards externally-influenced data into the `CamelDoclingCustomArguments` header (or into the path-bearing headers used to build the invocation) could cause the producer to pass unrecognized or unintended `docling` CLI flags to the subprocess, and could supply path-like argument values that resolved outside the intended directory through traversal sequences not caught by the literal `../` check. Because Camel itself builds the `docling` invocation from these values, the component is responsible for constraining them, and the weak validatio
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 openwall.com
May 21, 2026(Externally Controlled Reference to a Resource in Another Sphere), (Authorization Bypass Through User-Controlled Key) vulnerability in Apache Camel K.CVE-2026-45760 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.1
(Externally Controlled Reference to a Resource in Another Sphere), (Authorization Bypass Through User-Controlled Key) vulnerability in Apache Camel K. Authorized users in a Kubernetes namespace can create a Build resource, controlling the Pod generation in a namespace of their choice, including the operator namespace. This issue affects Apache Camel K: from 2.0.0 before 2.8.1, from 2.9.0 before 2.9.2, from 2.10.0 before 2.10.1. Users are recommended to upgrade to version 2.10.1 (or 2.8.1 or 2.9.2), which fixes the issue.
Product
Apache Camel K
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 openwall.com
May 19, 2026Camel-CXF and Camel-Knative Message Header Injection via Missing Inbound Filtering The CXF and Knative HeaderFilterStrategy implementations (CxfRsHeaderFilterSCVE-2026-47323 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
Camel-CXF and Camel-Knative Message Header Injection via Missing Inbound Filtering The CXF and Knative HeaderFilterStrategy implementations (CxfRsHeaderFilterStrategy in camel-cxf-rest, CxfHeaderFilterStrategy in camel-cxf-transport, and KnativeHttpHeaderFilterStrategy in camel-knative-http) only filter outbound Camel-internal headers via setOutFilterStartsWith, while not configuring inbound filtering via setInFilterStartsWith. As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelExecCommandExecutable, CamelFileName) via HTTP requests to CXF-RS or CXF-SOAP endpoints. When a route forwards messages from these endpoints to header-driven components such as camel-exec or camel-file, the injected headers override configured values, enabling remote code execution or arbitrary file writes. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and non-HTTP strategies (CVE-2026-40453). This issue affects Apache Camel: from 3.18.0 before 4.14.6, from 4.15.0 before 4.18.2. Users are recommended to upgrade to version 4.19.0, which fixes the issue. If
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 access.redhat.com
Apr 27, 2026Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Apache Camel Camel-Coap component.CVE-2026-33453 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 10
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Apache Camel Camel-Coap component. Apache Camel's camel-coap component is vulnerable to Camel message header injection, leading to remote code execution when routes forward CoAP requests to header-sensitive producers (e.g. camel-exec) The camel-coap component maps incoming CoAP request URI query parameters directly into Camel Exchange In message headers without applying any HeaderFilterStrategy. Specifically, CamelCoapResource.handleRequest() iterates over OptionSet.getUriQuery() and calls camelExchange.getIn().setHeader(...) for every query parameter. CoAPEndpoint extends DefaultEndpoint rather than DefaultHeaderFilterStrategyEndpoint, and CoAPComponent does not implement HeaderFilterStrategyComponent; the component contains no references to HeaderFilterStrategy at all. As a result, an unauthenticated attacker who can send a single CoAP UDP packet to a Camel route consuming from coap:// can inject arbitrary Camel internal headers (those prefixed with Camel*) into the Exchange. When the route delivers the message to a header-sensitive producer such as camel-exec, camel-sql, camel-
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 openwall.com
Apr 27, 2026The ConsulRegistry in the camel-consul component (class org.apache.camel.component.consul.ConsulRegistry and its inner ConsulRegistryUtils.deserialize method) rCVE-2026-27172 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.8
The ConsulRegistry in the camel-consul component (class org.apache.camel.component.consul.ConsulRegistry and its inner ConsulRegistryUtils.deserialize method) read Java-serialized values from the Consul KV store and passed them to ObjectInputStream.readObject() without configuring an ObjectInputFilter. An attacker who can write to the Consul KV store backing a Camel ConsulRegistry instance could inject a malicious serialized Java object that is deserialized the next time Camel performs a lookup against that registry, leading to arbitrary code execution in the Camel process. The issue mirrors the class of vulnerability already addressed for other Camel components in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747, and was overlooked during the original remediation of those CVEs. This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1. Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.1.
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 access.redhat.com
Apr 27, 2026The camel-infinispan component's ProtoStream-based remote aggregation repository deserializes data read from a remote Infinispan cache using java.io.ObjectInputCVE-2026-40858 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.8
The camel-infinispan component's ProtoStream-based remote aggregation repository deserializes data read from a remote Infinispan cache using java.io.ObjectInputStream without applying any ObjectInputFilter. An attacker who can write to the Infinispan cache used by a Camel application can inject a crafted serialized Java object that, when read during normal aggregation repository operations such as get or recover, results in arbitrary code execution in the context of the application. This issue affects Apache Camel: from 4.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2. The JIRA ticket: https://issues.apache.org/jira/browse/CAMEL-23322 refers to the various commits that resolved the issue, and have more details. This issue follows the same class of vulnerability previously addressed in CVE-2024-22369, CVE-2024-23114 and CVE-2026-25747.
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 access.redhat.com
Apr 27, 2026When authentication is enabled on the Apache Camel embedded HTTP server or embedded management server (camel-platform-http-main) and a non-root context path sucCVE-2026-40022 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.2
When authentication is enabled on the Apache Camel embedded HTTP server or embedded management server (camel-platform-http-main) and a non-root context path such as /api or /admin is configured via camel.server.path or camel.management.path, the BasicAuthenticationConfigurer and JWTAuthenticationConfigurer classes derive the authentication path from properties.getPath() when camel.server.authenticationPath / camel.management.authenticationPath is not explicitly set. Combined with the Vert.x sub-router mounting model - the sub-router is mounted at _path_* and the authentication handler is registered inside the sub-router at the resolved path - this causes the authentication handler to match only the exact configured context path, not its subpaths. Unauthenticated requests to subpaths such as /api/_route_ or /admin/observe/info therefore reach protected business routes and management endpoints without being challenged for credentials. The /observe/info endpoint can disclose runtime metadata such as the user, working directory, home directory, process ID, JVM and operating system information. This issue affects Apache Camel: from 4.14.1 before 4.14.6, from 4.18.0 before 4.18.2. User
Product
Apache Camel Platform HTTP Main
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 openwall.com
Apr 27, 2026The Camel-Mail component is vulnerable to Camel message header injection.CVE-2026-33454 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.4
The Camel-Mail component is vulnerable to Camel message header injection. The custom header filter strategy used by the component (MailHeaderFilterStrategy) only filters the 'out' direction via setOutFilterStartsWith, while it does not configure the 'in' direction via setInFilterStartsWith. As a result, when a Camel application consumes mail through camel-mail (for example via from(\"imap://...\") or from(\"pop3://...\")) the inbound filter check is skipped and Camel-prefixed MIME headers are mapped unfiltered into the Exchange. An attacker who can deliver an email to a mailbox monitored by such a consumer can inject Camel-specific headers that, for some Camel components downstream of the mail consumer (such as camel-bean, camel-exec, or camel-sql), can alter the behaviour of the route. This is the same pattern that was previously addressed in camel-undertow (CVE-2025-30177) and the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891). This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.1. Users are recommended to upgrade to version 4.19.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested t
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 access.redhat.com
Apr 27, 2026JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values vCVE-2026-40860 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.8
JmsBinding.extractBodyFromJms() in camel-jms, and the equivalent JmsBinding class in camel-sjms, deserialized the payload of incoming JMS ObjectMessage values via javax.jms.ObjectMessage.getObject() without applying any ObjectInputFilter, class allowlist or class denylist. Because this code path is reached whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer, an attacker able to publish a crafted ObjectMessage to a queue or topic consumed by a Camel application could achieve remote code execution when a deserialization gadget chain was present on the classpath. The same handling was reached transitively through camel-sjms2 (whose Sjms2Endpoint extends SjmsEndpoint) and through camel-amqp (whose AMQPJmsBinding extends JmsBinding), and by other JMS-family components built on JmsComponent such as camel-activemq and camel-activemq6. This issue affects Apache Camel: from 3.0.0 before 4.14.7, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.7. If users are on the 4.18.x releases
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 openwall.com
Apr 27, 2026The camel-mina component's MinaConverter.toObjectInput(IoBuffer) type converter wraps an IoBuffer in a java.io.ObjectInputStream without applying any ObjectInpuCVE-2026-40473 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.8
The camel-mina component's MinaConverter.toObjectInput(IoBuffer) type converter wraps an IoBuffer in a java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. When a Camel route uses camel-mina as a TCP or UDP consumer and requests conversion to ObjectInput (for example via getBody(ObjectInput.class) or @Body ObjectInput), an attacker sending a crafted serialized Java object over the network to the MINA consumer port can trigger arbitrary code execution in the context of the application during readObject(). This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
Product
Apache Camel Mina
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 openwall.com
Apr 27, 2026The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such as 'CAmelExecCommandExecutable' are filteCVE-2026-40453 · Email & office · Apache Software Foundation · reported by security@apache.orgCritical 9.9
The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such as 'CAmelExecCommandExecutable' are filtered out alongside 'CamelExecCommandExecutable'. The same setLowerCase(true) call was not applied to five non-HTTP HeaderFilterStrategy implementations: JmsHeaderFilterStrategy and ClassicJmsHeaderFilterStrategy in camel-jms, SjmsHeaderFilterStrategy in camel-sjms, CoAPHeaderFilterStrategy in camel-coap, and GooglePubsubHeaderFilterStrategy in camel-google-pubsub. Because those strategies use case-sensitive String.startsWith('Camel'/'camel') filtering while the Camel Exchange stores headers in a case-insensitive map, an attacker with JMS (or equivalent) producer access to the broker consumed by a Camel route can inject case-variant Camel internal headers, which are then resolved by downstream components such as camel-exec and camel-file using their canonical casing. This enables remote code execution and arbitrary file write on routes that forward JMS messages to header-driven components. This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0. Users are recommended to
Product
Apache Camel JMS
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 access.redhat.com
Apr 27, 2026The Camel-PQC FileBasedKeyLifecycleManager class deserializes the contents of `<keyId>.key` files in the configured key directory using java.io.ObjectInputStreaCVE-2026-40048 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 7.8
The Camel-PQC FileBasedKeyLifecycleManager class deserializes the contents of `<keyId>.key` files in the configured key directory using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. The cast to `java.security.KeyPair` is evaluated only after `readObject()` has already returned, so any `readObject()` side effects in the deserialized object run before the type check. An attacker who can write to the key directory used by a Camel application — for example through a path traversal into the directory, misconfigured filesystem permissions on the volume where keys are stored, a compromised key provisioning pipeline, or a symlink attack — can place a crafted serialized Java object that, when deserialized during normal key lifecycle operations, results in arbitrary code execution in the context of the application. This issue affects Apache Camel: from 4.19.0 before 4.20.0, from 4.18.0 before 4.18.2. Users are recommended to upgrade to version 4.20.0, which fixes the issue by replacing java.io.ObjectInputStream-based key and metadata storage with standard PKCS#8 (private key) / X.509 SubjectPublicKeyInfo (public key) Base64 JSON encoding. F
Product
Apache Camel PQC
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 openwall.com
Apr 22, 2026A flaw was found in camel-infinispan.CVE-2026-6857 · Other software · Red Hat · reported by Red HatHigh 7.5
A flaw was found in camel-infinispan. This vulnerability involves unsafe deserialization in the ProtoStream remote aggregation repository. A remote attacker with low privileges could exploit this by sending specially crafted data, leading to arbitrary code execution. This allows the attacker to gain full control over the affected system, impacting its confidentiality, integrity, and availability.
Product
Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Mar 25, 2026Directory Traversal vulnerability in the extractFile method of org.codehaus.plexus.util.Expand in plexus-utils before 6d780b3378829318ba5c2d29547e0012d5b29642.CVE-2025-67030 · Other software · Red Hat · reported by MITREHigh 8.8
Directory Traversal vulnerability in the extractFile method of org.codehaus.plexus.util.Expand in plexus-utils before 6d780b3378829318ba5c2d29547e0012d5b29642. This allows an attacker to execute arbitrary code
Product
Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record gist.github.com github.com
Feb 23, 2026Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component.CVE-2026-25747 · Websites & servers · Apache Software Foundation · reported by security@apache.orgHigh 8.8
Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component. The Camel-LevelDB DefaultLevelDBSerializer class deserializes data read from the LevelDB aggregation repository using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. An attacker who can write to the LevelDB database files used by a Camel application can inject a crafted serialized Java object that, when deserialized during normal aggregation repository operations, results in arbitrary code execution in the context of the application. This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.5, from 4.15.0 before 4.18.0. Users are recommended to upgrade to version 4.18.0, which fixes the issue. For the 4.10.x LTS releases, users are recommended to upgrade to 4.10.9, while for 4.14.x LTS releases, users are recommended to upgrade to 4.14.5
Product
Apache Camel LevelDB
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
Feb 23, 2026Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component.CVE-2026-23552 · Websites & servers · Apache Software Foundation · reported by security@apache.orgCritical 9.1
Cross-Realm Token Acceptance Bypass in KeycloakSecurityPolicy Apache Camel Keycloak component. The Camel-Keycloak KeycloakSecurityPolicy does not validate the iss (issuer) claim of JWT tokens against the configured realm. A token issued by one Keycloak realm is silently accepted by a policy configured for a completely different realm, breaking tenant isolation. This issue affects Apache Camel: from 4.15.0 before 4.18.0. Users are recommended to upgrade to version 4.18.0, which fixes the issue.
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
Jan 14, 2026Cypher Injection vulnerability in Apache Camel camel-neo4j component.CVE-2025-66169 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.3
Cypher Injection vulnerability in Apache Camel camel-neo4j component. This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.3, from 4.15.0 before 4.17.0 Users are recommended to upgrade to version 4.10.8 for 4.10.x LTS and 4.14.3 for 4.14.x LTS and 4.17.0.
Product
Apache Camel Neo4j
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 openwall.com
Jan 7, 2026A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications.CVE-2025-12543 · Other software · Red Hat · reported by Red HatCritical 9.6
A flaw was found in the Undertow HTTP server core, which is used in WildFly, JBoss EAP, and other Java applications. The Undertow library fails to properly validate the Host header in incoming HTTP requests.As a result, requests containing malformed or malicious Host headers are processed without rejection, enabling attackers to poison caches, perform internal network scans, or hijack user sessions.
Product
Red Hat build of Apache Camel 4.14.4 for Spring Boot 3.5.11
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Sep 2, 2025A flaw was found in Undertow where malformed client requests can trigger server-side stream resets without triggering abuse counters.CVE-2025-9784 · Other software · Red Hat · reported by Red HatHigh 7.5
A flaw was found in Undertow where malformed client requests can trigger server-side stream resets without triggering abuse counters. This issue, referred to as the "MadeYouReset" attack, allows malicious clients to induce excessive server workload by repeatedly causing server-side stream aborts. While not a protocol bug, this highlights a common implementation weakness that can be exploited to cause a denial of service (DoS).
Product
Red Hat build of Apache Camel 4.14.2 for Spring Boot 3.5.8
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Apr 1, 2025Bypass/Injection vulnerability in Apache Camel in Camel-Undertow component under particular conditions.CVE-2025-30177 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 6.5
Bypass/Injection vulnerability in Apache Camel in Camel-Undertow component under particular conditions. This issue affects Apache Camel: from 4.10.0 before 4.10.3, from 4.8.0 before 4.8.6. Users are recommended to upgrade to version 4.10.3 for 4.10.x LTS and 4.8.6 for 4.8.x LTS. Camel undertow component is vulnerable to Camel message header injection, in particular the custom header filter strategy used by the component only filter the "out" direction, while it doesn't filter the "in" direction. This allows an attacker to include Camel specific headers that for some Camel components can alter the behaviour such as the camel-bean component, or the camel-exec component.
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
Mar 12, 2025A flaw was found in Smallrye, where smallrye-fault-tolerance is vulnerable to an out-of-memory (OOM) issue.CVE-2025-2240 · Other software · Red Hat · reported by Red HatHigh 7.5
A flaw was found in Smallrye, where smallrye-fault-tolerance is vulnerable to an out-of-memory (OOM) issue. This vulnerability is externally triggered when calling the metrics URI. Every call creates a new object within meterMap and may lead to a denial of service (DoS) issue.
Product
Red Hat build of Apache Camel 4.8.5 for Spring Boot
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Mar 12, 2025Bypass/Injection vulnerability in Apache Camel.CVE-2025-29891 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 4.8
Bypass/Injection vulnerability in Apache Camel. This issue affects Apache Camel: from 4.10.0 before 4.10.2, from 4.8.0 before 4.8.5, from 3.10.0 before 3.22.4. Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases. This vulnerability is present in Camel's default incoming header filter, that allows an attacker to include Camel specific headers that for some Camel components can alter the behaviours such as the camel-bean component, or the camel-exec component. If you have Camel applications that are directly connected to the internet via HTTP, then an attacker could include parameters in the HTTP requests that are sent to the Camel application that get translated into headers. The headers could be both provided as request parameters for an HTTP methods invocation or as part of the payload of the HTTP methods invocation. All the known Camel HTTP component such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http would be vulnerable out of the box. This CVE is related to the CVE-2025-27636: while they have the same root cause and are fixed with the same fix, CVE-2025-27636 was ass
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
Mar 9, 2025Bypass/Injection vulnerability in Apache Camel components under particular conditions.CVE-2025-27636 · Websites & servers · Apache Software Foundation · reported by security@apache.orgMedium 5.6
Bypass/Injection vulnerability in Apache Camel components under particular conditions. This issue affects Apache Camel: from 4.10.0 through <= 4.10.1, from 4.8.0 through <= 4.8.4, from 3.10.0 through <= 3.22.3. Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases. This vulnerability is present in Camel's default incoming header filter, that allows an attacker to include Camel specific headers that for some Camel components can alter the behaviours such as the camel-bean component, to call another method on the bean, than was coded in the application. In the camel-jms component, then a malicious header can be used to send the message to another queue (on the same broker) than was coded in the application. This could also be seen by using the camel-exec component The attacker would need to inject custom headers, such as HTTP protocols. So if you have Camel applications that are directly connected to the internet via HTTP, then an attacker could include malicious HTTP headers in the HTTP requests that are send to the Camel application. All the known Camel HTTP component such as camel-servlet, camel-jetty,
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 issues.apache.org
Feb 26, 2025A flaw was found in the quarkus-resteasy extension, which causes memory leaks when client requests with low timeouts are made.CVE-2025-1634 · Other software · Red Hat · reported by Red HatHigh 7.5
A flaw was found in the quarkus-resteasy extension, which causes memory leaks when client requests with low timeouts are made. If a client request times out, a buffer is not released correctly, leading to increased memory usage and eventual application crash due to OutOfMemoryError.
Product
Red Hat Build of Apache Camel 4.8 for Quarkus 3.15
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Feb 13, 2025A flaw was found in Quarkus REST that allows request parameters to leak between concurrent requests if endpoints use field injection without a CDI scope.CVE-2025-1247 · Other software · Red Hat · reported by Red HatHigh 8.3
A flaw was found in Quarkus REST that allows request parameters to leak between concurrent requests if endpoints use field injection without a CDI scope. This vulnerability allows attackers to manipulate request data, impersonate users, or access sensitive information.
Product
Red Hat Build of Apache Camel 4.8 for Quarkus 3.15
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Oct 8, 2024A vulnerability was found in Quarkus CXF.CVE-2024-9621 · Other software · Red Hat · reported by Red HatMedium 5.3
A vulnerability was found in Quarkus CXF. Passwords and other secrets may appear in the application log in spite of the user configuring them to be hidden. This issue requires some special configuration to be vulnerable, such as SOAP logging enabled, application set client, and endpoint logging properties, and the attacker must have access to the application log.
Product
Red Hat Build of Apache Camel 4.4 for Quarkus 3.8
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Aug 21, 2024A vulnerability was found in Undertow where the ProxyProtocolReadListener reuses the same StringBuilder instance across multiple requests.CVE-2024-7885 · Other software · Red Hat · reported by Red HatHigh 7.5
A vulnerability was found in Undertow where the ProxyProtocolReadListener reuses the same StringBuilder instance across multiple requests. This issue occurs when the parseProxyProtocolV1 method processes multiple requests on the same HTTP connection. As a result, different requests may share the same StringBuilder instance, potentially leading to information leakage between requests or responses. In some cases, a value from a previous request or response may be erroneously reused, which could lead to unintended data exposure. This issue primarily results in errors and connection termination but creates a risk of data leakage in multi-request environments.
Product
HawtIO 4.0.0 for Red Hat build of Apache Camel 4
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Jul 8, 2024A vulnerability was found in Undertow, where the chunked response hangs after the body was flushed.CVE-2024-5971 · Other software · Red Hat · reported by Red HatHigh 7.5
A vulnerability was found in Undertow, where the chunked response hangs after the body was flushed. The response headers and body were sent but the client would continue waiting as Undertow does not send the expected 0\r\n termination of the chunked response. This results in uncontrolled resource consumption, leaving the server side to a denial of service attack. This happens only with Java 17 TLSv1.3 scenarios.
Product
Red Hat build of Apache Camel 3.20.7 for Spring Boot
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Apr 4, 2024A vulnerability was found in the quarkus-core component.CVE-2024-2700 · Other software · Red Hat · reported by Red HatHigh 7
A vulnerability was found in the quarkus-core component. Quarkus captures local environment variables from the Quarkus namespace during the application's build, therefore, running the resulting application inherits the values captured at build time. Some local environment variables may have been set by the developer or CI environment for testing purposes, such as dropping the database during application startup or trusting all TLS certificates to accept self-signed certificates. If these properties are configured using environment variables or the .env facility, they are captured into the built application, which can lead to dangerous behavior if the application does not override these values. This behavior only happens for configuration properties from the `quarkus.*` namespace. Application-specific properties are not captured.
Product
HawtIO 4.0.0 for Red Hat build of Apache Camel 4
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Mar 22, 2024A flaw was found in XNIO.CVE-2023-5685 · Other software · Red Hat · reported by Red HatHigh 7.5
A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS).
Product
Red Hat build of Apache Camel 4.4.0 for Spring Boot
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record access.redhat.com access.redhat.com
Feb 26, 2024Exposure of sensitive data by by crafting a malicious EventFactory and providing a custom ExchangeCreatedEvent that exposes sensitive data.CVE-2024-22371 · Email & office · Apache Software Foundation · reported by security@apache.orgLow 2.9
Exposure of sensitive data by by crafting a malicious EventFactory and providing a custom ExchangeCreatedEvent that exposes sensitive data. Vulnerability in Apache Camel.This issue affects Apache Camel: from 3.21.X through 3.21.3, from 3.22.X through 3.22.0, from 4.0.X through 4.0.3, from 4.X through 4.3.0. Users are recommended to upgrade to version 3.21.4, 3.22.1, 4.0.4 or 4.4.0, which fixes the issue.
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

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.