Overview 156 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
156matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
156
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
156
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
4
2.6%
Forecast only
0
0.0%
No public exploit
152
97.4%
split by
peak 40 / year
20061
No exploit published1
Medium1
not blocked1
No public exploit1
20070
20081
No exploit published1
Medium1
not blocked1
No public exploit1
20092
No exploit published2
Medium2
not blocked2
No public exploit2
20103
No exploit published3
Medium3
not blocked3
No public exploit3
20118
No exploit published8
Medium8
not blocked8
No public exploit8
20128
No exploit published8
Medium8
not blocked8
No public exploit8
20138
No exploit published8
Medium8
not blocked8
No public exploit8
201410
No exploit published10
Medium10
not blocked10
No public exploit10
20155
No exploit published5
Medium5
not blocked5
No public exploit5
20164
No exploit published4
Medium4
not blocked4
No public exploit4
20178
No exploit published8
Medium8
not blocked8
No public exploit8
201812
No exploit published12
Medium12
not blocked12
No public exploit12
20191
No exploit published1
Medium1
not blocked1
No public exploit1
20205
No exploit published5
Medium5
not blocked5
No public exploit5
20216
No exploit published6
Medium6
not blocked6
No public exploit6
20229
No exploit published9
Medium9
not blocked9
Proof of concept only1
No public exploit8
20239
No exploit published9
Medium9
not blocked9
No public exploit9
202411
No exploit published11
Medium11
not blocked11
No public exploit11
20255
No exploit published5
Medium5
not blocked5
Proof of concept only1
No public exploit4
202640
No exploit published40
Medium40
not blocked40
Proof of concept only2
No public exploit38
20062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-97848 | Medium | 2026-11-06 | No exploit published | No public exploit | A flaw was found in the token sanitization logic of Keycloak, an open source identity and access management solution. The issue occurs when a protocol mapper is configured to emit structured claims using the JSON type. The security check designed to remove unauthorized role mappings only looks for standard Java maps and fails to recognize Jackson based JSON objects. This allows an attacker to inject forged client roles into security tokens, which could lead to unauthorized access to protected resources. |
| CVE-2026-97174 | Medium | 2026-11-05 | No exploit published | No public exploit | A flaw was found in the Client-Initiated Backchannel Authentication (CIBA) implementation of Keycloak. The CIBA endpoint fails to properly validate the sub parameter, allowing it to be stored as an additional request parameter. During the token issuance process, this injected value overwrites the legitimate subject identifier. This allows an attacker to authenticate as themselves but receive security tokens belonging to a different victim user, leading to unauthorized account access. |
| CVE-2026-108946 | Medium | 2026-11-04 | No exploit published | No public exploit | Improper input validation vulnerability in Apache ActiveMQ, Apache ActiveMQ KahaDB. The ActiveMQ broker resolves connection, session and consumer state from ids that are user provided and in some scenarios does not validate that they ids are bound to that user. This allows an authenticated client to spoof another user's ids. This allows: * an authenticated client consumes from another connection's temporary queue/topic by putting the victim's connection id in its own ConsumerId, bypassing the broker-side ownership check. * a duplicate ConsumerId registration is only logged, after which the attacker's RemoveInfo or disconnect tears down the victim's live subscription * a forged MessageAck for the victim's ConsumerId permanently deletes an in-flight, unacknowledged message. This issue affects Apache ActiveMQ: from 6.0.0 before 6.3.3, before 5.19.12; Apache ActiveMQ KahaDB: from 6.0.0 before 6.3.3, before 5.19.12. Users are recommended to upgrade to version 6.4.0, 6.3.3, or 5.19.12, which fixes the issue. |
| CVE-2026-108500 | Medium | 2026-11-04 | No exploit published | No public exploit | Input validation vulnerability in Apache ActiveMQ configured to use the LDAPAuthorizationMapPlugin allows an authenticated attacker to create or address a destination with a crafted name containing LDAP DN special characters (such as comma, plus, equals, backslash) can manipulate the LDAP search base used for ACL lookups. This issue affects Apache ActiveMQ: from 6.3.0 before 6.3.3, from 5.19.0 before 5.19.12. Users are recommended to upgrade to version 6.4.0, 6.3.3 or 5.19.12, which fixes the issue. |
| CVE-2026-119641 | Medium | 2026-11-03 | No exploit published | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Improper input validation vulnerability in Apache Oozie. An authenticated Oozie user can reconfigure another tenant's workflow job and change its ownership. This issue affects Apache Oozie: 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-119210 | Medium | 2026-10-29 | No exploit published | No public exploit | MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the ClientMessage.validateLocalFileName() check used a regular expression that could match LOAD DATA LOCAL INFILE text inside quoted identifiers, string literals, or comments instead of requiring a real statement. A malicious or compromised server, or a machine-in-the-middle attacker, could return crafted database or table identifiers that the connector reused in metadata or updatable-result queries, then answer with a LOCAL INFILE request for a client file. With allowLocalInfile enabled, this caused the connector to stream any readable client-host file named by the crafted text, including through DatabaseMetaData.getImportedKeys(), DatabaseMetaData.getExportedKeys(), or ResultSet.updateRow() paths. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11. |
| CVE-2026-91411 | Medium | 2026-10-20 | No exploit published | No public exploit | Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JGSS). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition as well as unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 6.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H). |
| CVE-2026-85314 | Medium | 2026-10-19 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Camel Mail component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. CVE-2026-46584 addressed mail headers reaching the Exchange without passing through a header filter, but the MimeMultipart data format retained an unfiltered path: unmarshalling a multipart message mapped mail.smtp headers onto the Exchange with no filter applied. Those names sit outside the Camel namespace that consumer filters block, so a message crafted by an external sender could still set them, and the mail.smtp namespace influences how a downstream mail producer connects and sends. This is an incomplete fix of CVE-2026-46584 rather than a new class of defect: a deployment that applied that advisory and considered camel-mail settled remained exposed on this path. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The MimeMultipart data format now applies the header filter on unmarshal, closing the path CVE-2026-46584 left open. For deployments that cannot upgrade immediately, strip the namespace after the data format with removeHeaders("mail.smtp*") before any mail producer. |
| CVE-2026-85312 | Medium | 2026-10-19 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Camel Core component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The saga processor consulted a header named Long-Running-Action to decide which saga an exchange belonged to. The name carries no Camel prefix, so it sits outside the namespace that consumer header filters block, and an external sender could supply it on an inbound message. That let the sender name the saga the exchange joined, attaching their request to a long-running action started by someone else, or causing compensation to be associated with an action they did not initiate. The header is only consulted by a saga service that uses it, which bounds the exposure to deployments running sagas over an LRA coordinator. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The header is now consulted only for a saga service that actually uses it, rather than on every exchange. For deployments that cannot upgrade immediately, strip the header at the trust boundary with removeHeaders("Long-Running-Action") on every consumer that accepts messages from an untrusted sender. |
| CVE-2026-85249 | Medium | 2026-10-19 | No exploit published | No public exploit | Improper Input Validation vulnerability in Apache Camel Tika component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Tika producer mapped every metadata key parsed out of the submitted document onto the Exchange as a header, with no filter applied. Document metadata is attacker-controlled content: the party that supplies the file chooses the metadata keys it carries. A crafted document could therefore set Exchange headers that the rest of the route depends on, including headers in the Camel namespace such as CamelFileName, which downstream components use to decide where content is written. The pattern is the same header-injection class as the consumer advisories published previously, reached here through parsed file content rather than through a protocol header. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. Parsed document metadata is now filtered through a HeaderFilterStrategy before it is mapped onto the Exchange. A route that was reading a metadata-derived header the filter now blocks will see it missing. For deployments that cannot upgrade immediately, strip the Camel namespace after the Tika producer with removeHeaders("Camel*") before any component that acts on those headers. |
| CVE-2026-54700 | Medium | 2026-10-13 | No exploit published | No public exploit | ConnectBot SSH Client Library is written in Kotlin with Kaitai Struct and KStateMachine. Prior to 0.3.1, the SSH protocol parser trusts attacker-controlled inner byte lengths and element counts without verifying that they fit in the containing packet. A malicious or compromised SSH server can return a small malformed packet whose oversized declarations cause the Kaitai Struct Java runtime to attempt excessive allocation or repeated parsing before detecting truncated input. The general transport path requires a client connection but no authentication or optional feature; malformed SSH-agent messages additionally require SSH agent forwarding. The issue can raise an uncaught OutOfMemoryError and terminate the application process, with no demonstrated confidentiality or integrity impact. This issue is fixed in version 0.3.1. |
| CVE-2026-93995 | Medium | 2026-09-30 | No exploit published | No public exploit | Improper input validation in sshd-git in Apache MINA SSHD, versions up to 2.19.0 and 3.0.0-M1 to 3.0.0-M5. Apache MINA SSHD is a Java library for client-side and server-side SSH. Component org.apache.sshd:sshd-git provides though class GitPgmCommandFactory a way to configure an Apache MINA SSHD server such that authenticated SSH clients can remotely execute git commands via the JGit library on git repositories stored on the server. In CVE-2026-58624 this mechanism was restricted to only a few git commands, including "git archive" without "--output" or "-o" options such that the resulting archive would not be written on the server but instead sent back to the client over the SSH connection. The fix done for CVE-2026-58624 was insufficient as it missed removing the single-argument "-o=file.zip" version of the command parameter from the "archive" command. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue. |
| CVE-2026-85528 | Medium | 2026-09-04 | No exploit published | No public exploit | Improper input validation of the auto-configuration account identifier in Snowflake JDBC Driver versions 4.2.0 through 4.3.3 allowed a credential-bearing login request to be redirected to an attacker-selected HTTPS endpoint. An attacker able to control the account value could cause the driver to transmit a reusable login credential to a host of their choosing and replay it to obtain the privileges granted to that credential. Successful exploitation requires an application using jdbc:snowflake:auto with a connections.toml section that omits an explicit host and a lower-trust principal able to set the account value; ordinary JDBC URLs are unaffected. The fix is available in Snowflake JDBC Driver version 4.3.4, including the snowflake-jdbc-fips and snowflake-jdbc-thin. Users must manually upgrade. |
| CVE-2026-84666 | Medium | 2026-09-02 | No exploit published | No public exploit | Jenkins Job Configuration History Plugin 1367.vc8fa_b_15101dc and earlier allows overwriting the plugin's history recording configuration through Stapler data binding, allowing attackers to redirect history storage to an attacker-specified directory and modify history recording settings. |
| CVE-2026-49830 | Medium | 2026-09-02 | No exploit published | No public exploit | DSpace open source software is a repository application which provides durable access to digital resources. Prior to versions 7.6.7, 8.4, 9.3, and 10.0, when ingesting an aggregated ORE resource by URI (using the OAI-ORE Harvester), the ORE Ingestion Crosswalk does not validate the URI scheme. This may allow for local file inclusion via malicious paths like file:///etc/passwd. The attacker MUST already have DSpace collection administrator privileges in order to perform the attack. This issue has been patched in versions 7.6.7, 8.4, 9.3, and 10.0. |
| CVE-2026-47880 | Medium | 2026-08-27 | No exploit published | No public exploit | A producer who can publish to a JMS destination consumed by any Spring Integration JMS inbound component can set String JMS properties named replyChannel, errorChannel, or json__TypeId__ which are copied verbatim into the Spring Integration MessageHeaders. 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 Spring Integration 5.5.21 and earlier |
| CVE-2026-59230 | Medium | 2026-08-24 | No exploit published | No public exploit | Improper input validation vulnerability in Apache Camel. This issue affects Apache Camel: from 2.17.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-mail component ships a MimeMultipart data format that can unmarshal a MIME multipart message. When it is configured with headersInline set to true, the unmarshal path copies the MIME headers of the incoming message onto the Camel message: it enumerates every header that is not one of the three standard ones it generates itself - Message-ID, MIME-Version and Content-Type - and calls setHeader for each, applying no HeaderFilterStrategy. The names of those MIME headers come from the message being unmarshalled, so a sender able to influence the message could place a header whose name falls in the Camel-internal namespace and have it set on the Exchange. Camel components read control headers from that namespace to override their configured behaviour - the camel-sql producer, for instance, takes the statement to execute from a Camel header when one is present - so an injected header could redirect what a downstream step in the route does with data the route author never intended it to take from the message. Which sinks are reachable, and what the consequences are, depends entirely on what the route does after the unmarshal step. The camel-mail consumer already applied a header filter strategy on its own inbound path, so this was the parallel inbound path into the same component that the earlier hardening did not cover. The affected copy is reached only when headersInline is enabled, which is not the default: with the default setting the MIME headers are surfaced as attachments rather than as message headers, and are not affected. The behaviour dates back to the introduction of the data format in 2.17.0 and was present on every release line until this fix. 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, leave headersInline at its default of false where the inline headers are not needed, since the copy is only reached when it is enabled. Where it must stay enabled, strip Camel-internal headers immediately after the unmarshal step, for example with removeHeaders(“Camel*”) placed before any processor or producer that reads control headers, and do not unmarshal MIME content from an untrusted sender into a route that dispatches on header values. As defence in depth, treat the header names of any MIME message arriving from outside the trust boundary as untrusted input. |
| CVE-2026-63335 | Medium | 2026-08-18 | No exploit published | 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.31.0, inbound AMQP command assembly in src/main/java/com/rabbitmq/client/impl/CommandAssembler.java processes a content-bearing method and header whose remainingBodyBytes value is smaller than a following AMQP.FRAME_BODY payload. CommandAssembler.consumeBodyFrame subtracts the peer-controlled payload length before validating that it fits, drives remainingBodyBytes negative, and throws a raw UnsupportedOperationException instead of MalformedFrameException. A malicious or compromised broker peer can send this malformed sequence on an open nonzero channel to terminate frame processing and close the client connection, causing denial of service for work using that connection. This issue is fixed in version 5.31.0. |
| CVE-2025-13909 | Medium | 2026-08-06 | No exploit published | No public exploit | The system accepts authentication requests without sufficient validation to enforce tenant isolation when using Email OTP, SMS OTP, or Magic Link as first-factor authenticators. This failure to adequately separate user data between tenants can lead to the exposure of personally identifiable information. Successful exploitation allows an attacker to disclose personally identifiable information of users in different tenants, resulting in privacy violations and potential regulatory non-compliance. This may include unauthorized access to user details such as mobile numbers. |
| CVE-2024-6541 | Medium | 2026-08-06 | No exploit published | No public exploit | The Class Mediator fails to correctly validate or sanitize `messageContext` properties when they are used to populate dynamic values. This allows authenticated users to potentially access or modify data across different system invocations that should be isolated. This weakness can lead to the disclosure of sensitive information belonging to other users or the unintended modification of system data by authenticated users. The exact impact depends on how `messageContext` properties are utilized within the affected WSO2 products. |
| CVE-2024-10302 | Medium | 2026-08-06 | No exploit published | No public exploit | The user self-signup flow in multiple WSO2 products fails to adequately validate user-supplied input. This weakness allows arbitrary unvalidated data to be included within user claims, which are then used by downstream processes. Allowing unvalidated input into user claims can lead to various security risks. Malicious or malformed data injected during signup could be processed by other parts of the application, potentially enabling attacks such as content manipulation, redirection, user interface inconsistencies, unauthorized actions, and data exposure. The actual impact depends on how the compromised data is consumed and the privileges associated with the affected users. |
| CVE-2026-18217 | Medium | 2026-07-31 | No exploit published | No public exploit | A flaw was found in the SAML protocol implementation of Keycloak, an open-source identity and access management solution. The issue occurs when Keycloak handles SAML authentication requests using the HTTP-Redirect binding. If a client is configured with a wildcard redirect URL, an attacker can craft a request that includes malicious parameters. When a user authenticates, Keycloak appends its legitimate response to the attacker's parameters. This can cause some service providers to process the attacker's data instead of the real login information, potentially leading to a user being logged into the wrong account. |
| CVE-2026-18211 | Medium | 2026-07-31 | No exploit published | No public exploit | A flaw was found in the secure-client-uris client policy executor within Keycloak core services. This component is responsible for enforcing security requirements on client configurations, such as requiring encrypted connections for redirect URIs. Due to an improper check that only looks at the start of a web address rather than properly verifying the host, an attacker can bypass these security restrictions by using a specially crafted domain name. This could allow an attacker to intercept sensitive authentication codes over unencrypted connections. |
| CVE-2026-62519 | Medium | 2026-07-21 | No exploit published | No public exploit | Vulnerability in the Oracle Succession planning product of Oracle E-Business Suite (component: Succession plan). Supported versions that are affected are 12.2.3-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Succession planning. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Succession planning accessible data as well as unauthorized read access to a subset of Oracle Succession planning accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Succession planning. CVSS 3.1 Base Score 6.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L). |
| CVE-2026-60620 | Medium | 2026-07-21 | No exploit published | No public exploit | Vulnerability in the JD Edwards EnterpriseOne Configurator product of Oracle JD Edwards (component: Configuration Management). The supported version that is affected is 9.2. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise JD Edwards EnterpriseOne Configurator. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of JD Edwards EnterpriseOne Configurator as well as unauthorized update, insert or delete access to some of JD Edwards EnterpriseOne Configurator accessible data and unauthorized read access to a subset of JD Edwards EnterpriseOne Configurator accessible data. CVSS 3.1 Base Score 6.4 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H). |
| CVE-2026-60613 | Medium | 2026-07-21 | No exploit published | No public exploit | Vulnerability in the PeopleSoft Enterprise CS Student Records product of Oracle PeopleSoft (component: Research Tracking). The supported version that is affected is 9.2.38. Difficult to exploit vulnerability allows high privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CS Student Records. Successful attacks of this vulnerability can result in takeover of PeopleSoft Enterprise CS Student Records. CVSS 3.1 Base Score 6.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H). |
| CVE-2026-58624 | Medium | 2026-07-20 | No exploit published | No public exploit | Improper input validation in sshd-git in Apache MINA SSHD. Apache MINA SSHD is a Java library for client-side and server-side SSH. Component org.apache.sshd:sshd-git provides though its GitPgmCommandFactory a way to configure an Apache MINA SSHD server such that SSH clients can remotely execute git commands via the JGit library on git repositories stored on the server. This GitPgmCommandFactory allowed a user authenticated via SSH to run any JGit command available, including commands that could write files at arbitrary places such as git archive with the --output option. Affected are SSH servers implemented with Apache MINA SSHD and using the GitPgmCommandFactory. If the GitPgmCommandFactory is not configured on the server, the server is not affected. It is recommended to upgrade affected servers to Apache MINA SSHD 2.19.0 or 3.0.0-M5, which fix this issue. The issue is fixed by restricting the available commands to a small whitelist of uncritical commands (such as git log). git archive is also allowed, but its --output argument is ignored and the archive is always sent through the SSH channel to the client. |
| CVE-2026-6790 | Medium | 2026-07-14 | No exploit published | No public exploit | In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present). This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112). This mismatch can cause a number of problems that may be classified as vulnerabilities such as: * URI constructions (for example, for redirects -- this is typical for login pages) * Virtual host selection * Reverse proxying * Misleading logs * Etc. Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant. |
| CVE-2026-49098 | Medium | 2026-07-06 | No exploit published | No public exploit | Improper Input Validation, Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in Apache Camel Kafka Component. The camel-kafka producer can override its configured target topic at runtime from the kafka.OVERRIDE_TOPIC Exchange header: KafkaProducer.evaluateTopic() returns the header value in preference to the topic configured on the endpoint. The control-header constants in KafkaConstants (for example OVERRIDE_TOPIC = kafka.OVERRIDE_TOPIC, OVERRIDE_TIMESTAMP = kafka.OVERRIDE_TIMESTAMP, PARTITION_KEY = kafka.PARTITION_KEY) used plain, non-Camel-prefixed values. camel-kafka's own KafkaHeaderFilterStrategy does filter the kafka.* namespace, but only on the Kafka-to-Exchange serialization boundary (reading Kafka record headers into the Exchange, and writing Exchange headers into a Kafka record); it does not apply to headers that arrive from an upstream consumer in a multi-component route. The upstream HTTP consumer uses HttpHeaderFilterStrategy, which blocks only the Camel / camel namespace, so a kafka.* header passes through unfiltered. As a result, in a route that bridges an HTTP consumer (for example platform-http) into a kafka: producer, any HTTP client could set the kafka.OVERRIDE_TOPIC header and cause the message to be published to an arbitrary Kafka topic instead of the configured one - redirecting it to a sensitive internal topic, or injecting attacker-crafted messages into a topic consumed by a critical downstream service. The related kafka.OVERRIDE_TIMESTAMP and kafka.PARTITION_KEY headers could likewise be injected to backdate messages or target specific partitions. No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set or read Kafka headers via the raw header names must use the CamelKafka* names (for example CamelKafkaOverrideTopic and CamelKafkaTopic) instead of the old kafka.* values. For deployments that cannot upgrade immediately, strip the kafka.* headers from any untrusted ingress before the kafka: producer (for example removeHeaders('kafka.*') at the start of the route), and set the target topic from a trusted source. |
| CVE-2026-49097 | Medium | 2026-07-06 | No exploit published | No public exploit | Improper Input Validation, Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in Apache Camel IRC component. The camel-irc producer chooses the destination of an outgoing IRC message from the irc.sendTo Exchange header (the constant IrcConstants.IRC_SEND_TO, value irc.sendTo); when that header is present it overrides the channel list configured on the endpoint, and the message is sent only to the specified destination. This and the component's other control headers (irc.target, irc.messageType, irc.user.*, irc.num, irc.value) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into an irc: producer, any HTTP client could therefore set the irc.sendTo header and redirect a message that the route intended for a configured channel to an arbitrary IRC channel or user - exfiltrating the message content to an attacker-chosen nickname, leaking it into a public channel, or delivering messages that appear to come from the bot. No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set IRC headers via the raw header names must use the CamelIrc* names (for example CamelIrcSendTo) instead of the old irc.* values. For deployments that cannot upgrade immediately, strip the irc.* headers from any untrusted ingress before the irc: producer (for example removeHeaders('irc.*') at the start of the route), and set the IRC destination from a trusted source. |
| CVE-2026-49086 | Medium | 2026-07-06 | No exploit published | No public exploit | Improper Input Validation, Unintended Proxy or Intermediary ('Confused Deputy') vulnerability in Apache Camel DAPR component. The camel-dapr Dapr Pub/Sub consumer (DaprPubSubConsumer) copied two fields from each inbound CloudEvent - its Pub/Sub component name and its topic - into the CamelDaprPubSubName and CamelDaprTopic Exchange headers. These two headers are producer-direction routing headers: when the route republishes through a Dapr producer, DaprConfigurationOptionsProxy reads them back and prefers them over the destination configured on the endpoint. As a result, in a route that consumes from one Dapr Pub/Sub topic and republishes to another (for example from('dapr-pubsub:p:t').to('dapr-pubsub:p:other')), an actor able to publish a message to the subscribed topic could set the CloudEvent's pub/sub-name and topic to values of their choosing and cause the re-published message to be delivered to an arbitrary Dapr Pub/Sub component and topic instead of the configured destination - redirecting or exfiltrating the message and bypassing the route's intended routing and any topic-level access controls in the underlying broker. Exploitation requires the ability to publish to the topic the route subscribes to; no other authentication or user interaction is needed. This issue affects Apache Camel: from 4.12.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. For deployments that cannot upgrade immediately, remove the CamelDaprPubSubName and CamelDaprTopic headers from the Exchange between the Dapr consumer and any Dapr producer in the route (for example removeHeaders('CamelDaprPubSubName', 'CamelDaprTopic')), and restrict who can publish to the subscribed Dapr Pub/Sub topic so that only trusted producers can send to it. |
| CVE-2026-48206 | Medium | 2026-07-06 | No exploit published | No public exploit | Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel JIRA component. The camel-jira producers read their operation parameters - the issue key, project key, transition id, summary, type, assignee, components, watchers, link type, work-log minutes and others - from Exchange message headers. The header constants defined in JiraConstants (for example ISSUE_KEY = IssueKey, ISSUE_PROJECT_KEY = ProjectKey, ISSUE_TRANSITION_ID = IssueTransitionId, LINK_TYPE = linkType) used plain, non-Camel-prefixed values. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a jira: producer, any HTTP client could therefore supply these headers and override the values the route intended, driving JIRA operations against the configured JIRA instance with the endpoint's configured service-account credentials - for example deleting or transitioning an arbitrary issue (via IssueKey / IssueTransitionId), creating an issue in a different project (via ProjectKey), modifying issue fields, adding or removing watchers, or logging work. The operations are bounded by what the configured service account is permitted to do. No credentials are required from the attacker when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that drive JIRA operations via the raw header names must use the CamelJira* names (for example CamelJiraIssueKey) instead of the old values. For deployments that cannot upgrade immediately, strip the camel-jira control headers from any untrusted ingress before the jira: producer (for example removing the IssueKey, ProjectKey, IssueTransitionId and related headers at the start of the route), and set the required JIRA operation parameters from a trusted source. |
| CVE-2026-46453 | Medium | 2026-07-06 | No exploit published | No public exploit | Improper Input Validation, Authorization Bypass Through User-Controlled Key vulnerability in Apache Camel ElasticSearch Rest Client. The camel-elasticsearch-rest-client component reads several Exchange headers to control its behaviour - SEARCH_QUERY (an advanced query body), OPERATION (which Elasticsearch operation to run), INDEX_NAME, INDEX_SETTINGS and ID. The string values of these header constants, defined in ElasticSearchRestClientConstant, are plain unprefixed names ('SEARCH_QUERY', 'OPERATION', 'INDEX_NAME', 'INDEX_SETTINGS', 'ID') rather than the 'Camel'-prefixed names used by every other Camel component (for example CamelSqlQuery, CamelMongoDbCriteria, CamelCqlQuery). Camel's inbound HTTP header filter, HttpHeaderFilterStrategy, blocks only header names that begin with 'Camel' or 'camel'. Because the Elasticsearch header names do not carry that prefix, they pass through the inbound filter unchanged. When a Camel route exposes an HTTP entry point (for example platform-http) in front of an elasticsearch-rest-client producer, an untrusted HTTP client can set these headers directly on its request and override the query and operation that the route author configured: reading every document in the index (SEARCH_QUERY with a match_all query), deleting documents (OPERATION set to Delete together with ID), or exfiltrating selected fields. No credentials are required and the producer reads the headers unconditionally. This issue affects Apache Camel: from 4.3.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix renames the camel-elasticsearch-rest-client Exchange header constant string values (ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION) to carry the Camel prefix (CamelElasticsearchId, CamelElasticsearchSearchQuery, CamelElasticsearchIndexSettings, CamelElasticsearchIndexName, CamelElasticsearchOperation) so that they are blocked by the inbound HttpHeaderFilterStrategy; the Java field names are unchanged. For deployments that cannot upgrade immediately, strip the affected headers from untrusted inbound messages before they reach the producer (for example removeHeader('SEARCH_QUERY'), removeHeader('OPERATION'), removeHeader('INDEX_NAME'), removeHeader('INDEX_SETTINGS') and removeHeader('ID') in front of the elasticsearch-rest-client endpoint), or apply a custom HeaderFilterStrategy that blocks these names. |
| 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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. |
| CVE-2023-36566 | Medium | 2023-10-10 | No exploit published | No public exploit | Microsoft Common Data Model SDK Denial of Service Vulnerability |
| CVE-2023-42503 | Medium | 2023-09-14 | No exploit published | No public exploit | Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. Users are recommended to upgrade to version 1.24.0, which fixes the issue. A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. [1]: https://issues.apache.org/jira/browse/COMPRESS-612 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 [3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html [4]: https://bugs.openjdk.org/browse/JDK-6560193 [5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. |
| CVE-2023-34150 | Medium | 2023-07-05 | No exploit published | No public exploit | ** UNSUPPORTED WHEN ASSIGNED ** Use of TikaEncodingDetector in Apache Any23 can cause excessive memory usage. |
| CVE-2023-0869 | Medium | 2023-02-23 | No exploit published | No public exploit | Cross-site scripting in outage/list.htm in multiple versions of OpenNMS Meridian and Horizon allows an attacker access to confidential session information. The solution is to upgrade to Meridian 2023.1.0 or newer, or Horizon 31.0.4 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. |
| CVE-2023-0868 | Medium | 2023-02-23 | No exploit published | No public exploit | Reflected cross-site scripting in graph results in multiple versions of OpenNMS Meridian and Horizon could allow an attacker access to steal session cookies. Users should upgrade to Meridian 2023.1.0 or newer, or Horizon 31.0.4. 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. |
| CVE-2023-0867 | Medium | 2023-02-23 | No exploit published | No public exploit | Multiple stored and reflected cross-site scripting vulnerabilities in webapp jsp pages in multiple versions of OpenNMS Meridian and Horizon could allow an attacker access to confidential session information. Users should upgrade to Meridian 2023.1.0 or newer, or Horizon 31.0.4. 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. |
| CVE-2022-44644 | Medium | 2023-01-31 | No exploit published | No public exploit | In Apache Linkis <=1.3.0 when used with the MySQL Connector/J in the data source module, an authenticated attacker could read arbitrary local files by connecting a rogue MySQL server, By adding allowLoadLocalInfile to true in the JDBC parameter. Therefore, the parameters in the JDBC URL should be blacklisted. Versions of Apache Linkis <= 1.3.0 will be affected. We recommend users upgrade the version of Linkis to version 1.3.1 |
| CVE-2021-28655 | Medium | 2022-12-16 | No exploit published | No public exploit | The improper Input Validation vulnerability in "”Move folder to Trash” feature of Apache Zeppelin allows an attacker to delete the arbitrary files. This issue affects Apache Zeppelin Apache Zeppelin version 0.9.0 and prior versions. |
| CVE-2021-37533 | Medium | 2022-12-03 | No exploit published | No public exploit | Prior to Apache Commons Net 3.9.0, Net's FTP client trusts the host from PASV response by default. A malicious server can redirect the Commons Net code to use a different host, but the user has to connect to the malicious server in the first place. This may lead to leakage of information about services running on the private network of the client. The default in version 3.9.0 is now false to ignore such hosts, as cURL does. See https://issues.apache.org/jira/browse/NET-711. |
| CVE-2022-3676 | Medium | 2022-10-24 | No exploit published | No public exploit | In Eclipse Openj9 before version 0.35.0, interface calls can be inlined without a runtime type check. Malicious bytecode could make use of this inlining to access or modify memory via an incompatible type. |
| CVE-2022-39259 | Medium | 2022-10-21 | No exploit published | Proof of concept only | jadx is a set of command line and GUI tools for producing Java source code from Android Dex and Apk files. versions prior to 1.4.5 are subject to a Denial of Service when opening zip files with HTML sequences. This issue has been patched in version 1.4.5. There are no known workarounds. |
| CVE-2022-24280 | Medium | 2022-09-23 | No exploit published | No public exploit | Improper Input Validation vulnerability in Proxy component of Apache Pulsar allows an attacker to make TCP/IP connection attempts that originate from the Pulsar Proxy's IP address. When the Apache Pulsar Proxy component is used, it is possible to attempt to open TCP/IP connections to any IP address and port that the Pulsar Proxy can connect to. An attacker could use this as a way for DoS attacks that originate from the Pulsar Proxy's IP address. It hasn’t been detected that the Pulsar Proxy authentication can be bypassed. The attacker will have to have a valid token to a properly secured Pulsar Proxy. This issue affects Apache Pulsar Proxy versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.2; 2.9.0 to 2.9.1; 2.6.4 and earlier. |
| CVE-2021-3754 | Medium | 2022-08-26 | No exploit published | No public exploit | A flaw was found in keycloak where an attacker is able to register himself with the username same as the email ID of any existing user. This may cause trouble in getting password recovery email in case the user forgets the password. |
| CVE-2020-35509 | Medium | 2022-08-23 | No exploit published | No public exploit | A flaw was found in keycloak affecting versions 11.0.3 and 12.0.0. An expired certificate would be accepted by the direct-grant authenticator because of missing time stamp validations. The highest threat from this vulnerability is to data confidentiality and integrity. |
| CVE-2022-29049 | Medium | 2022-04-12 | No exploit published | No public exploit | Jenkins promoted builds Plugin 873.v6149db_d64130 and earlier, except 3.10.1, does not validate the names of promotions defined in Job DSL, allowing attackers with Job/Configure permission to create a promotion with an unsafe name. |
| CVE-2021-41571 | Medium | 2022-02-01 | No exploit published | No public exploit | In Apache Pulsar it is possible to access data from BookKeeper that does not belong to the topics accessible by the authenticated user. The Admin API get-message-by-id requires the user to input a topic and a ledger id. The ledger id is a pointer to the data, and it is supposed to be a valid it for the topic. Authorisation controls are performed against the topic name and there is not proper validation the that ledger id is valid in the context of such ledger. So it may happen that the user is able to read from a ledger that contains data owned by another tenant. This issue affects Apache Pulsar Apache Pulsar version 2.8.0 and prior versions; Apache Pulsar version 2.7.3 and prior versions; Apache Pulsar version 2.6.4 and prior versions. |
| CVE-2021-39234 | Medium | 2021-11-19 | No exploit published | No public exploit | In Apache Ozone versions prior to 1.2.0, Authenticated users knowing the ID of an existing block can craft specific request allowing access those blocks, bypassing other security checks like ACL. |
| CVE-2021-35611 | Medium | 2021-10-20 | No exploit published | No public exploit | Vulnerability in the Oracle Sales Offline product of Oracle E-Business Suite (component: Offline Template). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Sales Offline. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Sales Offline. CVSS 3.1 Base Score 4.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L). |
| CVE-2021-33609 | Medium | 2021-10-13 | No exploit published | No public exploit | Missing check in DataCommunicator class in com.vaadin:vaadin-server versions 8.0.0 through 8.14.0 (Vaadin 8.0.0 through 8.14.0) allows authenticated network attacker to cause heap exhaustion by requesting too many rows of data. |
| CVE-2021-31412 | Medium | 2021-06-24 | No exploit published | No public exploit | Improper sanitization of path in default RouteNotFoundError view in com.vaadin:flow-server versions 1.0.0 through 1.0.14 (Vaadin 10.0.0 through 10.0.18), 1.1.0 prior to 2.0.0 (Vaadin 11 prior to 14), 2.0.0 through 2.6.1 (Vaadin 14.0.0 through 14.6.1), and 3.0.0 through 6.0.9 (Vaadin 15.0.0 through 19.0.8) allows network attacker to enumerate all available routes via crafted HTTP request when application is running in production mode and no custom handler for NotFoundException is provided. |
| CVE-2021-21639 | Medium | 2021-04-07 | No exploit published | No public exploit | Jenkins 2.286 and earlier, LTS 2.277.1 and earlier does not validate the type of object created after loading the data submitted to the `config.xml` REST API endpoint of a node, allowing attackers with Computer/Configure permission to replace a node with one of a different type. |
| CVE-2021-21606 | Medium | 2021-01-13 | No exploit published | No public exploit | Jenkins 2.274 and earlier, LTS 2.263.1 and earlier improperly validates the format of a provided fingerprint ID when checking for its existence allowing an attacker to check for the existence of XML files with a short path. |
| CVE-2020-14338 | Medium | 2020-09-17 | No exploit published | No public exploit | A flaw was found in Wildfly's implementation of Xerces, specifically in the way the XMLSchemaValidator class in the JAXP component of Wildfly enforced the "use-grammar-pool-only" feature. This flaw allows a specially-crafted XML file to manipulate the validation process in certain cases. This issue is the same flaw as CVE-2020-14621, which affected OpenJDK, and uses a similar code. This flaw affects all Xerces JBoss versions before 2.12.0.SP3. |
| CVE-2020-1727 | Medium | 2020-06-22 | No exploit published | No public exploit | A vulnerability was found in Keycloak before 9.0.2, where every Authorization URL that points to an IDP server lacks proper input validation as it allows a wide range of characters. This flaw allows a malicious to craft deep links that introduce further attack scenarios on affected clients. |
| CVE-2020-10693 | Medium | 2020-05-06 | No exploit published | No public exploit | A flaw was found in Hibernate Validator version 6.1.2.Final. A bug in the message interpolation processor enables invalid EL expressions to be evaluated as if they were valid. This flaw allows attackers to bypass input sanitation (escaping, stripping) controls that developers may have put in place when handling user-controlled data in error messages. |
| CVE-2020-1732 | Medium | 2020-05-04 | No exploit published | No public exploit | A flaw was found in Soteria before 1.0.1, in a way that multiple requests occurring concurrently causing security identity corruption across concurrent threads when using EE Security with WildFly Elytron which can lead to the possibility of being handled using the identity from another request. |
| CVE-2020-11007 | Medium | 2020-04-16 | No exploit published | No public exploit | In Shopizer before version 2.11.0, using API or Controller based versions negative quantity is not adequately validated hence creating incorrect shopping cart and order total. This vulnerability makes it possible to create a negative total in the shopping cart. This has been patched in version 2.11.0. |
| CVE-2019-0214 | Medium | 2019-04-30 | No exploit published | No public exploit | In Apache Archiva 2.0.0 - 2.2.3, it is possible to write files to the archiva server at arbitrary locations by using the artifact upload mechanism. Existing files can be overwritten, if the archiva run user has appropriate permission on the filesystem for the target file. |
| CVE-2018-11799 | Medium | 2018-12-19 | No exploit published | No public exploit | Vulnerability allows a user of Apache Oozie 3.1.3-incubating to 5.0.0 to impersonate other users. The malicious user can construct an XML that results workflows running in other user's name. |
| CVE-2018-16956 | Medium | 2018-09-18 | No exploit published | No public exploit | The AjaxControl component of Oracle WebCenter Interaction Portal 10.3.3 does not validate the names of pages when processing page rename requests. Pages can be renamed to include characters unsupported for URIs by the web server hosting the WCI Portal software (such as IIS). Renaming pages to include unsupported characters, such as 0x7f, prevents these pages from being accessed over the web server, causing a Denial of Service (DoS) to the page. NOTE: this CVE is assigned by MITRE and isn't validated by Oracle because Oracle WebCenter Interaction Portal is out of support. |
| CVE-2018-12537 | Medium | 2018-08-14 | No exploit published | No public exploit | In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response. |
| CVE-2018-1999037 | Medium | 2018-08-01 | No exploit published | No public exploit | A data modification vulnerability exists in Jenkins Resource Disposer Plugin 0.11 and earlier in AsyncResourceDisposer.java that allows attackers to stop tracking a resource. |
| CVE-2017-2674 | Medium | 2018-07-27 | No exploit published | No public exploit | JBoss BRMS 6 and BPM Suite 6 before 6.4.3 are vulnerable to a stored XSS via several lists in Business Central. The flaw is due to lack of sanitation of user input when creating new lists. Remote, authenticated attackers that have privileges to create lists can store scripts in them, which are not properly sanitized before showing to other users, including admins. |
| CVE-2017-2658 | Medium | 2018-07-27 | No exploit published | No public exploit | It was discovered that the Dashbuilder login page as used in Red Hat JBoss BPM Suite before 6.4.2 and Red Hat JBoss Data Virtualization & Services before 6.4.3 could be opened in an IFRAME, which made it possible to intercept and manipulate requests. An attacker could use this flaw to trick a user into performing arbitrary actions in the Console (clickjacking). |
| CVE-2018-1000607 | Medium | 2018-06-26 | No exploit published | No public exploit | A arbitrary file write vulnerability exists in Jenkins Fortify CloudScan Plugin 1.5.1 and earlier in ArchiveUtil.java that allows attackers able to control rulepack zip file contents to overwrite any file on the Jenkins master file system, only limited by the permissions of the user the Jenkins master process is running as. |
| CVE-2018-1199 | Medium | 2018-03-16 | No exploit published | No public exploit | Spring Security (Spring Security 4.1.x before 4.1.5, 4.2.x before 4.2.4, and 5.0.x before 5.0.1; and Spring Framework 4.3.x before 4.3.14 and 5.0.x before 5.0.3) does not consider URL path parameters when processing security constraints. By adding a URL path parameter with special encodings, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification. Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. In this particular attack, different character encodings used in path parameters allows secured Spring MVC static resource URLs to be bypassed. |
| CVE-2018-1298 | Medium | 2018-02-09 | No exploit published | No public exploit | A Denial of Service vulnerability was found in Apache Qpid Broker-J 7.0.0 in functionality for authentication of connections for AMQP protocols 0-8, 0-9, 0-91 and 0-10 when PLAIN or XOAUTH2 SASL mechanism is used. The vulnerability allows unauthenticated attacker to crash the broker instance. AMQP 1.0 and HTTP connections are not affected. An authentication of incoming AMQP connections in Apache Qpid Broker-J is performed by special entities called "Authentication Providers". Each Authentication Provider can support several SASL mechanisms which are offered to the connecting clients as part of SASL negotiation process. The client chooses the most appropriate SASL mechanism for authentication. Authentication Providers of following types supports PLAIN SASL mechanism: Plain, PlainPasswordFile, SimpleLDAP, Base64MD5PasswordFile, MD5, SCRAM-SHA-256, SCRAM-SHA-1. XOAUTH2 SASL mechanism is supported by Authentication Providers of type OAuth2. If an AMQP port is configured with any of these Authentication Providers, the Broker may be vulnerable. |
| CVE-2017-1000402 | Medium | 2018-01-26 | No exploit published | No public exploit | Jenkins Swarm Plugin Client 3.4 and earlier bundled a version of the commons-httpclient library with the vulnerability CVE-2012-6153 that incorrectly verified SSL certificates, making it susceptible to man-in-the-middle attacks. |
| CVE-2017-1000397 | Medium | 2018-01-26 | No exploit published | No public exploit | Jenkins Maven Plugin 2.17 and earlier bundled a version of the commons-httpclient library with the vulnerability CVE-2012-6153 that incorrectly verified SSL certificates, making it susceptible to man-in-the-middle attacks. Maven Plugin 3.0 no longer has a dependency on commons-httpclient. |
| CVE-2017-12197 | Medium | 2018-01-18 | No exploit published | No public exploit | It was found that libpam4j up to and including 1.8 did not properly validate user accounts when authenticating. A user with a valid password for a disabled account would be able to bypass security restrictions and possibly access sensitive information. |
| CVE-2017-15707 | Medium | 2017-12-01 | No exploit published | No public exploit | In Apache Struts 2.5 to 2.5.14, the REST Plugin is using an outdated JSON-lib library which is vulnerable and allow perform a DoS attack using malicious request with specially crafted JSON payload. |
| CVE-2014-0219 | Medium | 2017-11-15 | No exploit published | No public exploit | Apache Karaf before 4.0.10 enables a shutdown port on the loopback interface, which allows local users to cause a denial of service (shutdown) by sending a shutdown command to all listening high ports. |