Overview 65 matches · 0 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
65
100.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
65
100.0%
partly blocked
0
0.0%
not blocked
0
0.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
1
1.5%
Proof of concept only
10
15.4%
Forecast only
0
0.0%
No public exploit
54
83.1%
split by
peak 24 / month
Aug 2617
Protected by Waratek17
High17
blocked by ARMR today17
Working exploit published1
Proof of concept only4
No public exploit12
Sep 2619
Protected by Waratek19
High19
blocked by ARMR today19
No public exploit19
Oct 2624
Protected by Waratek24
High24
blocked by ARMR today24
Proof of concept only6
No public exploit18
Nov 265
Protected by Waratek5
High5
blocked by ARMR today5
No public exploit5
Aug 26Sep 26Oct 26Nov 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-12389 | High | 2026-11-10 | Protected by Waratek | No public exploit | A vulnerability that could lead to a high privileged authenticated user performing a remote code execution attack. |
| CVE-2026-82440 | High | 2026-11-09 | Protected by Waratek | No public exploit | Description Nimbus instantiates the class named by a topology's `topology.scheduler.strategy` when scheduling it. The allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as "allow any class" when unset, and it had no entry in the shipped `defaults.yaml`, so unset was the shipped state. An authenticated submitter could therefore cause Nimbus to instantiate any class on the Nimbus classpath that has a no-argument constructor. Storm's own production artifacts contain classes with side effects suitable for this: instantiating `org.apache.storm.testing.InProcessZookeeper` starts a ZooKeeper server with its own threads and sockets and nothing closes it, and `org.apache.storm.LocalCluster` behaves similarly. Repeated submissions therefore consume threads, sockets and memory in the most privileged daemon in the cluster. Mitigation Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class. Note that this is a behaviour change: a cluster running an out-of-tree scheduler strategy without an explicit allowlist will have those topologies refused until the class is added to `nimbus.scheduler.strategy.class.whitelist`. The rejection message names the refused class and the configuration key. Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to the strategies they intend to permit. |
| CVE-2026-109408 | High | 2026-11-05 | Protected by Waratek | No public exploit | vault-java-driver, a Java client for HashiCorp Vault, silently disables TLS certificate and hostname verification in three states where the caller asked for verification: an SslConfig passed to VaultConfig without calling build(), an SslConfig restored by Java deserialization, and VAULT_SSL_VERIFY set to a truthy value other than "true", such as 1, yes or on. In each case SslConfig.isVerify() returns false and the driver installs a trust-all SSLContext. An attacker on the network path to the Vault server can then read the Vault token and secrets in transit and forge responses. This issue affects io.github.jopenlibs:vault-java-driver 5.2.0 through 6.2.3. It is fixed in 7.0.0. |
| CVE-2026-119724 | High | 2026-11-03 | Protected by Waratek | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Improper restriction of recursive entity references in DTDs ('XML entity expansion') vulnerability in Apache JClouds. This issue affects Apache JClouds: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| CVE-2026-2613 | High | 2026-11-02 | Protected by Waratek | No public exploit | The Admin REST API accepts user-supplied input without adequately sanitizing it, allowing it to be included in the structure of SQL statements. A user with administrator privileges can exploit this by influencing the structure of executed SQL statements, enabling blind SQL injection to infer database information and potentially impact the availability of the database service. |
| CVE-2026-63224 | High | 2026-10-30 | Protected by Waratek | Proof of concept only | OpenRemote is an open-source internet-of-things platform. Prior to 1.26.0, the `datapoint export` API constructs `CSV crosstab` SQL by concatenating an `asset name` and `attribute name` into a `COPY` query that uses `crosstab` and streams `TO STDOUT`. The `asset name` enters both a double-quoted column identifier and a category query enclosed by the fixed `$cat$` delimiter. Escaping single quotes in one string context does not escape embedded double quotes in identifiers or protect that dollar-quote boundary. An authenticated user permitted to create or rename an asset and read/export datapoints for one of its attributes can store SQL metacharacters in the name and request a `crosstab` export, causing injected SELECT output to be returned in the normal ZIP/CSV response. This enables database exfiltration without direct database or filesystem access or token forgery. In a multi-tenant deployment it can expose other tenants' data if the manager's database role can read shared tables; integrity and availability effects are not established by the demonstrated read primitive. This issue is fixed in version 1.26.0. |
| CVE-2026-61586 | High | 2026-10-30 | Protected by Waratek | No public exploit | Copernik XML Factory provides secure-by-default JAXP factory creation for Java. Prior to 0.1.2, Copernik XML Factory does not block XInclude resource resolution on the stock JDK provider after an application enables XInclude on a factory returned by `XmlFactories.newDocumentBuilderFactory()` or `XmlFactories.newSAXParserFactory()`, or on an `XMLReader` passed through `XmlFactories.harden()`. An application parsing untrusted XML can resolve attacker-controlled `xi:include` references to disclose local files or, through `http` references, reach internal network endpoints by server-side request forgery. Exploitation requires use of one of those factory/hardening APIs, the stock JDK provider with Apache Xerces absent from the classpath, explicit `setXIncludeAware(true)` or the equivalent reader feature, and XML from an untrusted source. The Xerces provider selected when Xerces is present and the Android provider are unaffected. This issue is fixed in version 0.1.2. |
| CVE-2026-15564 | High | 2026-10-29 | Protected by Waratek | No public exploit | Wildfly's IIOP listener may permit deserialization of input streams before authentication is performed. An attacker who can gain access to the IIOP port may be able to construct and send malicious objects and achieve deserialization, if the target EJB allows untyped method parameters, and depending on the potential gadget chains available in the running classpath. |
| CVE-2026-117624 | High | 2026-10-28 | Protected by Waratek | No public exploit | Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not consistently enforce the restriction on deserializing objects of types marked as storing their configuration in independent top-level configuration files as nested values, allowing attackers to bypass the root element check and potentially inject nested objects. |
| CVE-2026-117616 | High | 2026-10-28 | Protected by Waratek | No public exploit | Jenkins 2.587 and earlier, LTS 2.580.1 and earlier provides an HTTP endpoint that loads agents by name without validating the name, allowing attackers with Overall/Read permission to load any config.xml file on the controller file system as an agent configuration, and to overwrite an arbitrary config.xml file when that agent is saved, potentially resulting in arbitrary code execution. |
| CVE-2026-111551 | High | 2026-10-28 | Protected by Waratek | No public exploit | Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check. |
| CVE-2026-90885 | High | 2026-10-26 | Protected by Waratek | No public exploit | Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default. |
| CVE-2026-113582 | High | 2026-10-22 | Protected by Waratek | No public exploit | UNSUPPORTED WHEN ASSIGNED Improper restriction of XML external entity references in Apache Abdera allows an attacker to access sensitive data or make server-side requests when an application parses attacker-controlled XML with Abdera. This issue affects Apache Abdera: all versions. Apache Abdera is retired and no longer supported, so we do not plan to release a version that fixes this issue. Users are recommended to migrate to a maintained alternative. Applications that cannot migrate should ensure that untrusted XML cannot reach the affected Abdera parser or JDBC adapter parsing paths. Actively maintained downstream products may still be impacted if they include an affected Abdera artifact. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| CVE-2026-111075 | High | 2026-10-21 | Protected by Waratek | No public exploit | In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset` fields during `DataDescriptor` message deserialization. An unauthenticated remote attacker can send a crafted network payload that triggers an unsigned integer underflow in `DataDescriptor::getPayloadSize()` and `DataDescriptor::getNextDescriptor()`. This results in an out-of-bounds heap read and an immediate process crash (SIGSEGV), causing a denial of service. |
| CVE-2026-101457 | High | 2026-10-20 | Protected by Waratek | No public exploit | Vulnerability in the Siebel Apps - Life Sciences product of Oracle Siebel CRM (component: eDetailing). Supported versions that are affected are 17.0-26.9. Easily exploitable vulnerability allows low privileged attacker with network access via SQL to compromise Siebel Apps - Life Sciences. Successful attacks of this vulnerability can result in takeover of Siebel Apps - Life Sciences. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). |
| CVE-2026-88901 | High | 2026-10-19 | Protected by Waratek | No public exploit | Improper Restriction of XML External Entity Reference vulnerability in Apache Camel. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. Improper Restriction of XML External Entity Reference in the Smooks component (camel-smooks) in Apache Camel allows an attacker who supplies the XML message body to read local files or issue requests to internal network locations via an external entity declaration in that body. This issue affects Apache Camel: from 4.7.0 before 4.18.5, from 4.19.0 before 4.22.1. The Smooks data format (.unmarshal().smooks(...)) and the Smooks component (smooks:) parse the incoming XML body with the reader Smooks resolves by default, which is the Woodstox SAX parser. That reader resolves external general and parameter entities and loads external DTDs, and camel-smooks applied none of the parser hardening that the other Camel XML components apply. A DOCTYPE with an external subset, or an external general entity, declared in the XML document is therefore resolved and expanded while the body is unmarshalled, and the resolved content is bound into the unmarshalled result and returned on InOut routes. An external sender whose XML reaches a camel-smooks data format or endpoint could therefore read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since resolving external entities was the default behaviour. Configurations that declare their own reader - EDI, CSV, JSON, or a custom reader - do not use the XML reader and are not affected. Users are recommended to upgrade to version 4.18.5, 4.22.1 or 4.23.0, which fixes the issue. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. camel-smooks now parses the XML body with a javax.xml.parsers.DocumentBuilder that does not resolve external general or parameter entities and does not load external DTDs, and hands Smooks the resulting document, matching the secure XML processing configuration used by org.apache.camel.converter.jaxp.XmlConverter and the other Camel XML components. This hardening is applied only when the Smooks configuration parses XML with its default reader, so EDI, CSV, JSON and custom-reader configurations, and the marshalling direction, are unchanged. A new allowExternalEntities option, disabled by default, restores the previous behaviour for trusted legacy configurations that rely on external entity resolution. The camel-4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not apply camel-smooks to XML received from untrusted senders. |
| CVE-2026-88900 | High | 2026-10-19 | Protected by Waratek | No public exploit | Deserialization of Untrusted Data vulnerability in Apache Camel Camel-Jgroups component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. JGroupsEndpoint.createExchange(Message), which CamelJGroupsReceiver calls for every message the jgroups consumer receives before the exchange is routed, set the exchange body from org.jgroups.Message.getObject(). For an ObjectMessage, which is the message type the Camel jgroups producer sends, JGroups Java-deserializes the payload through an ObjectInputStream on its own receive thread as the message arrives, and getObject() returns the resulting object. No java.io.ObjectInputFilter was applied on that path unless the deployment had set a JVM-wide serialization filter: camel-jgroups installed none, and the JGroups versions shipped with the affected releases apply none of their own, so any serializable class on the application classpath could be instantiated and its deserialization callbacks run. Unless a channel or the channelProperties option is configured, the consumer creates its channel with new JChannel(), the stock JGroups protocol stack, which multicasts over UDP without the AUTH protocol and without encryption, so any host able to reach the cluster's multicast group or bind port can join the cluster and send messages to the consumer without credentials. Such a host could send a crafted serialized object that leads to remote code execution in the Camel process when a usable deserialization gadget chain is present on the classpath, and no non-default option was required on the consumer. Because JGroups materializes the object before Camel's receiver runs, a check performed by Camel can only inspect the deserialized result and cannot stop code that runs during deserialization, so closing the issue also requires a control that applies before the payload is read, as described in the mitigation. Exploitation requires network access to the cluster's multicast group or bind port, which with the default UDP multicast transport means a host on an adjacent network, and a usable gadget chain on the classpath, which is why the severity is assessed as high rather than critical. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, and the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. |
| CVE-2026-85250 | High | 2026-10-19 | Protected by Waratek | No public exploit | Improper Restriction of XML External Entity Reference vulnerability in Apache Camel XPath component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. With documentType set to InputSource, XPathBuilder handed the payload straight to javax.xml.xpath, which builds a DocumentBuilder of its own using the JDK defaults. The hardening applied to Camel's default document type was therefore bypassed: a DOCTYPE declaration that is refused on the default type was accepted here, and the external entity it declared was resolved and expanded into the evaluated document. An external sender whose XML reaches such an expression could read files readable by the Camel process and cause the process to issue requests to hosts it names. The two document types disagreeing on parser configuration is what made this reachable, since a deployment choosing InputSource for streaming reasons had no indication it was also choosing a weaker parser. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The InputSource document type now goes through the same hardened parser as the default type, so a DOCTYPE is refused. Note that it also shares that type's documented escape hatch: the same DocumentBuilderFactory system properties that relax the default type relax this one, so a deployment that has set them remains unprotected by design. For deployments that cannot upgrade immediately, do not use documentType=InputSource on expressions evaluated over untrusted XML; the default document type already refuses a DOCTYPE. |
| CVE-2026-79985 | High | 2026-10-19 | Protected by Waratek | Proof of concept only | 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 single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint's own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel carries no integrity protection at all, so an on-path attacker can rewrite a LIST response without holding any credentials; a compromised, malicious or multi-tenant server, or a server backed by a virtual filesystem, can emit such a name directly. Retrieval is reachable in a default consumer configuration, since the remote consumers download every listed file; deletion and renaming additionally require one of the disposition options above, all of which are common. Escape from the directory Camel was configured to poll is unconditional, while escape from the server's own account boundary additionally depends on whether that server confines the account. The jailStartingDirectory option, which is documented as restricting Camel to the starting directory and is enabled by default, governed producer writes and, since the localWorkDirectory containment work, consumer downloads to the local work directory - but it did not constrain this remote operand, so its name and description claimed a boundary that was not enforced here. The same entry point had already been recognised on the local side: the localWorkDirectory download path was constrained so that a remote file name containing parent-directory segments could not resolve outside the local work directory. The remote operand was the remaining half of that surface. This artifact provides the smb scheme. Its consumer walks the share listing on its own rather than through RemoteFileConsumer, skipping only the exact "." and ".." entries, so a name carrying traversal segments in any other form was concatenated unchecked. Reaching it requires a server that emits a listing name which is not a single path segment, which a conforming SMB2 implementation does not do; the exposure was corrected on the same basis as the other remote-file consumers rather than from a demonstrated proof of concept against this scheme. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x releases stream should upgrade to 4.22.1. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. The 4.14.x stream reached end of life and does not receive this fix; users on it should move to a supported releases stream. |
| CVE-2026-79984 | High | 2026-10-19 | Protected by Waratek | Proof of concept only | 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 a single path segment therefore resolved to a path outside the configured polling directory, causing Camel to read, delete or rename files outside it using the endpoint's own credentials. A listing name is not route-controlled data. It is supplied by the remote server, and the FTP control channel carries no integrity protection at all, so an on-path attacker can rewrite a LIST response without holding any credentials; a compromised, malicious or multi-tenant server, or a server backed by a virtual filesystem, can emit such a name directly. Retrieval is reachable in a default consumer configuration, since the remote consumers download every listed file; deletion and renaming additionally require one of the disposition options above, all of which are common. Escape from the directory Camel was configured to poll is unconditional, while escape from the server's own account boundary additionally depends on whether that server confines the account. The jailStartingDirectory option, which is documented as restricting Camel to the starting directory and is enabled by default, governed producer writes and, since the localWorkDirectory containment work, consumer downloads to the local work directory - but it did not constrain this remote operand, so its name and description claimed a boundary that was not enforced here. The same entry point had already been recognised on the local side: the localWorkDirectory download path was constrained so that a remote file name containing parent-directory segments could not resolve outside the local work directory. The remote operand was the remaining half of that surface. This artifact provides the mina-sftp scheme, an alternative SFTP implementation whose consumer derives from the same RemoteFileConsumer base class and therefore inherited the same unconstrained resolution. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.22.x releases stream should upgrade to 4.22.1. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. The 4.14.x stream reached end of life and does not receive this fix; users on it should move to a supported releases stream. |
| CVE-2026-78165 | High | 2026-10-19 | Protected by Waratek | Proof of concept only | 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 Redis keyspace, and SpringRedisIdempotentRepository shared that template. Configuring a custom redisTemplate did not close the consumer path, because RedisConsumer.setBody reads getSerializer directly rather than the serializer attached to the template, so a deployment that had wired a String serializer into its own template remained exposed on the consumer side unless it also set the serializer option. The component never constructed a java.io.ObjectInputStream itself, which is why earlier passes over the Camel codebase for unfiltered Java deserialization did not reach it. The behaviour dates back to the introduction of the component, first released in 2.11.0, and was unchanged until this fix. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, set the JVM-wide jdk.serialFilter system property, which the affected code path honours because it reads through a java.io.ObjectInputStream, for example -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; or set the serializer endpoint option to a serializer that does not use Java serialization, such as StringRedisSerializer, noting that this must be set as the serializer option and not only on a custom redisTemplate. As defence in depth, require authentication on the Redis instance and restrict which clients may publish to the subscribed channels, and do not expose a Redis instance consumed by Camel to untrusted networks. |
| CVE-2026-84823 | High | 2026-10-16 | Protected by Waratek | No public exploit | A flaw was found in WildFly. A user with the `Monitor` role, which is the lowest standard Role-Based Access Control (RBAC) role, can exploit a path traversal vulnerability in the `take-snapshot` operation. By manipulating the `name` parameter, this user can write a copy of the server configuration to an arbitrary location. This allows the `Monitor` role to read back the server configuration, including sensitive credentials, which would otherwise be restricted by RBAC, leading to information disclosure. |
| CVE-2026-85634 | High | 2026-10-15 | Protected by Waratek | No public exploit | A flaw was found in the ContentRepositoryImpl.copyExplodedContent function of the wildfly-core library, which is used by WildFly and JBoss EAP to manage server deployments. The issue occurs when the library processes an unsanitized deployment name. Due to a missing containment check, an attacker with the Deployer RBAC role can use path traversal sequences to access files outside the restricted deployment directory. This can allow the attacker to delete arbitrary directories or create files with arbitrary content, leading to a full privilege escalation to the management SuperUser role. |
| CVE-2026-110614 | High | 2026-10-14 | Protected by Waratek | Proof of concept only | Yiuman citrus through 0.15.0 contains an ORDER BY sql injection vulnerability in the citrus-support generic query framework that allows users to inject SQL via the sortBy request parameter. Attackers can reach any generic list route of controllers extending BaseQueryController or BaseQueryRestful to append unvalidated SQL to the ORDER BY clause and extract database contents using boolean- or time-based blind techniques. |
| CVE-2026-93905 | High | 2026-10-13 | Protected by Waratek | No public exploit | IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.10 could allow an unauthenticated remote attacker to corrupt the persisted status of batch job instances. |
| CVE-2026-54640 | High | 2026-10-13 | Protected by Waratek | No public exploit | OpenRemote is an open-source internet-of-things platform. Prior to 1.24.2, the KNXProtocol.startAssetImport method in agent/src/main/java/org/openremote/agent/protocol/knx/KNXProtocol.java processes 0.xml from an authenticated user's uploaded ETS project ZIP with Saxon TransformerFactoryImpl and XMLInputFactory parsers that permit external entity resolution. This incomplete remediation of CVE-2026-40882 leaves the KNX handler unprotected while the parallel Velbus handler is hardened, allowing a regular realm user to read files accessible to the JVM process or cause server-side requests. This issue is fixed in version 1.24.2. |
| CVE-2026-105442 | High | 2026-10-13 | Protected by Waratek | No public exploit | IBM WebSphere Application Server 8.5, and 9.0 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.10 Liberty could allow a remote attacker to cause a denial of service caused by an insecure deserialization in the messaging service. |
| CVE-2026-102554 | High | 2026-10-09 | Protected by Waratek | Proof of concept only | Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams. |
| CVE-2026-88789 | High | 2026-10-01 | Protected by Waratek | No public exploit | Improper Restriction of XML External Entity Reference in the XSLT support extension (camel-quarkus-support-xalan) in Apache Camel Quarkus from 3.2.0 before 3.33.3 and from 3.34.0 before 3.40.0 on all platforms allows an attacker who supplies the XML document being transformed to read local files or issue requests to internal network locations via an external entity declaration in that document. The extension supplies its own Xalan-backed TransformerFactory to the xslt component and registers it as the JAXP default. Xalan-J 2.7.x predates JAXP 1.5 and does not honour javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD or ACCESS_EXTERNAL_STYLESHEET, so the external access restrictions Apache Camel applies to the TransformerFactory it creates were not in effect. On the xslt component path this affects message bodies that reach the transformer already as a javax.xml.transform.Source; bodies of other types are converted to a SAXSource by Apache Camel with external entities and external DTD loading disabled, and are not affected. Because the factory is also the JAXP default, other code in the application obtaining one through TransformerFactory.newInstance() loses the same restrictions without error. Applications are affected if they use any of camel-quarkus-xslt, camel-quarkus-xslt-saxon, camel-quarkus-tika or camel-quarkus-xmlsecurity, each of which brings the XSLT support extension onto the classpath. For all but camel-quarkus-xslt, the exposure is limited to the JAXP default factory, since those extensions do not perform XSLT transformations themselves. Users are recommended to upgrade to version 3.33.3 or 3.40.0, which fixes this issue. |
| CVE-2026-103088 | High | 2026-09-30 | Protected by Waratek | No public exploit | Handlebars.java before 4.5.5 allows directory traversal. In handlebars-springmvc 4.5.3 and 4.5.4, the path-containment fix for CVE-2026-63490 validates template locations as raw percent-encoded strings, whereas the template file is opened through a URL handler that percent-decodes the path. In a Spring MVC application with a file: template prefix and a request-derived view name, a percent-encoded traversal such as %2e%2e/ bypasses both the view-resolver check and the loader-side containment and reads files outside the configured template base directory. |
| CVE-2026-82804 | High | 2026-09-29 | Protected by Waratek | No public exploit | The scriptPath parameter is incorporated into a /bin/sh -c command without sufficient neutralization of shell metacharacters, allowing shell command substitution and execution. An authenticated user can exploit this behavior by creating a resource whose filename contains shell command substitution syntax, such as $(...), and subsequently supplying the resulting path to the Alert Script plugin's /test-send endpoint. When the alert script is executed, the shell interprets the injected command, resulting in arbitrary command execution with the privileges of the DolphinScheduler service process. This issue affects Apache DolphinScheduler: before 3.4.3. Users are recommended to upgrade to version 3.4.3, which fixes the issue. |
| CVE-2026-91006 | High | 2026-09-28 | Protected by Waratek | No public exploit | Apache Karaf's instance-management service (InstanceServiceImpl) builds the command line used to launch a child Karaf JVM by string concatenation, then executes it through /bin/sh (Unix) or cscript (Windows). The caller-supplied javaOpts value is spliced into that string unquoted. A javaOpts value containing shell metacharacters (;, |, `, $(...)) is interpreted by the shell instead of being passed to the JVM as an option, giving arbitrary OS command execution as the Karaf process user. Reachable via the shell commands instance:create, instance:start, instance:restart, instance:change-opts, and the equivalent InstanceMBean JMX operations (createInstance, startInstance, changeJavaOpts, cloneInstance). Mitigation * Set karaf.secured.command.compulsory.roles=admin in etc/system.properties to close the fail-open gap for all unconfigured command scopes. * Restrict which principals can reach instance:* commands and InstancesMBean via etc/users.properties role assignments. * Treat javaOpts passed to instance:create/instance:start/instance:change-opts/InstancesMBean as untrusted input only from fully-trusted operators. |
| CVE-2026-70410 | High | 2026-09-22 | Protected by Waratek | No public exploit | Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Apache Calcite Avatica. Plugin instantiation (via AvaticaUtils#instantiatePlugin and other methods) initializes arbitrary classes via unrestricted calls to Class.forName(String) which by default triggers initialization. This may lead to the execution of static initializer blocks in arbitrary classes present in the classpath. The instantiation APIs should initialize and instantiate only classes implementing the specified plugin interface passed as input in conjunction with the desired classname. At the moment of writing, there are no well-known or widely used classes with dangerous static initializer blocks so the severity is low. This issue affects Apache Calcite Avatica: before 1.29.0. Users are recommended to upgrade to version 1.29.0, which fixes the issue. |
| CVE-2026-61570 | High | 2026-09-22 | Protected by Waratek | No public exploit | MPXJ is an open source library to read and write project plans from a variety of file formats and databases. From 5.5.5 until 16.4.1, MerlinReader creates a DocumentBuilder with default settings while parsing XML from the ZTIMEINTERVALS column of a Merlin project SQLite database, leaving doctype declarations and external entities enabled. A crafted database can cause the parser to read an arbitrary local file, although MPXJ's subsequent handling of the parsed XML makes disclosure of the file contents unlikely. This issue is fixed in version 16.4.1. |
| CVE-2026-92126 | High | 2026-09-16 | Protected by Waratek | No public exploit | Jenkins Script Security Plugin 1415.v9a_f9b_3a_c253d and earlier does not reject @Builder annotations whose builderStrategy member names an arbitrary class, allowing attackers with permission to define and run sandboxed scripts, including Pipelines, to execute code outside the sandbox if a suitable class is present on the classpath of the component that evaluates the script. |
| CVE-2026-87976 | High | 2026-09-16 | Protected by Waratek | No public exploit | Apache NiFi Registry 0.4.0 through 2.11.0 are subject to path manipulation when storing extension bundle content using group, artifact, and version coordinates from uploaded NAR manifests. The default file persistence provider used coordinates as filesystem path components without rejected parent-directory names, and the path-containment check compared an unnormalized resolved path. An authenticated user authorized to write and delete bundles in a bucket can upload a NAR with a crafted manifest resulting in file system operations outside of the file persistence directory. Upgrading to Apache NiFi Registry 2.12.0 is the recommended mitigation, which rejects parent-directory coordinates and requires a normalized path to remain a strict child of the storage root location. |
| CVE-2026-74909 | High | 2026-09-16 | Protected by Waratek | No public exploit | Keycloak provides a policy enforcer to protect applications by matching incoming web requests against defined security policies. A flaw was found where the enforcer fails to correctly normalize web addresses that contain special encoded characters, such as those representing semicolons or directory traversal segments. An authenticated user can use these encoded characters to trick the enforcer into applying a less restrictive security policy than intended, potentially gaining unauthorized access to sensitive administrative or private application endpoints. |
| CVE-2026-54077 | High | 2026-09-15 | Protected by Waratek | No public exploit | ArcadeDB is a Multi-Model DBMS. Prior to 26.6.1, the IMPORT DATABASE statement in engine/src/main/java/com/arcadedb/query/sql/parser/ImportDatabaseStatement.java did not require administrative privileges and passed its source to integration/src/main/java/com/arcadedb/integration/importer/SourceDiscovery.java without validation. An authenticated user with SQL command access through /api/v1/command or /api/v1/query can supply HTTP or HTTPS destinations to make server-side requests to internal services, or file:// paths to read files accessible to the server process and ingest the results as queryable records. The XML importer also permits DTD processing and external entities, enabling entity expansion. The root-only /api/v1/server administration endpoint is not affected. The fix requires updateSecurity permission, blocks local-network import destinations by default through arcadedb.server.security.importBlockLocalNetworks, supports the arcadedb.server.security.importAllowedLocalPaths file allow-list, and disables XML DTD processing and external entities. This issue is fixed in version 26.6.1. |
| CVE-2026-82428 | High | 2026-09-14 | Protected by Waratek | No public exploit | Description Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from the Maven coordinate, for example `dep---.jar`. The key was therefore identical for every user of the cluster and predictable in advance. When the blob already existed, the uploader caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob's content or owner matched the artifact the submitter had resolved. A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter of the same coordinate would receive on the worker classpath, resulting in code execution inside another tenant's topology. This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used. Mitigation Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a pre-existing blob is no longer silently reused. Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology jar instead. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| CVE-2026-82427 | High | 2026-09-14 | Protected by Waratek | No public exploit | Description A topology's `topology.blobstore.map` lets the submitter choose a local name for each blob that the supervisor localises. That name was used to build a path under the topology's working directory without normalisation, in both `AsyncLocalizer` and `Container.createBlobstoreLinks`, and the symlink helper force-deletes whatever already exists at the target before creating the link. A submitter could therefore use `../` segments to direct that delete-and-symlink operation at an arbitrary path, as the supervisor user, on every node the topology is scheduled onto. The consequences include recursive deletion of supervisor-owned content and planting a symlink that causes a subsequent worker launch to execute attacker-chosen code as another tenant's operating-system user, which defeats the isolation that `supervisor.run.worker.as.user` is intended to provide. Mitigation Upgrade to 3.1.0, where the resolved target must lie inside the expected root at both call sites. Users who cannot upgrade immediately should restrict topology submission to trusted principals, and may reject submissions whose `topology.blobstore.map` entries contain path separators or `..` segments before they reach Nimbus. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| CVE-2026-67211 | High | 2026-09-11 | Protected by Waratek | No public exploit | OOM Denial of Service via Unbounded Map Pre-Sizing in Apache OpenNLP SymSpellModelSerializer Versions Affected: - 3.0.0-M4 - 3.0.0-M5 (The opennlp-spellcheck extension was introduced in 3.0.0-M4. Releases 1.x and 2.x do not contain the affected code.) Description: The SymSpellModelSerializer.create() method reads two 32-bit signed integer count fields (unigramCount and bigramCount) from a binary SymSpell model stream and passes each value directly to LinkedHashMap.newLinkedHashMap() after validating only that it is non-negative. No upper bound is applied, so the count is fully attacker-controlled when the model file originates from an untrusted source. A crafted .bin model file in which either count field is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) causes the map to be pre-sized to a capacity of 2^30 entries. The oversized backing array is allocated on the first put() into that map, requesting 4–8 GB depending on whether compressed oops are in effect, and the load fails with an OutOfMemoryError. Because the count fields sit immediately after a fixed-size header (magic, format version, three UTF strings, the configuration fields, and the edit-distance identifier) the attacker pays no meaningful size cost to weaponize a payload: a file of well under 100 bytes plus a single real entry is sufficient to crash a JVM that loads it. Any code path that deserializes a SymSpell model is affected, including SymSpellModels.deserialize(InputStream), SymSpellModels.fromBytes(byte[]), classpath model loading via SymSpellModelResolver.resolveByLanguage(String), the CorrectTextTool command-line tool, and model-archive loading through the registered ArtifactSerializer. The opennlp-spellcheck extension ships in the official OpenNLP binary distribution. The practical impact is denial of service against processes that load SymSpell model files from untrusted or semi-trusted origins. Mitigation: - 3.x users should upgrade to 3.0.0-M6. Note: The fix applies an upper bound to both count fields, checked before the map is pre-sized; counts that are negative or exceed the bound cause an IOException to be thrown and the read to fail fast with no large allocation. The bound is the existing AbstractModelReader.MAX_ENTRIES limit introduced earlie, which the current change promotes to public visibility so that serializers implementing their own binary format can share it. The default bound is 10,000,000, which is well above the entry counts of legitimate SymSpell dictionaries but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load larger dictionaries can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Note that this property is shared with the model-reader limit and raising it relaxes both. Users who cannot upgrade immediately should treat all SymSpell .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks. |
| CVE-2026-87822 | High | 2026-09-09 | Protected by Waratek | No public exploit | t-digest versions 3.1 through 3.3 fail to validate centroid means during deserialization in MergingDigest.fromBytes, allowing attackers to inject NaN values that bypass validation checks. Attackers can craft malicious serialized digests containing NaN centroids that degrade sorting performance from O(n log n) to O(n squared), causing severe processing delays during merge operations. |
| CVE-2026-86404 | High | 2026-09-07 | Protected by Waratek | No public exploit | EAP's Artemis deserialization configuration permits deserialization by default. ObjectMessage.getObject() uses ObjectInputStreamWithClassLoader, which implements allow-list/block-list filtering via its checkSecurity()/isTrustedType() method. However, by default both allow-list and block-list are empty. When the allow-list is empty (size == 0), isTrustedType() returns true for ALL classes. This means all classes are deserializable by default. |
| CVE-2026-52691 | High | 2026-09-04 | Protected by Waratek | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Griffin Hive Metastore Module. This issue affects Apache Griffin Hive Metastore Module: all versions. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| CVE-2026-84675 | High | 2026-09-02 | Protected by Waratek | No public exploit | OS command injection vulnerability in Jenkins TICS Plugin 2025.1.1 and earlier allows attackers able to control build environment variable values to execute arbitrary commands on the agent running the build. |
| CVE-2026-84670 | High | 2026-09-02 | Protected by Waratek | No public exploit | Jenkins Performance Plugin 1015.v09ca_52b_3370e and earlier does not restrict the classes that can be instantiated when deserializing cached performance reports stored in the build directory on the Jenkins controller, allowing attackers with Item/Configure permission to execute arbitrary code on the Jenkins controller. |
| CVE-2026-84669 | High | 2026-09-02 | Protected by Waratek | No public exploit | A path traversal vulnerability in Jenkins Allure Plugin 2.35.2 and earlier allows attackers with Item/Read permission on jobs that publish Allure report results to read arbitrary files on the Jenkins controller's file system. |
| CVE-2026-84650 | High | 2026-09-02 | Protected by Waratek | No public exploit | In Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, transient fields cannot be excluded from deserialization, allowing attackers able to submit configuration updates to specify the values of transient fields that will be deserialized, the impact depending on how those fields are used. |
| CVE-2026-17615 | High | 2026-08-31 | Protected by Waratek | No public exploit | A flaw was found in RESTEasy's SourceProvider. This vulnerability allows an unauthenticated attacker to perform an unauthenticated remote file read. By sending a specially crafted XML body with a DOCTYPE declaration referencing external entities to an endpoint that accepts application/xml and returns Source or StreamSource, the server can be tricked into resolving the entity and including sensitive file contents in the HTTP response. This is due to the SourceProvider.writeTo() method creating a SAXParser without disabling external entity resolution, leading to an XML External Entity (XXE) vulnerability. |
| CVE-2026-55848 | High | 2026-08-28 | Protected by Waratek | Proof of concept only | mapfish-print is a component of MapFish for printing templated cartographic maps. Prior to 3.28.30, 3.30.32, 3.31.24, 3.33.16, and 4.0.5, MapFish Print accepts an attacker-controlled GML layer url in requests to the /api/print3/print endpoint and fetches XML parsed by core/src/main/java/org/mapfish/print/map/geotools/GmlLayer.java without disabling external entities and external DTDs. A remote XML document and DTD can expand a local file entity, and the resulting content can be exposed through the GML parsing and error path. This allows unauthenticated attackers to read files such as operating-system account data, Kubernetes service-account tokens, and certificates. Replacing the file entity target with an internal HTTP endpoint also permits server-side request forgery. This issue is fixed in versions 3.28.30, 3.30.32, 3.31.24, 3.33.16, and 4.0.5. |
| CVE-2026-55673 | High | 2026-08-28 | Protected by Waratek | No public exploit | PowSyBl (Power System Blocks) is a framework to build power system oriented software. Prior to 7.2.2, UnixLocalCommandExecutor and WindowsLocalCommandExecutor concatenate command arguments and environment variables into strings interpreted through bash -c or cmd /c without sufficient escaping. Attacker-controlled values reaching UnixLocalCommandExecutor.execute, WindowsLocalCommandExecutor.execute, LocalComputationManager.execute, ParallelLoadFlowActionSimulator.run, ActionSimulatorTool.run, AmplModelRunner.run, or AmplModelRunner.runAsync can break out of the intended command and execute arbitrary shell commands as the JVM user. The affected itools paths include action-simulator with task-count, security-analysis with external, and dynamic-security-analysis. Downstream CLI tools, libraries, REST front ends, and multi-tenant grid-analysis services that forward less-trusted contingency identifiers or computation parameters into these APIs can expose the injection remotely. This issue is fixed in version 7.2.2. |
| CVE-2026-55552 | High | 2026-08-28 | Protected by Waratek | Working exploit published | Yamcs is a mission control framework. Prior to 5.11.13, Yamcs StaticFileHandler.locateFile resolves an unauthenticated request path without using Path.normalize and Path.toAbsolutePath to confirm that the absolute path remains within the configured staticRoots. A path containing traversal segments can escape the intended web root and return an arbitrary readable host file. The flaw is in yamcs-core/src/main/java/org/yamcs/http/StaticFileHandler.java and can disclose sensitive operating-system and application data. This issue is fixed in version 5.11.13, and the 5.12 line is fixed from version 5.12.0. |
| CVE-2026-59307 | High | 2026-08-27 | Protected by Waratek | No public exploit | An operator who calls JdbcMessageStore.addAllowedPatterns(...) to restrict deserialization receives no protection at all when the store is a Spring-managed bean. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 |
| CVE-2026-59285 | High | 2026-08-27 | Protected by Waratek | No public exploit | Spring for GraphQL applications are vulnerable to Unsafe Deserialization when processing paginated GraphQL queries. Spring for GraphQL 2.0.0 - 2.0.4 |
| CVE-2026-54550 | High | 2026-08-26 | Protected by Waratek | Proof of concept only | IzPack is a widely used tool for packaging applications on the Java platform as cross-platform installers. In 5.2.6 and earlier, UnpackerBase.unpack() in izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java obtains an attacker-controlled PackFile targetPath, passes it through IoHelper.translatePath(), which only converts separators, and constructs a File without normalizing parent-directory segments or enforcing destination containment. A malicious installer pack entry containing ../ sequences can therefore write outside the intended installation directory to startup folders, executable search paths, or other locations accessible with the victim's privileges when the victim runs the installer. |
| CVE-2026-66907 | High | 2026-08-24 | Protected by Waratek | No public exploit | Relative path traversal vulnerability in Apache Camel Google Storage component. This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + "/${file:name}". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work. Users are recommended to upgrade to version 4.22.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.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them. |
| CVE-2026-63490 | High | 2026-08-20 | Protected by Waratek | Proof of concept only | Handlebars.java provides logic-less and semantic Mustache templates with Java. Prior to 4.5.3, com.github.jknack.handlebars.springmvc.SpringTemplateLoader resolves attacker-influenced Spring MVC view names through Spring ResourceLoader without the path-containment validation used by other URL-based loaders. In handlebars-springmvc/src/main/java/com/github/jknack/handlebars/springmvc/SpringTemplateLoader.java, a view name using a file: or classpath: URL and ending with the # fragment delimiter places the appended .hbs suffix in the fragment, which FileUrlResource.exists() and URL.openStream() discard. HandlebarsViewResolver in handlebars-springmvc/src/main/java/com/github/jknack/handlebars/springmvc/HandlebarsViewResolver.java then passes the attacker-controlled name to handlebars.compile(), allowing an unauthenticated remote attacker to read files accessible to the JVM when an application exposes a controller with a user-influenced view name. This issue is fixed in version 4.5.3. |
| CVE-2026-63337 | High | 2026-08-18 | Protected by Waratek | Proof of concept only | The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, com.rabbitmq.tools.jsonrpc.ProcedureDescription receives a javaReturnType value in an untrusted system.describe response and passes it through JSONUtil.tryFill, setJavaReturnType, and computeReturnTypeAsJavaClass to Class.forName(javaReturnType) with initialization enabled. An attacker able to answer the JsonRpcClient request through a shared broker or network interception can select a class already present in the victim JVM and trigger its static initializer, while JsonRpcClient.java later passes getReturnType output to mapper.parse and may also create type confusion. Successful exploitation can affect confidentiality, integrity, and availability in the client process. This issue is fixed in version 5.33.0. |
| CVE-2026-66256 | High | 2026-08-13 | Protected by Waratek | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Deserialization of Untrusted Data vulnerability in Apache Shindig. This issue affects Apache Shindig: all versions. Users with access to the Shindig REST API can send specially-crafted requests to trigger arbitrary code execution on the server. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| CVE-2026-15555 | High | 2026-08-11 | Protected by Waratek | No public exploit | A flaw was found in JBoss marshalling. The Infinispan session replication path deserializes replicated session data via the JBoss Marshalling River unmarshaller with no class filtering — enabling RCE via deserialization gadget chains on every cluster node. |
| CVE-2026-65432 | High | 2026-08-06 | Protected by Waratek | No public exploit | Apache CXF reads a top-level WSDL through its hardened StaxUtils path, which disables XML DTDs and external entities. However, any <wsdl:import> or <xsd:import> referenced from that top-level WSDL is handed off to WSDL4J, which does not disable DOCTYPE declarations or external entities. As a result, the protections applied to the top-level document do not extend to imported documents, leaving imported WSDL/XSD content vulnerable to XML External Entity (XXE) attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue. |
| CVE-2026-3415 | High | 2026-08-06 | Protected by Waratek | No public exploit | The XML and schema validation functionalities within the SchemaValidator Mediator process XML input as part of validation flows. Under certain conditions, the XML parser allows the resolution of external entities when handling user-supplied XML content during validation operations. This behavior can occur when an attacker supplies crafted XML payloads to the relevant mediator flows with sufficient privileges. Successful exploitation may allow a highly privileged actor to read files accessible within the server hosting the affected product. Additionally, it may be possible to trigger outbound requests to unintended internal or external locations, depending on the server environment and network configuration. Specially crafted XML payloads can also lead to excessive resource consumption during parsing, impacting the availability of the product. |
| CVE-2026-70448 | High | 2026-08-05 | Protected by Waratek | No public exploit | Jenkins Ivy Report Plugin 1.2 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks when processing Ivy report files. |
| CVE-2026-46581 | High | 2026-08-05 | Protected by Waratek | No public exploit | In Eclipse Mojarra versions 2.3 and following, URL handing in `DefaultFaceletFactory` does not properly sanitize and/or block remote URLs, allowing an attacker to specify a URL to a remote Facelet which will be included and processed as part of the normal request, with the privileges of the target server. This could allow access to restricted files such as `WEB-INF/web.xml` or `/etc/passwd`. |
| CVE-2026-67340 | High | 2026-08-01 | Protected by Waratek | No public exploit | ArcadeDB before 26.7.2 (arcadedb-engine) allows trigger scripts to look up host classes in java.lang.* (via Java.type) because ScriptTriggerExecutor adds java.lang.* to the allowed packages. An authenticated user with UPDATE_SCHEMA permission can create a JavaScript trigger that invokes java.lang.Runtime.getRuntime().exec() (or ProcessBuilder), achieving OS command execution when the trigger fires. |