CWE-20 CVEs
494 CVEs, 23 exploited, 83 protected by Waratek
Overview 494 matches · 82 protected · 23 exploited · 11 CISA KEV · 46 public PoC · 30 EPSS ≥ 0.5
Protected by Waratek
83
16.8%
Rule in development
0
0.0%
Mitigation candidate
23
4.7%
No exploit published
388
78.5%
blocked by ARMR today
82
16.6%
partly blocked
1
0.2%
not blocked
411
83.2%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 138 / year
20063
Protected by Waratek2
No exploit published1
High2
Medium1
blocked by ARMR today2
not blocked1
Exploited1
No public exploit2
20074
Mitigation candidate1
No exploit published3
High2
Medium1
Low1
not blocked4
Working exploit published1
No public exploit3
20081
No exploit published1
Medium1
not blocked1
No public exploit1
20095
Mitigation candidate1
No exploit published4
High2
Medium3
not blocked5
Working exploit published1
No public exploit4
201012
Protected by Waratek1
Mitigation candidate1
No exploit published10
Critical1
High4
Medium4
Low3
blocked by ARMR today1
not blocked11
Working exploit published1
No public exploit11
201110
Mitigation candidate1
No exploit published9
High2
Medium8
not blocked10
Working exploit published1
No public exploit9
201214
Protected by Waratek1
Mitigation candidate1
No exploit published12
Critical1
High4
Medium9
blocked by ARMR today1
not blocked13
Exploited1
Working exploit published1
No public exploit12
201312
Protected by Waratek2
Mitigation candidate1
No exploit published9
Critical1
High1
Medium9
Low1
blocked by ARMR today2
not blocked10
Exploited1
Working exploit published1
Proof of concept only1
No public exploit9
201417
Protected by Waratek6
Mitigation candidate1
No exploit published10
High3
Medium14
blocked by ARMR today6
not blocked11
Exploited1
Working exploit published2
No public exploit14
201510
Protected by Waratek3
No exploit published7
High2
Medium7
Low1
blocked by ARMR today3
not blocked7
Working exploit published1
No public exploit9
201623
Protected by Waratek8
Mitigation candidate3
No exploit published12
Critical7
High12
Medium4
blocked by ARMR today8
not blocked15
Exploited1
Working exploit published3
Proof of concept only1
Forecast only1
No public exploit17
201731
Protected by Waratek6
No exploit published25
Critical8
High15
Medium8
blocked by ARMR today6
not blocked25
Exploited3
Working exploit published2
No public exploit26
201833
Protected by Waratek6
Mitigation candidate3
No exploit published24
Critical3
High15
Medium14
Low1
blocked by ARMR today6
not blocked27
Exploited3
Working exploit published3
No public exploit27
201918
Protected by Waratek3
No exploit published15
Critical4
High10
Medium2
Low2
blocked by ARMR today2
partly blocked1
not blocked15
Exploited1
No public exploit17
202026
Protected by Waratek5
Mitigation candidate4
No exploit published17
Critical4
High16
Medium5
Low1
blocked by ARMR today5
not blocked21
Exploited2
Working exploit published2
No public exploit22
202124
Protected by Waratek10
No exploit published14
Critical4
High10
Medium10
blocked by ARMR today10
not blocked14
Exploited3
No public exploit21
202227
Protected by Waratek7
No exploit published20
Critical9
High7
Medium10
Low1
blocked by ARMR today7
not blocked20
Exploited2
Proof of concept only4
No public exploit21
202328
Protected by Waratek3
Mitigation candidate1
No exploit published24
Critical5
High12
Medium10
Low1
blocked by ARMR today3
not blocked25
Working exploit published1
Proof of concept only1
No public exploit26
202433
Protected by Waratek5
Mitigation candidate2
No exploit published26
Critical3
High16
Medium13
Low1
blocked by ARMR today5
not blocked28
Exploited1
Working exploit published1
Proof of concept only3
No public exploit28
202525
Protected by Waratek5
No exploit published20
Critical3
High13
Medium6
Low3
blocked by ARMR today5
not blocked20
Proof of concept only4
No public exploit21
2026138
Protected by Waratek10
Mitigation candidate3
No exploit published125
Critical29
High58
Medium42
Low8
None1
blocked by ARMR today10
not blocked128
Exploited3
Working exploit published1
Proof of concept only9
No public exploit125
20062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-13006 | High | 2026-06-24 | No exploit published | No public exploit | ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.36 in Java applications, allows an attacker to execute arbitrary code circumventing existing protections against CVE-2025-11226 by compromising an existing logback configuration file or by injecting an environment variable before program execution. A successful attack requires the presence of Janino library to be present on the user's class path. In addition, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. Please note that in logack version 1.5.37 conditional processing using Janino was removed. |
| CVE-2025-58175 | High | 2026-06-18 | Protected by Waratek | No public exploit | GeoServer is an open source server that allows users to share and edit geospatial data. Prior to versions 2.26.4 and 2.27.3, a GeoServer that uses `ENTITY_RESOLUTION_ALLOWLIST` may allow attacker to perform unauthenticated Server-Side Request Forgery (SSRF). This vulnerability requires that GeoServer is set up to use a proxy base URL and the `ENTITY_RESOLUTION_ALLOWLIST` (default since 2.25.0). Versions 2.26.4 and 2.27.3 contain a fix. GeoServer installations are only affected by this vulnerability if they use a proxy base URL that does not contain a URL path or end with a slash. If the proxy base URL does not contain a path, adding a slash to the end of the URL will mitigate this vulnerability. |
| CVE-2026-46910 | Critical | 2026-06-17 | No exploit published | No public exploit | Vulnerability in the JD Edwards EnterpriseOne Tools product of Oracle JD Edwards (component: Enterprise Infrastructure Security). Supported versions that are affected are 9.2.0.0-9.2.26.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise JD Edwards EnterpriseOne Tools. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all JD Edwards EnterpriseOne Tools accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of JD Edwards EnterpriseOne Tools. CVSS 3.1 Base Score 9.1 (Confidentiality and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H). |
| CVE-2026-50633 | High | 2026-06-12 | Protected by Waratek | No public exploit | A JNDI Injection vulnerability has been discovered in Apache CXF's JCA integration module, which can allow for code execution, if an attacker is able to manipulate the JCA deployment descriptor (ra.xml) or runtime activation parameters. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue. |
| CVE-2026-50632 | High | 2026-06-12 | Protected by Waratek | No public exploit | A further incomplete fix for a previous advisory CVE-2026-44417 (Untrusted JMS configuration can lead to RCE) for Apache CXF has been identified, which can allow code execution capabilities, if untrusted users are allowed to configure JMS for Apache CXF. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue. |
| CVE-2026-50628 | Critical | 2026-06-12 | No exploit published | No public exploit | A logic error in OAuthRequestFilter rejects legitimate requests originating from the bound IP address, while blindly allowing requests from any other IP address. Enabling this security feature inadvertently creates an inverse security check. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue. |
| CVE-2026-41727 | Medium | 2026-06-10 | No exploit published | No public exploit | Spring Kafka's retry topic infrastructure did not sufficiently validate user-controlled header values before acting on them. A producer could send a record with a crafted retry_topic-attempts header to supply an out-of-range attempt count and cause the retry topic router to misidentify where the message was in the retry sequence. Affected versions: Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11. |
| CVE-2026-45505 | High | 2026-06-01 | No exploit published | No public exploit | Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ. Non-parenthesized discovery wrappers such as `masterslave:vm://...,...` and `static:vm://...` incorrectly pass validation allowing bypass of fix in CVE-2026-34197. Original description from CVE-2026-34197. Apache ActiveMQ exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). An authenticated attacker can invoke these operations with a crafted discovery UR that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ Broker: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ All: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6. Users are recommended to upgrade to version 5.19.7 or 6.2.6, which fixes the issue. |
| CVE-2026-42588 | High | 2026-06-01 | Mitigation candidate | Proof of concept only | Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ. Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including BrokerService.addNetworkConnector(String). An authenticated attacker can invoke these operations with a crafted discovery URI that triggers the VM transport's brokerConfig parameter using the "masterslave:// " URL which can allow loading a Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ Broker: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ All: before 5.19.7, from 6.0.0 before 6.2.6; Apache ActiveMQ: before 5.19.7, from 6.0.0 before 6.2.6. Users are recommended to upgrade to version 5.19.7 or 6.2.6, which fixes the issue. |
| CVE-2026-48922 | High | 2026-05-27 | Protected by Waratek | No public exploit | Jenkins Credentials Binding Plugin 720.v3f6decef43ea_ and earlier does not properly sanitize file names for file and zip file credentials, allowing attackers able to provide credentials to a job to write files to arbitrary locations on the node filesystem, which can lead to remote code execution if Jenkins is configured to allow a low-privileged user to configure file or zip file credentials used for a job running on the built-in node. |
| CVE-2026-9497 | Low | 2026-05-25 | No exploit published | No public exploit | A flaw has been found in changmingxie tcc-transaction up to 2.1.0. This issue affects the function Fastjson.parseObject of the component Fastjson AutoType REST API. This manipulation causes deserialization. It is possible to initiate the attack remotely. The vendor was contacted early about this disclosure but did not respond in any way. |
| CVE-2026-44417 | High | 2026-05-22 | No exploit published | No public exploit | The fix for CVE-2025-48913: Apache CXF: Untrusted JMS configuration can lead to RCE was not complete, meaning that another path in the code might lead to code execution capabilities, if untrusted users are allowed to configure JMS for Apache CXF. Users are recommended to upgrade to versions 4.2.1, 4.1.6 or 3.6.11, which fix this issue. |
| CVE-2026-8759 | Medium | 2026-05-17 | No exploit published | Proof of concept only | A vulnerability was identified in xiandafu beetl up to 3.20.2. Affected is an unknown function of the file beetl-classic-integration/beetl-spring-classic/src/main/java/org/beetl/ext/spring/SpELFunction.java of the component SpELFunction. The manipulation leads to improper neutralization of special elements used in an expression language statement. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet. |
| CVE-2026-42579 | Critical | 2026-05-13 | No exploit published | Proof of concept only | Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's DNS codec does not enforce RFC 1035 domain name constraints during either encoding or decoding. This creates a bidirectional attack surface: malicious DNS responses can exploit the decoder, and user-influenced hostnames can exploit the encoder. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final. |
| CVE-2026-41293 | Critical | 2026-05-12 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.21, from 10.1.0-M1 through 10.1.54, from 9.0.0.M1 through 9.0.117, from 10.0.0-M1 through 10.0.27. Older, end of support versions may also be affected. Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue. |
| CVE-2026-42812 | Critical | 2026-05-04 | No exploit published | No public exploit | In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read. `write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations. The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target. `allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite. In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs. If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area. That attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there. The practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location. So the core issue is not only later credential vending. The primary defect is that Polaris skips its intended location checks before performing a security- sensitive metadata write when only `write.metadata.path` changes. When `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes. |
| CVE-2026-42811 | Critical | 2026-05-04 | No exploit published | No public exploit | In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials that only work for one table's files, but a crafted namespace or table name can cause those credentials to work across the configured bucket instead. Apache Polaris builds Google Cloud Storage downscoped credentials by creating a Credential Access Boundary (CAB) with CEL conditions that are intended to restrict access to the requested table's storage path. The relevant CEL string is built from the bucket name and the table path. That table path is derived from namespace and table identifiers. In current code, that path appears to be inserted into the CEL expression without escaping. As a result, a namespace or table identifier containing a single quote and other URI-safe CEL fragments can break out of the intended quoted string and change the meaning of the CEL condition. In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated GCS credentials whose CEL path restriction had effectively collapsed. Those delegated credentials could then: - list another table's object prefix; - read another table's metadata control file (Iceberg metadata JSON); - create and delete an object under another table's object prefix; - and also list, read, create, and delete objects under an unrelated external prefix in the same bucket that was not part of any table path. That last point is important. The issue is not limited to "another table". In the confirmed setup, once Apache Polaris returned credentials for the crafted table, the path restriction inside the configured bucket was effectively gone. The practical effect is that temporary credentials for one crafted table can be broader than the table Polaris was asked to authorize, and can become effectively bucket-wide within the configured bucket. The current GCS testing used a Polaris principal with broad catalog privileges for setup. A separate least-privilege Polaris RBAC variant has not yet been tested on GCS. However, the storage-credential broadening behavior itself has been confirmed on GCS. |
| CVE-2026-42810 | Critical | 2026-05-04 | No exploit published | No public exploit | Apache Polaris accepts literal `*` characters in namespace and table names. When it later builds temporary S3 access policies for delegated table access, those same characters appear to be reused unescaped in S3 IAM resource patterns and `s3:prefix` conditions. In S3 IAM policy matching, `*` is treated as a wildcard rather than as ordinary text. That means temporary credentials issued for one crafted table can match the storage path of a different table. In private testing against Polaris 1.4.0 using Polaris' AWS S3 temporary- credential path on both MinIO and real AWS S3, credentials returned for crafted tables such as `f*.t1`, `f*.*`, `*.*`, and `foo.*` could reach other tables' S3 locations. The confirmed behavior includes: - reading another table's metadata control file ([Iceberg metadata JSON]); - listing another table's exact S3 table prefix ([table prefix]); - and, when write delegation was returned for the crafted table, creating and deleting an object under another table's exact S3 table prefix. A control case using ordinary different names did not allow the same cross-table access. A least-privilege AWS S3 variant was also confirmed in which the attacker principal had no Polaris permissions on the victim table and only the minimal permissions required to create and use a crafted wildcard table (namespace-scoped `TABLE_CREATE` and `TABLE_WRITE_DATA` on `*`). In that setup, direct Polaris access to `foo.t1` remained forbidden, but the attacker could still create and load `*.*`, receive delegated S3 credentials, and use those credentials to list, read, create, and delete objects under `foo.t1`. In Iceberg, the metadata JSON file is a control file: it tells readers which data files belong to the table, which snapshots exist, and which table version to read. So unauthorized access to it is already a meaningful confidentiality problem. The confirmed write-capable variant means the issue is not limited to disclosure. |
| CVE-2026-42809 | Critical | 2026-05-04 | No exploit published | No public exploit | Apache Polaris can issue broad temporary ("vended") storage credentials during staged table creation before the effective table location has been validated or durably reserved. Those temporary credentials are meant to limit the scope of accessible table data and metadata, but this scope limitation becomes attacker- directed because the attacker can choose a reachable target location. In the confirmed variant, if the caller supplies a custom `location` during stage create and requests credential vending, Apache Polaris uses that location to construct delegated storage credentials immediately. The stage-create path itself neither runs the normal location validation nor the overlap checks before those credentials are issued. Closely related to that, the staged-create flow also accepts `write.data.path` / `write.metadata.path` in the request properties and feeds those location overrides into the same effective table location set used for credential vending. Those fields are secondary to the main custom-`location` exploit, but they are still attacker-influenced location inputs that should be validated before any credentials are issued. |
| CVE-2026-41044 | High | 2026-04-24 | No exploit published | No public exploit | Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ, Apache ActiveMQ Broker, Apache ActiveMQ All. An authenticated attacker can use the admin web console page to construct a malicious broker name that bypasses name validation to include an xbean binding that can be later used by a VM transport to load a remote Spring XML application. The attacker can then use the DestinationView mbean to send a message to trigger a VM transport creation that will reference this malicious broker name which can lead to loading the malicious Spring XML context file. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5. Users are recommended to upgrade to version 6.2.5 or 5.19.6, which fixes the issue. |
| CVE-2026-40466 | High | 2026-04-24 | Mitigation candidate | Exploited | Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ. An authenticated attacker may bypass the fix in CVE-2026-34197 by adding a connector using an HTTP Discovery transport via BrokerView.addNetworkConnector or BrokerView.addConnector through Jolokia if the activemq-http module is on the classpath. A malicious HTTP endpoint can return a VM transport through the HTTP URI which will bypass the validation added in CVE-2026-34197. The attacker can then use the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ Broker: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ All: before 5.19.6, from 6.0.0 before 6.2.5; Apache ActiveMQ: before 5.19.6, from 6.0.0 before 6.2.5. Users are recommended to upgrade to version 5.19.6 or 6.2.5, which fixes the issue. |
| CVE-2026-22748 | Medium | 2026-04-22 | No exploit published | No public exploit | Vulnerability in Spring Spring Security. When an application configures JWT decoding with NimbusJwtDecoder or NimbusReactiveJwtDecoder, it must configure an OAuth2TokenValidator<Jwt> separately, for example by calling setJwtValidator.This issue affects Spring Security: from 6.3.0 through 6.3.14, from 6.4.0 through 6.4.14, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4. |
| CVE-2026-32604 | Critical | 2026-04-20 | No exploit published | No public exploit | Spinnaker is an open source, multi-cloud continuous delivery platform. In versions prior to 2026.1.0, 2026.0.1, 2025.4.2, and 2025.3.2, a bad actor can execute arbitrary commands very simply on the clouddriver pods. This can expose credentials, remove files, or inject resources easily. Versions 2026.1.0, 2026.0.1, 2025.4.2, and 2025.3.2 contain a patch. As a workaround, disable the gitrepo artifact types. |
| CVE-2026-32990 | Medium | 2026-04-09 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Tomcat due to an incomplete fix of CVE-2025-66614. This issue affects Apache Tomcat: from 11.0.15 through 11.0.19, from 10.1.50 through 10.1.52, from 9.0.113 through 9.0.115. Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue. |
| CVE-2026-34197 | High | 2026-04-07 | Protected by Waratek | Exploited | Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ. Apache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including BrokerService.addNetworkConnector(String) and BrokerService.addConnector(String). An authenticated attacker can invoke these operations with a crafted discovery URI that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext. Because Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec(). This issue affects Apache ActiveMQ Broker: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ All: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ: before 5.19.4, from 6.0.0 before 6.2.3. Users are recommended to upgrade to version 5.19.4 or 6.2.3, which fixes the issue |
| CVE-2025-60012 | Medium | 2026-03-13 | No exploit published | No public exploit | Malicious configuration can lead to unauthorized file access in Apache Livy. This issue affects Apache Livy 0.7.0 and 0.8.0 when connecting to Apache Spark 3.1 or later. A request that includes a Spark configuration value supported from Apache Spark version 3.1 can lead to users gaining access to files they do not have permissions to. For the vulnerability to be exploitable, the user needs to have access to Apache Livy's REST or JDBC interface and be able to send requests with arbitrary Spark configuration values. Users are recommended to upgrade to version 0.9.0 or later, which fixes the issue. |
| CVE-2026-24713 | Critical | 2026-03-09 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache IoTDB. This issue affects Apache IoTDB: from 1.0.0 before 1.3.7, from 2.0.0 before 2.0.7. Users are recommended to upgrade to version 1.3.7 or 2.0.7, which fixes the issue. |
| CVE-2025-11143 | Medium | 2026-03-05 | No exploit published | No public exploit | The Jetty URI parser has some key differences to other common parsers when evaluating invalid or unusual URIs. Differential parsing of URIs in systems using multiple components may result in security by-pass. For example a component that enforces a black list may interpret the URIs differently from one that generates a response. At the very least, differential parsing may divulge implementation details. |
| CVE-2026-24734 | High | 2026-02-17 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Tomcat Native, Apache Tomcat. When using an OCSP responder, Tomcat Native (and Tomcat's FFM port of the Tomcat Native code) did not complete verification or freshness checks on the OCSP response which could allow certificate revocation to be bypassed. This issue affects Apache Tomcat Native: from 1.3.0 through 1.3.4, from 2.0.0 through 2.0.11; Apache Tomcat: from 11.0.0-M1 through 11.0.17, from 10.1.0-M7 through 10.1.51, from 9.0.83 through 9.0.114. The following versions were EOL at the time the CVE was created but are known to be affected: from 1.1.23 through 1.1.34, from 1.2.0 through 1.2.39. Older EOL versions are not affected. Apache Tomcat Native users are recommended to upgrade to versions 1.3.5 or later or 2.0.12 or later, which fix the issue. Apache Tomcat users are recommended to upgrade to versions 11.0.18 or later, 10.1.52 or later or 9.0.115 or later which fix the issue. |
| CVE-2026-24733 | Medium | 2026-02-17 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Tomcat. Tomcat did not limit HTTP/0.9 requests to the GET method. If a security constraint was configured to allow HEAD requests to a URI but deny GET requests, the user could bypass that constraint on GET requests by sending a (specification invalid) HEAD request using HTTP/0.9. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0.M1 through 9.0.112. Older, EOL versions are also affected. Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fixes the issue. |
| CVE-2025-66614 | Critical | 2026-02-17 | No exploit published | No public exploit | Improper Input Validation vulnerability. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected. Tomcat did not validate that the host name provided via the SNI extension was the same as the host name provided in the HTTP host header field. If Tomcat was configured with more than one virtual host and the TLS configuration for one of those hosts did not require client certificate authentication but another one did, it was possible for a client to bypass the client certificate authentication by sending different host names in the SNI extension and the HTTP host header field. The vulnerability only applies if client certificate authentication is only enforced at the Connector. It does not apply if client certificate authentication is enforced at the web application. Users are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue. |
| CVE-2024-4027 | High | 2026-01-30 | No exploit published | No public exploit | A flaw was found in Undertow. Servlets using a method that calls HttpServletRequestImpl.getParameterNames() can cause an OutOfMemoryError when the client sends a request with large parameter names. This issue can be exploited by an unauthorized user to cause a remote denial-of-service (DoS) attack. |
| CVE-2026-1225 | Low | 2026-01-22 | No exploit published | No public exploit | ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file. The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado. |
| CVE-2026-22444 | High | 2026-01-21 | No exploit published | No public exploit | The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element . These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes. Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users. This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles. Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores. Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue. |
| CVE-2025-29847 | High | 2026-01-19 | Protected by Waratek | No public exploit | A vulnerability in Apache Linkis. Problem Description When using the JDBC engine and da When using the JDBC engine and data source functionality, if the URL parameter configured on the frontend has undergone multiple rounds of URL encoding, it may bypass the system's checks. This bypass can trigger a vulnerability that allows unauthorized access to system files via JDBC parameters. Scope of Impact This issue affects Apache Linkis: from 1.3.0 through 1.7.0. Severity level moderate Solution Continuously check if the connection information contains the "%" character; if it does, perform URL decoding. Users are recommended to upgrade to version 1.8.0, which fixes the issue. More questions about this vulnerability can be discussed here: https://lists.apache.org/list?dev@linkis.apache.org:2025-9:cve |
| CVE-2026-0976 | Low | 2026-01-15 | No exploit published | No public exploit | A flaw was found in Keycloak. This improper input validation vulnerability occurs because Keycloak accepts RFC-compliant matrix parameters in URL path segments, while common reverse proxy configurations may ignore or mishandle them. A remote attacker can craft requests to mask path segments, potentially bypassing proxy-level path filtering. This could expose administrative or sensitive endpoints that operators believe are not externally reachable. |
| CVE-2025-12543 | Critical | 2026-01-07 | No exploit published | Proof of concept only | 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. |
| CVE-2025-61916 | High | 2026-01-05 | No exploit published | No public exploit | Spinnaker is an open source, multi-cloud continuous delivery platform. Versions prior to 2025.1.6, 2025.2.3, and 2025.3.0 are vulnerable to server-side request forgery. The primary impact is allowing users to fetch data from a remote URL. This data can be then injected into spinnaker pipelines via helm or other methods to extract things LIKE idmsv1 authentication data. This also includes calling internal spinnaker API's via a get and similar endpoints. Further, depending upon the artifact in question, auth data may be exposed to arbitrary endpoints (e.g. GitHub auth headers) leading to credentials exposure. To trigger this, a spinnaker installation MUST have two things. The first is an artifact enabled that allows user input. This includes GitHub file artifacts, BitBucket, GitLab, HTTP artifacts and similar artifact providers. JUST enabling the http artifact provider will add a "no-auth" http provider that could be used to extract link local data (e.g. AWS Metadata information). The second is a system that can consume the output of these artifacts. e.g. Rosco helm can use this to fetch values data. K8s account manifests if the API returns JSON can be used to inject that data into the pipeline itself though the pipeline would fail. This vulnerability is fixed in versions 2025.1.6, 2025.2.3, and 2025.3.0. As a workaround, disable HTTP account types that allow user input of a given URL. This is probably not feasible in most cases. Git, Docker and other artifact account types with explicit URL configurations bypass this limitation and should be safe as they limit artifact URL loading. Alternatively, use one of the various vendors which provide OPA policies to restrict pipelines from accessing or saving a pipeline with invalid URLs. |
| CVE-2024-3884 | High | 2025-12-03 | No exploit published | No public exploit | A flaw was found in Undertow that can cause remote denial of service attacks. When the server uses the FormEncodedDataDefinition.doParse(StreamSourceChannel) method to parse large form data encoding with application/x-www-form-urlencoded, the method will cause an OutOfMemory issue. This flaw allows unauthorized users to cause a remote denial of service (DoS) attack. |
| CVE-2025-13805 | Low | 2025-12-01 | Protected by Waratek | Proof of concept only | A weakness has been identified in nutzam NutzBoot up to 2.6.0-SNAPSHOT. This affects the function getInputStream of the file nutzcloud/nutzcloud-literpc/src/main/java/org/nutz/boot/starter/literpc/impl/endpoint/http/HttpServletRpcEndpoint.java of the component LiteRpc-Serializer. Executing a manipulation can lead to deserialization. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit has been made available to the public and could be used for attacks. |
| CVE-2025-59250 | High | 2025-10-14 | No exploit published | No public exploit | Improper input validation in JDBC Driver for SQL Server allows an unauthorized attacker to perform spoofing over a network. |
| CVE-2025-11226 | High | 2025-10-01 | No exploit published | No public exploit | ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. |
| CVE-2025-59952 | High | 2025-09-30 | Protected by Waratek | No public exploit | MinIO Java SDK is a Simple Storage Service (aka S3) client to perform bucket and object operations to any Amazon S3 compatible object storage service. In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources. This is fixed in version 8.6.0. |
| CVE-2025-48392 | High | 2025-09-24 | No exploit published | No public exploit | A vulnerability in Apache IoTDB. This issue affects Apache IoTDB: from 1.3.3 through 1.3.4, from 2.0.1-beta through 2.0.4. Users are recommended to upgrade to version 2.0.5, which fixes the issue. |
| CVE-2025-9467 | Medium | 2025-09-04 | No exploit published | No public exploit | When the Vaadin Upload's start listener is used to validate metadata about an incoming upload, it is possible to bypass the upload validation. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin 7.0.0 - 7.7.47 Vaadin 8.0.0 - 8.28.1 Vaadin 14.0.0 - 14.13.0 Vaadin 23.0.0 - 23.6.1 Vaadin 24.0.0 - 24.7.6 Mitigation Upgrade to 7.7.48 Upgrade to 8.28.2 Upgrade to 14.13.1 Upgrade to 23.6.2 Upgrade to 24.7.7 or newer Please note that Vaadin versions 10-13 and 15-22 are no longer supported and you should update either to the latest 14, 23, 24 version. Artifacts Maven coordinatesVulnerable versionsFixed versioncom.vaadin:vaadin-server 7.0.0 - 7.7.47 ≥7.7.48 com.vaadin:vaadin-server 8.0.0 - 8.28.1 ≥8.28.2 com.vaadin:vaadin 14.0.0 - 14.13.0 ≥14.13.1 com.vaadin:vaadin23.0.0 - 23.6.1 ≥23.6.2 com.vaadin:vaadin24.0.0 - 24.7.6 ≥24.7.7com.vaadin:vaadin-upload-flow 2.0.0 - 14.13.0 ≥14.13.1 com.vaadin:vaadin-upload-flow 23.0.0 - 23.6.1 ≥23.6.2 com.vaadin:vaadin-upload-flow 24.0.0 - 24.7.6 ≥24.7.7 |
| CVE-2024-43115 | High | 2025-09-03 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache DolphinScheduler. An authenticated user can execute any shell script server by alert script. This issue affects Apache DolphinScheduler: before 3.2.2. Users are recommended to upgrade to version 3.3.1, which fixes the issue. |
| CVE-2025-46047 | Medium | 2025-09-02 | No exploit published | Proof of concept only | A User enumeration vulnerability in the /CredentialsServlet/ForgotPassword endpoint in Silverpeas 6.4.1 and 6.4.2 allows remote attackers to determine valid usernames via the Login parameter. |
| CVE-2025-48913 | Critical | 2025-08-08 | No exploit published | No public exploit | If untrusted users are allowed to configure JMS for Apache CXF, previously they could use RMI or LDAP URLs, potentially leading to code execution capabilities. This interface is now restricted to reject those protocols, removing this possibility. Users are recommended to upgrade to versions 3.6.8, 4.0.9 or 4.1.3, which fix this issue. |
| CVE-2024-52279 | High | 2025-08-03 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin. The fix for JDBC URL validation in CVE-2024-31864 did not account for URL encoded input. This issue affects Apache Zeppelin: from 0.11.1 before 0.12.0. Users are recommended to upgrade to version 0.12.0, which fixes the issue. |
| CVE-2025-54385 | High | 2025-07-26 | Protected by Waratek | No public exploit | XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions between 17.0.0-rc1 to 17.2.2 and versions 16.10.5 and below, it's possible to execute any SQL query in Oracle by using the function like DBMS_XMLGEN or DBMS_XMLQUERY. The XWiki#searchDocuments APIs pass queries directly to Hibernate without sanitization. Even when these APIs enforce a specific SELECT clause, attackers can still inject malicious code through HQL's native function support in other parts of the query (such as the WHERE clause). This is fixed in versions 16.10.6 and 17.3.0-rc-1. |
| CVE-2025-50151 | High | 2025-07-21 | No exploit published | No public exploit | File access paths in configuration files uploaded by users with administrator access are not validated. This issue affects Apache Jena version up to 5.4.0. Users are recommended to upgrade to version 5.5.0, which does not allow arbitrary configuration upload. |
| CVE-2025-53652 | High | 2025-07-09 | No exploit published | No public exploit | Jenkins Git Parameter Plugin 439.vb_0e46ca_14534 and earlier does not validate that the Git parameter value submitted to the build matches one of the offered choices, allowing attackers with Item/Build permission to inject arbitrary values into Git parameters. |
| CVE-2024-34711 | Critical | 2025-06-10 | Protected by Waratek | No public exploit | GeoServer is an open source server that allows users to share and edit geospatial data. An improper URI validation vulnerability exists that enables an unauthorized attacker to perform XML External Entities (XEE) attack, then send GET request to any HTTP server. By default, GeoServer use PreventLocalEntityResolver class from GeoTools to filter out malicious URIs in XML entities before resolving them. The URI must match the regex (?i)(jar:file|http|vfs)[^?#;]*\\.xsd. But the regex leaves a chance for attackers to request to any HTTP server or limited file. Attacker can abuse this to scan internal networks and gain information about them then exploit further. GeoServer 2.25.0 and greater default to the use of ENTITY_RESOLUTION_ALLOWLIST and does not require you to provide a system property. |
| CVE-2025-22233 | Low | 2025-05-16 | No exploit published | No public exploit | CVE-2024-38820 ensured Locale-independent, lowercase conversion for both the configured disallowedFields patterns and for request parameter names. However, there are still cases where it is possible to bypass the disallowedFields checks. Affected Spring Products and Versions Spring Framework: * 6.2.0 - 6.2.6 * 6.1.0 - 6.1.19 * 6.0.0 - 6.0.27 * 5.3.0 - 5.3.42 * Older, unsupported versions are also affected Mitigation Users of affected versions should upgrade to the corresponding fixed version. Affected version(s)Fix Version Availability 6.2.x 6.2.7 OSS6.1.x 6.1.20 OSS6.0.x 6.0.28 Commercial https://enterprise.spring.io/ 5.3.x 5.3.43 Commercial https://enterprise.spring.io/ No further mitigation steps are necessary. Generally, we recommend using a dedicated model object with properties only for data binding, or using constructor binding since constructor arguments explicitly declare what to bind together with turning off setter binding through the declarativeBinding flag. See the Model Design section in the reference documentation. For setting binding, prefer the use of allowedFields (an explicit list) over disallowedFields. Credit This issue was responsibly reported by the TERASOLUNA Framework Development Team from NTT DATA Group Corporation. |
| CVE-2025-47888 | Medium | 2025-05-14 | No exploit published | No public exploit | Jenkins DingTalk Plugin 2.7.3 and earlier unconditionally disables SSL/TLS certificate and hostname validation for connections to the configured DingTalk webhooks. |
| CVE-2025-22235 | High | 2025-04-28 | No exploit published | No public exploit | EndpointRequest.to() creates a matcher for null/** if the actuator endpoint, for which the EndpointRequest has been created, is disabled or not exposed. Your application may be affected by this if all the following conditions are met: * You use Spring Security * EndpointRequest.to() has been used in a Spring Security chain configuration * The endpoint which EndpointRequest references is disabled or not exposed via web * Your application handles requests to /null and this path needs protection You are not affected if any of the following is true: * You don't use Spring Security * You don't use EndpointRequest.to() * The endpoint which EndpointRequest.to() refers to is enabled and is exposed * Your application does not handle requests to /null or this path does not need protection |
| CVE-2025-31672 | Medium | 2025-04-09 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache POI. The issue affects the parsing of OOXML format files like xlsx, docx and pptx. These file formats are basically zip files and it is possible for malicious users to add zip entries with duplicate names (including the path) in the zip. In this case, products reading the affected file could read different data because 1 of the zip entries with the duplicate name is selected over another but different products may choose a different zip entry. This issue affects Apache POI poi-ooxml before 5.4.0. poi-ooxml 5.4.0 has a check that throws an exception if zip entries with duplicate file names are found in the input file. Users are recommended to upgrade to version poi-ooxml 5.4.0, which fixes the issue. Please read https://poi.apache.org/security.html for recommendations about how to use the POI libraries securely. |
| CVE-2025-2622 | Medium | 2025-03-22 | Protected by Waratek | Proof of concept only | A vulnerability was found in aizuda snail-job 1.4.0. It has been classified as critical. Affected is the function getRuntime of the file /snail-job/workflow/check-node-expression of the component Workflow-Task Management Module. The manipulation of the argument nodeExpression leads to deserialization. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. |
| CVE-2024-4028 | Low | 2025-02-18 | No exploit published | No public exploit | A vulnerability was found in Keycloak. This issue may allow a privileged attacker to use a malicious payload as the permission while creating items (Resource and Permissions) from the admin console, leading to a stored cross-site scripting (XSS) attack. |
| CVE-2025-24970 | High | 2025-02-10 | No exploit published | Proof of concept only | Netty, an asynchronous, event-driven network application framework, has a vulnerability starting in version 4.1.91.Final and prior to version 4.1.118.Final. When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. Version 4.1.118.Final contains a patch. As workaround its possible to either disable the usage of the native SSLEngine or change the code manually. |
| CVE-2024-37358 | High | 2025-02-06 | No exploit published | No public exploit | Similarly to CVE-2024-34055, Apache James is vulnerable to denial of service through the abuse of IMAP literals from both authenticated and unauthenticated users, which could be used to cause unbounded memory allocation and very long computations Version 3.7.6 and 3.8.2 restrict such illegitimate use of IMAP literals. |
| CVE-2024-45479 | Critical | 2025-01-21 | No exploit published | No public exploit | SSRF vulnerability in Edit Service Page of Apache Ranger UI in Apache Ranger Version 2.4.0. Users are recommended to upgrade to version Apache Ranger 2.5.0, which fixes this issue. |
| CVE-2024-45478 | Medium | 2025-01-21 | No exploit published | No public exploit | Stored XSS vulnerability in Edit Service Page of Apache Ranger UI in Apache Ranger Version 2.4.0. Users are recommended to upgrade to version Apache Ranger 2.5.0, which fixes this issue. |
| CVE-2024-45761 | High | 2024-12-09 | Protected by Waratek | No public exploit | Dell OpenManage Server Administrator, versions 11.0.1.0 and prior, contains an improper input validation vulnerability. A remote low-privileged malicious user could potentially exploit this vulnerability to load any web plugins or Java class leading to the possibility of altering the behavior of certain apps/OS or Denial of Service. |
| CVE-2024-54140 | Low | 2024-12-05 | No exploit published | Proof of concept only | sigstore-java is a sigstore java client for interacting with sigstore infrastructure. sigstore-java has insufficient verification for a situation where a bundle provides a invalid signature for a checkpoint. This bug impacts clients using any variation of KeylessVerifier.verify(). Currently checkpoints are only used to ensure the root hash of an inclusion proof was provided by the log in question. Failing to validate that means a bundle may provide an inclusion proof that doesn't actually correspond to the log in question. This may eventually lead a monitor/witness being unable to detect when a compromised logs are providing different views of themselves to different clients. There are other mechanisms right now that mitigate this, such as the signed entry timestamp. Sigstore-java currently requires a valid signed entry timestamp. By correctly verifying the signed entry timestamp we can make certain assertions about the log signing the log entry (like the log was aware of the artifact signing event and signed it). Therefore the impact on clients that are not monitors/witnesses is very low. This vulnerability is fixed in 1.2.0. |
| CVE-2022-2232 | High | 2024-11-14 | No exploit published | No public exploit | A flaw was found in the Keycloak package. This flaw allows an attacker to utilize an LDAP injection to bypass the username lookup or potentially perform other malicious actions. |
| CVE-2023-1973 | High | 2024-11-07 | No exploit published | No public exploit | A flaw was found in Undertow package. Using the FormAuthenticationMechanism, a malicious user could trigger a Denial of Service by sending crafted requests, leading the server to an OutofMemory error, exhausting the server's memory. |
| CVE-2024-45031 | Medium | 2024-10-24 | No exploit published | No public exploit | When editing objects in the Syncope Console, incomplete HTML tags could be used to bypass HTML sanitization. This made it possible to inject stored XSS payloads which would trigger for other users during ordinary usage of the application. XSS payloads could also be injected in Syncope Enduser when editing “Personal Information” or “User Requests”: such payloads would trigger for administrators in Syncope Console, thus enabling session hijacking. Users are recommended to upgrade to version 3.0.9, which fixes this issue. |
| CVE-2024-7254 | High | 2024-09-19 | No exploit published | No public exploit | Any project that parses untrusted Protocol Buffers data containing an arbitrary number of nested groups / series of SGROUP tags can corrupted by exceeding the stack limit i.e. StackOverflow. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. |
| CVE-2024-45537 | Medium | 2024-09-17 | No exploit published | No public exploit | Apache Druid allows users with certain permissions to read data from other database systems using JDBC. This functionality allows trusted users to set up Druid lookups or run ingestion tasks. Druid also allows administrators to configure a list of allowed properties that users are able to provide for their JDBC connections. By default, this allowed properties list restricts users to TLS-related properties only. However, when configuration a MySQL JDBC connection, users can use a particularly-crafted JDBC connection string to provide properties that are not on this allow list. Users without the permission to configure JDBC connections are not able to exploit this vulnerability. CVE-2021-26919 describes a similar vulnerability which was partially addressed in Apache Druid 0.20.2. This issue is fixed in Apache Druid 30.0.1. |
| CVE-2024-30188 | High | 2024-08-12 | Mitigation candidate | Working exploit published | File read and write vulnerability in Apache DolphinScheduler , authenticated users can illegally access additional resource files. This issue affects Apache DolphinScheduler: from 3.1.0 before 3.2.2. Users are recommended to upgrade to version 3.2.2, which fixes the issue. |
| CVE-2024-29831 | High | 2024-08-12 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache DolphinScheduler. An authenticated user can cause arbitrary, unsandboxed javascript to be executed on the server. If you are using the switch task plugin, please upgrade to version 3.2.2. |
| CVE-2024-38503 | Medium | 2024-07-22 | No exploit published | No public exploit | When editing a user, group or any object in the Syncope Console, HTML tags could be added to any text field and could lead to potential exploits. The same vulnerability was found in the Syncope Enduser, when editing “Personal Information” or “User Requests”. Users are recommended to upgrade to version 3.0.8, which fixes this issue. |
| CVE-2024-32007 | High | 2024-07-19 | No exploit published | No public exploit | An improper input validation of the p2c parameter in the Apache CXF JOSE code before 4.0.5, 3.6.4 and 3.5.9 allows an attacker to perform a denial of service attack by specifying a large value for this parameter in a token. |
| CVE-2024-40642 | High | 2024-07-18 | No exploit published | No public exploit | The netty incubator codec.bhttp is a java language binary http parser. In affected versions the `BinaryHttpParser` class does not properly validate input values thus giving attackers almost complete control over the HTTP requests constructed from the parsed output. Attackers can abuse several issues individually to perform various injection attacks including HTTP request smuggling, desync attacks, HTTP header injections, request queue poisoning, caching attacks and Server Side Request Forgery (SSRF). Attacker could also combine several issues to create well-formed messages for other text-based protocols which may result in attacks beyond the HTTP protocol. The BinaryHttpParser class implements the readRequestHead method which performs most of the relevant parsing of the received request. The data structure prefixes values with a variable length integer value. The parsing code below first gets the lengths of the values from the prefixed variable length integer. After it has all of the lengths and calculates all of the indices, the parser casts the applicable slices of the ByteBuf to String. Finally, it passes these values into a new `DefaultBinaryHttpRequest` object where no further parsing or validation occurs. Method is partially validated while other values are not validated at all. Software that relies on netty to apply input validation for binary HTTP data may be vulnerable to various injection and protocol based attacks. This issue has been addressed in version 0.0.13.Final. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CVE-2024-22271 | High | 2024-07-09 | No exploit published | No public exploit | In Spring Cloud Function framework, versions 4.1.x prior to 4.1.2, 4.0.x prior to 4.0.8 an application is vulnerable to a DOS attack when attempting to compose functions with non-existing functions. Specifically, an application is vulnerable when all of the following are true: User is using Spring Cloud Function Web module Affected Spring Products and Versions Spring Cloud Function Framework 4.1.0 to 4.1.2 4.0.0 to 4.0.8 References https://spring.io/security/cve-2022-22979 https://checkmarx.com/blog/spring-function-cloud-dos-cve-2022-22979-and-unintended-function-invocation/ History 2020-01-16: Initial vulnerability report published. |
| CVE-2024-5276 | Critical | 2024-06-25 | Protected by Waratek | Exploited | A SQL Injection vulnerability in Fortra FileCatalyst Workflow allows an attacker to modify application data. Likely impacts include creation of administrative users and deletion or modification of data in the application database. Data exfiltration via SQL injection is not possible using this vulnerability. Successful unauthenticated exploitation requires a Workflow system with anonymous access enabled, otherwise an authenticated user is required. This issue affects all versions of FileCatalyst Workflow from 5.1.6 Build 135 and earlier. |
| CVE-2024-34365 | Critical | 2024-05-14 | No exploit published | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Karaf Cave.This issue affects all versions of Apache Karaf Cave. 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-2023-6717 | Medium | 2024-04-25 | No exploit published | No public exploit | A flaw was found in the SAML client registration in Keycloak that could allow an administrator to register malicious JavaScript URIs as Assertion Consumer Service POST Binding URLs (ACS), posing a Cross-Site Scripting (XSS) risk. This issue may allow a malicious admin in one realm or a client with registration access to target users in different realms or applications, executing arbitrary JavaScript in their contexts upon form submission. This can enable unauthorized access and harmful actions, compromising the confidentiality, integrity, and availability of the complete KC instance. |
| CVE-2024-31867 | Medium | 2024-04-09 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin. The attackers can execute malicious queries by setting improper configuration properties to LDAP search filter. This issue affects Apache Zeppelin: from 0.8.2 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue. |
| CVE-2024-31865 | Medium | 2024-04-09 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin. The attackers can call updating cron API with invalid or improper privileges so that the notebook can run with the privileges. This issue affects Apache Zeppelin: from 0.8.2 before 0.11.1. Users are recommended to upgrade to version 0.11.1, which fixes the issue. |
| CVE-2024-31862 | Medium | 2024-04-09 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin when creating a new note from Zeppelin's UI.This issue affects Apache Zeppelin: from 0.10.1 before 0.11.0. Users are recommended to upgrade to version 0.11.0, which fixes the issue. |
| CVE-2024-31860 | Medium | 2024-04-09 | Protected by Waratek | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin. By adding relative path indicators(E.g ..), attackers can see the contents for any files in the filesystem that the server account can access. This issue affects Apache Zeppelin: from 0.9.0 before 0.11.0. Users are recommended to upgrade to version 0.11.0, which fixes the issue. |
| CVE-2022-47894 | Medium | 2024-04-09 | Protected by Waratek | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin SAP.This issue affects Apache Zeppelin SAP: from 0.8.0 before 0.11.0. 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. For more information, the fix already was merged in the source code but Zeppelin decided to retire the SAP component NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| CVE-2024-23634 | Medium | 2024-03-20 | No exploit published | No public exploit | GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. An arbitrary file renaming vulnerability exists in versions prior to 2.23.5 and 2.24.2 that enables an authenticated administrator with permissions to modify stores through the REST Coverage Store or Data Store API to rename arbitrary files and directories with a name that does not end in `.zip`. Store file uploads rename zip files to have a `.zip` extension if it doesn't already have one before unzipping the file. This is fine for file and url upload methods where the files will be in a specific subdirectory of the data directory but, when using the external upload method, this allows arbitrary files and directories to be renamed. Renaming GeoServer files will most likely result in a denial of service, either completely preventing GeoServer from running or effectively deleting specific resources (such as a workspace, layer or style). In some cases, renaming GeoServer files could revert to the default settings for that file which could be relatively harmless like removing contact information or have more serious consequences like allowing users to make OGC requests that the customized settings would have prevented them from making. The impact of renaming non-GeoServer files depends on the specific environment although some sort of denial of service is a likely outcome. Versions 2.23.5 and 2.24.2 contain a fix for this issue. |
| CVE-2023-51444 | High | 2024-03-20 | Protected by Waratek | Proof of concept only | GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. An arbitrary file upload vulnerability exists in versions prior to 2.23.4 and 2.24.1 that enables an authenticated administrator with permissions to modify coverage stores through the REST Coverage Store API to upload arbitrary file contents to arbitrary file locations which can lead to remote code execution. Coverage stores that are configured using relative paths use a GeoServer Resource implementation that has validation to prevent path traversal but coverage stores that are configured using absolute paths use a different Resource implementation that does not prevent path traversal. This vulnerability can lead to executing arbitrary code. An administrator with limited privileges could also potentially exploit this to overwrite GeoServer security files and obtain full administrator privileges. Versions 2.23.4 and 2.24.1 contain a fix for this issue. |
| CVE-2024-24683 | Medium | 2024-03-19 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Hop Engine.This issue affects Apache Hop Engine: before 2.8.0. Users are recommended to upgrade to version 2.8.0, which fixes the issue. When Hop Server writes links to the PrepareExecutionPipelineServlet page one of the parameters provided to the user was not properly escaped. The variable not properly escaped is the "id", which is not directly accessible by users creating pipelines making the risk of exploiting this low. This issue only affects users using the Hop Server component and does not directly affect the client. |
| CVE-2024-24549 | High | 2024-03-13 | Mitigation candidate | Proof of concept only | Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98. Other, older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue. |
| CVE-2024-27894 | High | 2024-03-12 | No exploit published | No public exploit | The Pulsar Functions Worker includes a capability that permits authenticated users to create functions where the function's implementation is referenced by a URL. The supported URL schemes include "file", "http", and "https". When a function is created using this method, the Functions Worker will retrieve the implementation from the URL provided by the user. However, this feature introduces a vulnerability that can be exploited by an attacker to gain unauthorized access to any file that the Pulsar Functions Worker process has permissions to read. This includes reading the process environment which potentially includes sensitive information, such as secrets. Furthermore, an attacker could leverage this vulnerability to use the Pulsar Functions Worker as a proxy to access the content of remote HTTP and HTTPS endpoint URLs. This could also be used to carry out denial of service attacks. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true". This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. 2.10 Pulsar Function Worker users should upgrade to at least 2.10.6. 2.11 Pulsar Function Worker users should upgrade to at least 2.11.4. 3.0 Pulsar Function Worker users should upgrade to at least 3.0.3. 3.1 Pulsar Function Worker users should upgrade to at least 3.1.3. 3.2 Pulsar Function Worker users should upgrade to at least 3.2.1. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The updated versions of Pulsar Functions Worker will, by default, impose restrictions on the creation of functions using URLs. For users who rely on this functionality, the Function Worker configuration provides two configuration keys: "additionalEnabledConnectorUrlPatterns" and "additionalEnabledFunctionsUrlPatterns". These keys allow users to specify a set of URL patterns that are permitted, enabling the creation of functions using URLs that match the defined patterns. This approach ensures that the feature remains available to those who require it, while limiting the potential for unauthorized access and exploitation. |
| CVE-2024-27135 | Critical | 2024-03-12 | No exploit published | No public exploit | Improper input validation in the Pulsar Function Worker allows a malicious authenticated user to execute arbitrary Java code on the Pulsar Function worker, outside of the sandboxes designated for running user-provided functions. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true". This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0. 2.10 Pulsar Function Worker users should upgrade to at least 2.10.6. 2.11 Pulsar Function Worker users should upgrade to at least 2.11.4. 3.0 Pulsar Function Worker users should upgrade to at least 3.0.3. 3.1 Pulsar Function Worker users should upgrade to at least 3.1.3. 3.2 Pulsar Function Worker users should upgrade to at least 3.2.1. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. |
| CVE-2023-50378 | Medium | 2024-03-01 | No exploit published | No public exploit | Lack of proper input validation and constraint enforcement in Apache Ambari prior to 2.7.8 Impact : As it will be stored XSS, Could be exploited to perform unauthorized actions, varying from data access to session hijacking and delivering malicious payloads. Users are recommended to upgrade to version 2.7.8 which fixes this issue. |
| CVE-2024-21742 | Medium | 2024-02-27 | No exploit published | No public exploit | Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message. This can be exploited by an attacker to add unintended headers to MIME messages. |
| CVE-2023-51747 | High | 2024-02-27 | No exploit published | No public exploit | Apache James prior to versions 3.8.1 and 3.7.5 is vulnerable to SMTP smuggling. A lenient behaviour in line delimiter handling might create a difference of interpretation between the sender and the receiver which can be exploited by an attacker to forge an SMTP envelop, allowing for instance to bypass SPF checks. The patch implies enforcement of CRLF as a line delimiter as part of the DATA transaction. We recommend James users to upgrade to non vulnerable versions. |
| CVE-2024-23320 | High | 2024-02-23 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache DolphinScheduler. An authenticated user can cause arbitrary, unsandboxed javascript to be executed on the server. This issue is a legacy of CVE-2023-49299. We didn't fix it completely in CVE-2023-49299, and we added one more patch to fix it. This issue affects Apache DolphinScheduler: until 3.2.1. Users are recommended to upgrade to version 3.2.1, which fixes the issue. |
| CVE-2023-6291 | High | 2024-01-26 | No exploit published | No public exploit | A flaw was found in the redirect_uri validation logic in Keycloak. This issue may allow a bypass of otherwise explicitly allowed hosts. A successful attack may lead to an access token being stolen, making it possible for the attacker to impersonate other users. |
| CVE-2023-51441 | High | 2024-01-06 | No exploit published | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Axis allowed users with access to the admin service to perform possible SSRF This issue affects Apache Axis: through 1.3. As Axis 1 has been EOL we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. Alternatively you could use a build of Axis with the patch from https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06 applied. The Apache Axis project does not expect to create an Axis 1.x release fixing this problem, though contributors that would like to work towards this are welcome. |
| CVE-2023-49299 | High | 2023-12-30 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache DolphinScheduler. An authenticated user can cause arbitrary, unsandboxed javascript to be executed on the server.This issue affects Apache DolphinScheduler: until 3.1.9. Users are recommended to upgrade to version 3.1.9, which fixes the issue. |
| CVE-2023-6835 | Medium | 2023-12-15 | No exploit published | No public exploit | Multiple WSO2 products have been identified as vulnerable due to lack of server-side input validation in the Forum feature, API rating could be manipulated. |
| CVE-2023-46589 | High | 2023-11-28 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82 and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy. Older, EOL versions may also be affected. Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue. |
| CVE-2023-40314 | Medium | 2023-11-16 | No exploit published | No public exploit | Cross-site scripting in bootstrap.jsp in multiple versions of OpenNMS Meridian and Horizon allows an attacker access to confidential session information. The solution is to upgrade to Horizon 32.0.5 or newer and Meridian 2023.1.9 or newer Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet. OpenNMS thanks Moshe Apelbaum for reporting this issue. |