Java
Monthly
Denial of service in JavaCV's IPCameraFrameGrabber affects all versions prior to 1.5.14, where an attacker-influenced MJPEG stream can supply an oversized Content-Length header that overflows a 32-bit buffer-doubling loop and traps the frame-grabbing thread in a permanent 100% CPU spin. Unauthenticated remote attackers can trigger this either by operating a malicious or compromised IP camera endpoint the application connects to, or by tampering with the plaintext HTTP response in transit; the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms no privileges or user interaction are required and that impact is limited to availability. No public exploit code was identified at time of analysis and there is no CISA KEV listing, and the vendor has released a fixed version (1.5.14).
Authenticated workspace members can exploit an insecure direct object reference in Shaiwz data-platform-open (through commit efeacd3) to read, modify, or delete datasources belonging to other workspaces by supplying sequential numeric IDs. The flaw exposes JDBC credentials and database schemas via endpoints /datasource/detail, /listSchemaTable, /tableDetail, /update, and /delete, with no per-workspace authorization check. No public exploit code identified; exploitation requires a valid workspace-member account (PR:L) and no user interaction, and the impact is assessed as a moderately serious authorization flaw rather than an emergency-tier vulnerability.
Unauthenticated authorization bypass in the OpenNMS Meridian and Horizon REST API lets any remote attacker who can reach /rest/** read the monitored inventory and create, modify, or delete resources without credentials. The flaw arises because the Spring Security intercept-url rules match the HTTP method as a case-sensitive uppercase token and the filter chains terminate without a deny rule, so a request using a non-canonical method token (for example 'get' or 'put' instead of 'GET'/'PUT') matches no rule and is served without authentication; the /rest/alarms chain additionally leaks whether a specific alarm exists via a difference in the response. All pre-fix Meridian and Horizon versions in default configuration are affected, the vendor-supplied CVSS 3.1 base score is 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, i.e. unauthenticated and low complexity), and no public exploit code was identified at time of analysis; the practical limiting factor is deployment posture, since the vendor states these products belong on private networks and should not be Internet-facing.
Cross-site scripting in HtmlUnit Neko (htmlunit-neko) before 5.4.0 lets an unauthenticated remote attacker smuggle executable markup out of HTML sanitizers and content filters that use the library to serialize parsed HTML. HTMLWriterFilter fails to entity-encode decoded TEXTAREA and TITLE text, so entity-encoded markup supplied inside those elements is decoded on parse and re-emitted as literal markup by printCharacters(); output rendered by a victim's browser executes in that browser, which is why the CVSS 3.1 score of 7.2 (High) carries a scope change (S:C) on the vector AV:N/AC:L/PR:N/UI:N. The flaw is only reachable in a parse-transform-serialize pipeline that both relies on HTMLWriterFilter for its output and renders that output in a browser, and no public exploit code was identified at time of analysis; the issue is fixed in 5.4.0.
Denial of service in Junrar before 7.6.1 allows unauthenticated remote attackers to exhaust CPU and archive-processing worker capacity by supplying a crafted RAR4 archive. The archive drives the built-in RAR virtual machine into an infinite loop via a VM_JMP instruction targeting an address at or beyond the prepared program's codeSize; because the VM cannot execute native code, the supported impact is availability loss rather than code execution. No public exploit code or confirmed active exploitation has been identified, and the flaw is fixed in version 7.6.1.
Denial of service in Eclipse Vert.x's vertx-pg-client component allows an attacker controlling the PostgreSQL server or positioned as a man-in-the-middle on an unencrypted connection to crash the client application. The flaw resides in the binary array decoder (DataTypeCodec.binaryDecodeArray), which allocates a Java array based on a server-supplied 32-bit dimension count without upper bound checking, leading to a multi-gigabyte heap allocation and OutOfMemoryError. Affected versions include 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0. Exploitation requires no authentication (PR:N) but does require control of the database server or a MITM position on a non-TLS connection (AC:H), and no public exploit code has been identified at time of analysis.
Eclipse Vert.x DB2 Client versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 can deserialize attacker-controlled DRDA UDT column data, enabling remote code execution if a Java deserialization gadget chain is present on the classpath or denial of service otherwise. The affected component is io.vertx:vertx-db2-client, and exploitation requires an application to connect to a malicious or man-in-the-middle DRDA server that returns a result-set column tagged with FDOCA LID 0x50; legitimate DB2 servers never emit that type, and client-side TLS is disabled by default. The CVSS 4.0 score is 9.2 with PR:N, but practical exploitation requires attacker server-side/MITM position (AC:H) and, for RCE, a classpath gadget chain; no public exploit identified at time of analysis, and the real-world blast radius is narrower than the score alone suggests.
Unbounded direct-memory allocation in Eclipse Vert.x's MSSQL client (io.vertx:vertx-mssql-client) lets a malicious, compromised, or man-in-the-middle SQL Server endpoint crash a connecting client application by streaming TDS packets that never set the END_OF_MESSAGE status flag. Affected versions are [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] and 5.2.0: the TDS message decoder aggregates inbound packets into a composite direct-memory buffer with no cumulative size cap, so the buffer grows until memory is exhausted and the process dies (availability impact only, with no confidentiality or integrity loss, per the assessed CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H). The flaw is reachable before authentication completes, meaning no valid server credentials are required, but exploitation is not available to an arbitrary remote attacker - it demands control of, or a man-in-the-middle position on, the server side of the connection, which is why access complexity is rated High. No public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in Eclipse Vert.x HTTP proxy (io.vertx:vertx-http-proxy) affects versions 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, allowing remote unauthenticated attackers to cause indefinite heap allocation. Exploitation requires the application to explicitly configure an intercepting body transformer-a non-default, developer-enabled feature-and the flaw lies in the transformer interceptor's reliance on a max buffered bytes limit that fails to keep per-request buffers bounded. No public exploit code has been identified at time of analysis; the CVSS 4.0 score is 8.7 with high availability impact.
Unauthenticated remote denial of service in FasterXML Jackson 1.x (jackson-mapper-asl 1.8.3 and 1.9.2-1.9.13) allows an attacker to crash or exhaust the stack of an application that deserializes untrusted JSON via ObjectMapper.readValue by supplying deeply nested input. The flaw is CWE-674 uncontrolled recursion: the Jackson 1.x parser performs recursive descent without a configurable nesting-depth limit. No public exploit code identified at time of analysis, and Jackson 2.x deployments are unaffected because that branch enforces StreamReadConstraints depth limits by default.
Arbitrary file access and operating-system command execution in Stirling-PDF prior to 2.13.2 are reachable by an authenticated administrator who uploads a crafted SQL file to POST /api/v1/database/import-database on instances running the default H2 database backend with security mode enabled. DatabaseService.validateSqlContent() splits the normalized input on semicolons and accepts a statement if it merely contains an allowed keyword, so dangerous H2 constructs such as FILE_READ, CSVWRITE and CREATE ALIAS slip past the whitelist and execute when RUNSCRIPT processes the import; the demonstrated chain writes attacker-controlled startup files to a user-site location and triggers the application's Python interpreter to load them, yielding command execution as the JVM service account. The CVSS 3.1 base score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) reflects network reachability with full confidentiality, integrity and availability impact and a scope change, but PR:H means the attacker must already hold administrative privileges and non-H2 deployments are unaffected; no public exploit code identified at time of analysis, and the issue is fixed in version 2.13.2.
Unbounded HTTP request-body buffering in the Model Context Protocol (MCP) Java SDK lets an unauthenticated remote client exhaust the JVM heap and render an MCP server unavailable. The flaw affects the Servlet-based SSE, Streamable HTTP, and Stateless server transports in io.modelcontextprotocol.sdk:mcp 0.8.0-0.12.0, mcp-core 0.13.0-0.18.3, 1.0.0-1.1.3, and 2.0.0-M1-2.0.0; a client simply streams an arbitrarily large POST body (including via chunked transfer encoding) until OutOfMemory conditions make the process unresponsive. Rated CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affecting availability only, the impact is materially reduced for deployments that require authentication, enforce Origin/Host validation, or sit behind a reverse proxy, load balancer, or API gateway with a maximum-body-size limit, all of which reject the oversized request before the vulnerable read; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Improper neutralization of special elements (CWE-74) in Microsoft's Azure Storage client libraries - azure-storage-blob-batch 1.0.0 and the Azure Storage Blobs client library for Java - allows an attacker who already holds low-level authorized access (PR:L) to escalate privileges over the network by routing crafted input through the library into a downstream component that does not sanitize it. The weakness requires no user interaction (UI:N) and produces high integrity and availability impact (I:H/A:H) with no confidentiality loss (C:N), which is consistent with Microsoft's 'Code Injection' tagging. No public exploit code has been identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' and the issue as not automatable, so real-world urgency sits below what the 8.1 base score alone would imply.
SAP MII's administrative account-provisioning function fails to enforce proper authorization boundaries, enabling an attacker who already holds MII administrator privileges to craft a request that provisions an account with elevated privileges on the underlying Java application server. This can extend compromise beyond MII to the host, with high confidentiality, integrity, and availability impact, and is reflected in a CVSS 3.1 score of 9.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H). No public exploit code or confirmed active exploitation was identified at time of analysis.
Out-of-band XML External Entity (XXE) injection in Eclipse JAXB RI (jaxb-ri) lets an unauthenticated remote attacker read local files when an application unmarshals attacker-influenced XML through the affected JAXB factory helpers (XmlFactory in the core and xsom modules). The pre-patch code relied solely on XMLConstants.FEATURE_SECURE_PROCESSING, so on JAXP/SAX/DocumentBuilder implementations where that single feature does not disable DOCTYPE declarations, external general entities, external parameter entities, or external DTD loading, external entity resolution remains possible and file content can be exfiltrated out-of-band. Exploitation requires both conditions to hold - untrusted XML reaching JAXB unmarshalling, plus a parser stack where secure processing alone is insufficient - which is why the vector carries AC:H and the score is 8.3 (High) on both the supplied CVSS 4.0 vector and the independently assessed CVSS 3.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L). No confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
Denial of service in Google Guava 4.0 through 33.7.1 can be triggered by remote unauthenticated attackers who can supply crafted Java serialization streams containing CompactHashMap, CompactHashSet, or MapMakerInternalMap objects, causing Guava to allocate an attacker-controlled backing array without throttling and exhaust memory with OutOfMemoryError. This is a genuine but conditional availability-only risk: exploitation requires the target application to perform Java native deserialization (ObjectInputStream.readObject) on attacker-influenced input, and any authentication or authorization in front of the deserializing endpoint further limits reach; no code execution or data disclosure results. A vendor fix is available in Guava 33.7.2, and no public exploit identified at time of analysis.
Unbounded memory allocation in Xerial snappy-java before 1.1.10.9 lets unauthenticated remote attackers exhaust the JVM heap by declaring an oversized uncompressed length in a compressed stream header, triggering OutOfMemoryError and denial of service. Any application that passes externally supplied bytes to Snappy.uncompress, Snappy.uncompressString, SnappyInputStream or SnappyFramedInputStream - for example Kafka, Hadoop/Spark or other services using snappy-java transitively - is in scope, and a handful of crafted bytes can force allocations of up to 2 GB before decompression validates the data. Impact is limited to availability (CVSS:4.0 base 8.7; assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) with no data disclosure or modification, and no public exploit was identified at time of analysis; the practical constraint is reachability, since applications that only decompress trusted internal data are not meaningfully exposed.
Token validation bypass in Apache CXF's STSTokenValidator and Security Token Service (STS) allows unauthenticated remote attackers to impersonate another user by presenting a forged UsernameToken or self-signed SAML Assertion whose 32-bit Java hash collides with an entry already held in the validated-token cache. Because a cache hit is treated as proof of prior validation, the forged token is accepted without password validation, signature trust verification, or any call to the STS, and can subsequently be exchanged through STS validation or renewal for STS-signed tokens issued for the victim identity. Exploitation is constrained in practice: the target deployment must use STSTokenValidator or STS token validation/renewal with the validated-token cache enabled, and a legitimately validated token for the identity being impersonated must already be present in that cache; no public exploit code has been identified at time of analysis, KEV status is negative, and EPSS is low (~0.17%, 6th percentile), yet the headline CVSS of 9.1 reflects high confidentiality and integrity impact if the preconditions are met. Vendor patches are available in 4.2.4, 4.1.9, and 3.6.13.
Keystream reuse in the native one-shot CTR packet cipher of Bouncy Castle for Java LTS before 2.73.13 allows remote attackers to recover plaintext from ciphertext alone, without knowledge of the key. Exploitation is unauthenticated but conditional: the application must use the native one-shot CTR path with a 13-, 14-, or 15-byte IV, leaving only a 1-, 2-, or 3-byte block counter (256, 65,536, or 16,777,216 blocks), and must pass a single input longer than that counter space so the counter wraps and the keystream restarts within the packet. The call returns the full input length with no exception, so the caller receives no signal that some bytes were transformed under a repeated keystream; the resulting two-time-pad condition permits plaintext recovery. No public exploit code has been identified at time of analysis, and the non-default short-IV native deployment requirement keeps realistic exposure narrow, which is why this is assessed as AC:H rather than trivially exploitable.
Arbitrary memory disclosure and denial of service in Hazelcast allow a client that can reach a cluster member's listening port to read arbitrary data from that member's Java heap, off-heap storage and JVM process address space, to crash members, and - in some Hazelcast Enterprise Edition configurations - to corrupt memory with possible remote code execution. All editions prior to 5.4.5, 5.5.10, 5.6.1 and 5.7.0 are affected in both the slim and full distributions, and the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a low-privileged client credential where client authorization is enforced, while in default deployments with Hazelcast Security disabled any reachable client can connect without credentials; the vendor's CVSS 4.0 score of 9.3 assumes PR:N. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, but vendor-released patches exist (5.4.5, 5.5.10, 5.6.1, 5.7.0) and the vendor's own hardening guidance - enabling security, enforcing client authorization and defining an explicit zero-config Compact serialization allowlist - directly addresses the exposure, making this a genuine high-priority vulnerability rather than an inflated score.
SQL injection in the generated reactive entity-list endpoints of JHipster-produced applications (generator-jhipster versions 7.0.0 up to, but not including, 9.4.0) lets an authenticated user inject arbitrary SQL through the attacker-controlled `sort` request parameter on `GET /api/<entity>?sort=...` endpoints. Because the generated R2DBC code passes the sort property into the SQL ORDER BY clause unvalidated and unquoted, and the driver runs it over the simple query protocol, semicolon-separated statements are executed as well - enabling reads of sensitive tables such as `jhi_user` password hashes, modification or deletion of data, and table drops (CVSS 3.1 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Exploitation requires the app to be the reactive WebFlux + Spring Data R2DBC + SQL stack, and an account is needed, though the default self-registration flow lets a low-privileged one be self-provisioned; the vendor-released fix is version 9.4.0, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Cross-host request replay in AsyncHttpClient (AHC) before 3.0.13 and 2.16.1 can disclose the original origin's request path, Host header, Authorization credentials, or even a plaintext request to a completely different destination when an application's ResponseFilter fails over or retries a request onto a different base origin (host, scheme, or port) or downgrades HTTPS to HTTP. The assessed vector is unauthenticated from the network perspective (PR:N, AV:N), but exploitation hinges on a concrete application-side prerequisite: a ResponseFilter (or equivalent retry/failover code path) that replays requests across origins - default AHC usage with same-host retries is unaffected, and AC:H/AT:P reflect the specific sequencing that must occur. No public exploit code and no confirmed active exploitation were identified at time of analysis, and because the impact depends on configuration rather than an attacker-reachable endpoint, the CVSS 4.0 score of 9.4 and the independent CVSS 3.1 assessment point in different directions; prioritization should be driven by whether a cross-host replaying filter is deployed.
Connection-pool reuse in the AsyncHttpClient (AHC) Java library, versions prior to 3.0.13 and 2.16.1, lets an authenticated principal inherit an HTTP/1.1 socket that was authenticated by a different principal under NTLM, Kerberos, or SPNEGO/Negotiate, causing the backend to execute the second request as the first identity - a full read/act-as impersonation (VC:H/VI:H). The flaw is that the connection-pool partition key omits the authenticated principal for connection-oriented authentication schemes, while Basic and Digest, which authenticate every request, are not affected. Exploitation requires an authenticated user (PR:L) on a deployment that shares one client/pool across multiple identities, and it is timing-dependent (AC:H, AT:P) because a suitably authenticated pooled socket must exist and be handed to the mismatched request; no public exploit code was identified at time of analysis and there is no KEV entry, though EPSS data was not provided. The vendor-released patch is AsyncHttpClient 3.0.13 (3.x line) or 2.16.1 (2.x line).
Digest mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.12 allows a rogue or on-path peer to be accepted as the authenticated server: when a Digest challenge advertises qop="auth-int" as the only supported quality-of-protection, the client negotiates it but cannot compute the expected rspauth, treats that as unverifiable-but-nonfatal, and accepts a response whose rspauth value is invalid. The flaw is network-reachable, unauthenticated and requires no user interaction (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, 8.8), with the primary impact on integrity (VI:H) consistent with server impersonation rather than the data theft implied by the 'Information Disclosure' tag. It only affects applications that use AHC's Digest Realm with mutual authentication and connect to a peer offering an auth-int-only challenge; deployments where the server offers 'auth' or 'auth,auth-int' are unaffected because AHC prefers and verifies 'auth'. No public exploit code and no confirmed active exploitation were identified at time of analysis; the vendor-released patch is version 3.0.13.
Cleartext credential disclosure in AsyncHttpClient (AHC) before 3.0.12 on the 3.x line and before 2.16.1 on the 2.x line causes a client configured to use an HTTP proxy to write the origin request and its Authorization credentials onto a still-plaintext proxy connection when the proxy rejects the CONNECT with anything other than 200, because the client infers an established tunnel from the last request method rather than the CONNECT result. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 HIGH), this is an unauthenticated, confidentiality-only issue: Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. Exploitation is limited to environments where the victim application routes through an HTTP proxy and the attacker controls or can man-in-the-middle the client-to-proxy hop; no public exploit identified at time of analysis.
Credential disclosure in the AsyncHttpClient (AHC) Java library allows a malicious or compromised origin server or proxy to capture plaintext-recoverable usernames and passwords from applications that configure HTTP credentials via Realm.Builder. When the attacker returns a WWW-Authenticate or Proxy-Authenticate challenge labeled 'Digest' but with the nonce parameter omitted or empty, versions prior to 3.0.13 (3.x) and 2.16.1 (2.x) silently fall back to Basic authentication and resend the credentials in reversible Base64, defeating the entire purpose of Digest. Exploitation is unauthenticated from the network (CVSS v4.0 8.7, AV:N/PR:N, independent assessment CVSS v3.1 C:H/I:N/A:N), but requires the attacker to control or tamper with the authentication challenge, so it is not exploitable against arbitrary endpoints; no public exploit code or CISA KEV entry was identified at time of analysis.
Connection-pool key scoping in AsyncHttpClient (AHC) 2.0.0 through 3.0.13 omits identity-defining fields for Kerberos, SPNEGO, NTLM, authenticated proxy and SOCKS/CONNECT login paths, so a request can be handed a pooled keep-alive socket that was already authenticated as an entirely different identity and then execute under that first identity's credentials, exposing the other identity's data or authority. Reachability is conditional: the application must use Kerberos/SPNEGO/NTLM, an authenticated proxy realm, or SOCKS/CONNECT proxy logins, and specifically the ambiguous cases where login has no configured principal, where realms are proxy realms, where distinct identities share a user name, or where proxy logins are used - clients using only HTTP Basic/Digest or a single identity/principal are not affected. Rated CVSS 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, CWE-346 Origin Validation Error); exploitation depends on timing the reuse of an already-authenticated socket across multiplexed callers, and there is no public exploit identified at time of analysis and no CISA KEV listing. Vendor-released patch: 3.0.14.
Unbounded WebSocket permessage-deflate decompression in the AsyncHttpClient (AHC) Java library versions 2.2.0 through 3.0.13 allows a malicious or compromised WebSocket peer to exhaust the JVM heap of the connecting application by sending a small compressed message that inflates into a very large Netty buffer. The flaw is remote, requires no authentication or user interaction from the peer side (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), but it only triggers when the client application itself opens an outbound WebSocket connection with permessage-deflate compression negotiated - meaning the victim must connect to an attacker-controlled endpoint or be exposed to a man-in-the-middle. Impact is availability-only: no confidentiality or integrity loss, and no public exploit code has been identified at time of analysis. The issue is fixed in version 3.0.14.
Apache Commons BCEL before 6.13.0 caches attacker-supplied class files under the symbolic name declared inside the class file itself rather than validating that name against the name it was requested under, so a class loaded via AbstractClassPathRepository or ClassLoaderRepository can poison a repository entry keyed to a different, colliding name. Applications that load class files from an attacker-influenceable classpath or input stream and later rely on the repository's name-keyed lookups or verification results can be induced to operate on the wrong class, producing an integrity-only impact (no confidentiality or availability effect). The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N - network-reachable and unauthenticated, but requiring a specific name-collision and subsequent lookup sequence (AT:P), so it is not a fully automatable drive-in exploit; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor's elevated 8.2 CVSS 4.0 score reflects the integrity impact alone.
Local authenticated attackers who share a writable Java temporary directory with a victim JVM can exploit a time-of-check/time-of-use race in lz4-java 1.7.0 through 1.11.3 to replace the native LZ4 library extracted by net.jpountz.util.Native.load(), potentially executing native code with the victim's privileges. The vulnerability is local-only and requires winning a race against native-library extraction, plus a shared java.io.tmpdir and native binding use; hardened configurations may instead fail loading and fall back to Java implementations. Version 1.11.4 fixes the issue; no public exploit identified at time of analysis.
Denial of service in the RabbitMQ Java client (com.rabbitmq:amqp-client / rabbitmq-java-client) prior to the fixed release allows a single small, malformed JSON-RPC message body to permanently hang or crash a JVM. The deprecated com.rabbitmq.tools.jsonrpc tooling - JsonRpcServer and JsonRpcClient - falls back to DefaultJsonRpcMapper when no mapper is supplied, and that mapper hands raw message bodies straight to JSONReader.read(), whose string and comment scanners fail to stop at CharacterIterator.DONE. An input truncated inside a quoted string drives the parser into an unending append loop that exhausts the heap with OutOfMemoryError, while an unterminated // line comment pins a thread at 100% CPU indefinitely; neither condition is recoverable per request. Publicly available exploit code exists (a proof-of-concept is included in the vendor advisory) and the CVE is tracked by CISA SSVC with Exploitation=poc and Technical Impact=partial, though EPSS probability is low at roughly 0.49% (40th percentile) and no CISA KEV listing is present. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates a network-reachable, unauthenticated availability-only impact.
Code injection in Microsoft Kiota 0.5.0 through pre-1.35.0 allows attacker-controlled text embedded in an OpenAPI description to break out of the generated Java or PHP documentation comment and execute in the consuming application or build environment once that generated source is compiled and loaded (Java) or loaded (PHP). The flaw is reachable unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:R) but requires user interaction: a developer or CI pipeline must generate client code from an untrusted or tampered spec and then build or load the output, making this a build-time/supply-chain path rather than an attack on already-deployed runtime services. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV; CVSS 3.1 base score is 8.8, and the issue is fixed in 1.35.0.
Unauthenticated directory traversal in kkFileView 5.0.0 through 5.0.2 lets remote attackers create arbitrary directories and write files outside the intended fileDir root via the fileUpload, createFolder, and existsFile endpoints, which concatenate an attacker-supplied 'path' parameter into the upload base path without any validation. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) confirms that no credentials and no user interaction are needed, and that the impact is integrity-only (C:N/A:N), meaning the attacker can plant content beyond the configured storage root but gains no direct read or availability effect. Exploitation is gated chiefly by exposure rather than configuration - kkFileView is typically deployed as an internal document-preview service - and no public exploit code was identified at time of analysis, so internet-facing, unauthenticated reachability of the upload endpoints is the real-world precondition for mass abuse.
Remote code execution in LibreOffice Calc allows attackers to execute arbitrary Java code by embedding a crafted external data link that loads a malicious Java database driver from a remote URL when the document is opened. This affects LibreOffice versions prior to the fix that enforces file URLs for Java class-path entries. Exploitation requires user interaction (opening the document) and a local attack vector; no public exploit has been identified at time of analysis, yet the high-severity impact can fully compromise the user's system.
Unauthenticated remote code execution is possible in Perforce P4 Search container images prior to 2026.4.2 due to an exposed Java Debug Wire Protocol (JDWP) interface. An attacker with network access to the JDWP port can execute arbitrary code as the P4 Search service account, potentially compromising the connected P4 Server. No public exploit code has been identified at time of analysis, but the issue is rated critical (CVSS 9.5 in CVSS 4.0, assessed as CVSS 3.1 with scope change) and requires the debug interface to be reachable (attack prerequisite AT:P), making it a genuine high-priority issue rather than a high-CVSS-but-low-risk artifact.
Improper authentication in AhsayCBS up to version 10.3.2 lets an unauthenticated remote attacker bypass credential verification by manipulating the 'random' parameter processed by the checkSysPwd routine in the API component (com/ahsay/obs/api/ApiStructsAction.java). Exploitation requires only network reachability to the exposed AhsayCBS API/management interface and publicly available exploit code exists, so deployments that leave the console internet-facing or broadly reachable are the most at risk. The assessed impact is limited to partial confidentiality, integrity, and availability effects, and no confirmed active exploitation (CISA KEV) has been reported, making this a moderate-priority issue that is nonetheless straightforward to trigger where the API is exposed.
Bouncy Castle for Java before 1.86 fails to tie a Remove proposal in an MLS (RFC 9420) external commit to the joining party, allowing any holder of the group's public GroupInfo to evict an arbitrary member and take over that member's slot in the ratchet tree. Exploitation requires only that an application use the library's MLS module and accept external commits through the public Group.externalJoin / Group.handle API on an affected version; no group membership, credential, or user interaction is needed, and the missing credential check existed only in the gRPC interop harness, protecting none of the other API callers. The vendor rates this 8.7 (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N), and there is no public exploit identified at time of analysis, though the flaw is trivially reachable by anyone who legitimately receives GroupInfo.
Signature-verification bypass in Bouncy Castle for Java before 1.86 lets a phantom signer be accepted in BLS12-381 aggregate signature verification. The faulty BLS12_381BasicScheme.keyValidate() trusts the public key's own ECCurve object during the prime-order subgroup check, so an attacker-supplied ECPoint built on a foreign curve that merely shares BLS12-381's field characteristic - with its cofactor forged to 1 - passes validation despite not being a G1 point; in the pairing implementation such a point contributes the identity in the target group, so an aggregate signature verifies even though it contains no signature for that key/message pair. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key, since the standard 48-byte compressed-point decoder always supplies the canonical curve; no public exploit has been identified at time of analysis, and the assessed impact is high integrity compromise without confidentiality or availability loss (CVSS:4.0 base 7.1, network vector, no privileges required).
Bouncy Castle for Java's Messaging Layer Security (MLS, RFC 9420) implementation before 1.86 fails to bind an X.509 credential to a LeafNode's signature_key, allowing an unauthenticated remote attacker to present a victim's certificate while signing the LeafNode and KeyPackage with an unrelated key and be accepted under the victim's identity. In an MLS deployment that uses X.509 credentials and admits external commits without an independent credential-admission check, the attacker can be admitted as the victim, evict the victim via resynchronization (which compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. The flaw is rated CVSS 9.2 (CVSS:4.0) / 9.2-equivalent high impact with the vendor patch available in 1.86; no public exploit code or confirmed active exploitation was identified at time of analysis, and deployments using only basic credentials are explicitly unaffected. Note the assessed attack complexity is High because the MLS/X.509 path must be in use and the application must lack its own credential-admission validation.
Bouncy Castle for Java 1.81 through 1.85.2 fails to verify that a third-party OpenPGP signature was issued by a component key actually granted certification authority, so the high-level certificate API will attribute an attacker-made certification or trust delegation to the certificate's offline primary key. An attacker must already hold the private key of a restricted subkey (one bound only with SIGN_DATA, or a legacy RSA encryption subkey whose algorithm can still sign) that lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER flag; they can then issue a positive User ID certification or a full-trust depth-one direct-key delegation that getCertificationBy()/getDelegationBy() report as a valid chain, and any application treating isValid() as an identity or trusted-introducer decision will accept the forged assertion at the primary key's authority. The flaw is a privilege promotion of an already-compromised subkey rather than a key-recovery attack, no public exploit code has been identified at time of analysis, and vendor fixes are available in 1.86.
Signature misattribution in the high-level OpenPGP API of Bouncy Castle for Java before 1.86 lets an attacker who holds a third party's public signing subkey - entirely public material - graft that subkey onto their own primary key with a Subkey Binding signature that omits both the Key Flags subpacket and the embedded Primary Key Binding (cross-certification) signature. Because OpenPGPCertificate.isSigningKey() and verifyEmbeddedPrimaryKeyBinding() resolved the subkey's key flags two different ways, the grafted subkey was treated as signing-capable while being exempt from the cross-certification requirement, so OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true for a message the subkey genuinely signed and reported the attacker's certificate as its issuer; GnuPG rejects the identical certificate and message. This yields misattribution of an existing genuine signature under an attacker-chosen, self-asserted identity - no private key is recovered and no new signature can be forged - and only affects relying parties that pin trust on the subkey's fingerprint or key ID while taking the signer identity from the enclosing certificate. The vendor rates it 8.2 (CVSS 4.0) with integrity-only impact; an independent assessment scores it CVSS 3.1 8.2-equivalent integrity-only (AC:H, PR:N, UI:N), no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
In-place encryption over a secret key buffer in Bouncy Castle for Java LTS before 2.73.13 can silently replace freshly produced ciphertext with the raw AES key, because native one-shot packet ciphers release read-only input arrays with JNI mode 0 and a later copy-back overwrites the output. The trigger is narrow and application-dependent-it requires the non-default pattern of passing the same Java array as both input and destination (for example, encrypting over KeyParameter.getKey()) on a JVM that copies rather than pins JNI array elements-so real-world exploitability is far lower than the 8.2 base score implies; bcprov, pure-Java packet ciphers, and native streaming modes are unaffected. No public exploit identified at time of analysis.
Improper validation of the digestAlgorithm/authAttrs pairing in Bouncy Castle's CMS AuthenticatedData handling lets a man-in-the-middle make the parser return authenticated attributes that the message MAC never covered, in Bouncy Castle for Java before 1.86, Bouncy Castle LTS before 2.73.13, and the BC-FJA/FIPS releases (bcpkix-fips before 1.0.13/2.0.13/2.1.13 and bcutil-fips before 2.0.8/2.1.8). Because the streaming CMSAuthenticatedDataParser picks in its constructor whether the MAC covers the DER encoding of authAttrs or the eContent OCTET STRING based solely on whether digestAlgorithm is present - a field that precedes authAttrs in the SEQUENCE - a message crafted with digestAlgorithm absent but authAttrs present passes the genuine content-MAC check and then exposes attacker-chosen attributes through getAuthAttrs(). Exploitation is unauthenticated at the network layer (CVSS:4.0 PR:N, no keys of either the key-encryption or content-MAC type are needed) but requires an in-transit tampering position and a victim application that makes an authorization, routing, or labelling decision from those attributes; the eContent payload itself remains MAC-bound, no public exploit has been identified at time of analysis, and signals conflict on whether this merits urgent prioritization (vendor CVSS 4.0 8.7 with AC:L versus an independent CVSS 3.1 assessment of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Certificate-validation bypass in Bouncy Castle for Java lets a PKIXCertPathReviewer accept an end-entity certificate that violates a NameConstraints extension imposed by its own issuing CA, causing isValidCertPath() to return true with an empty error list for a chain the real PKIX validator rejects. Affected are BC-Java before 1.86, BC-LTS-Java before 2.73.13, and BC-FJA (bcpkix-fips) before 1.0.13 / 2.0.13 / 2.1.13; exploitation requires an application that uses org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer (or the legacy org.bouncycastle.x509 copy) to make the trust decision rather than the unaffected CertPathValidator "PKIX"/"BC", and a chain whose leaf actually breaches the CA's permitted or excluded subtrees. No public exploit code has been identified at time of analysis, the vulnerability is unauthenticated (CVSS PR:N) per the vendor vector, and the vendor scores it CVSS 4.0 8.7 (High) for high integrity impact; note that an independent assessment rates attack complexity higher (CVSS 3.1 AV:N/AC:H) because the exposure depends entirely on non-default application architecture rather than on anything the attacker controls.
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Opening a crafted untrusted document in Apache OpenOffice 4.1.16 and earlier can execute arbitrary code at the opening user's privilege level, including code fetched from a remote location, because the document's Java integration fails to authorize the external links it resolves. Exploitation is unauthenticated but requires user interaction: Java runtime integration must be enabled (the default configuration) and the victim must actively open an attacker-supplied file, making social engineering the primary delivery vector. There is no public exploit identified at time of analysis, no confirmed active exploitation (CISA KEV and SSVC both report none), and EPSS is only 0.22% (12th percentile); a vendor fix is expected in Apache OpenOffice 4.1.17, which is still in the release-candidate phase, so the recommended interim mitigation is to disable Java runtime integration in the Preferences dialog or to avoid opening untrusted documents entirely.
Denial of service in the Java bindings of Apache Thrift (all versions before 0.25.0) allows an accepted protocol peer to exhaust server resources by triggering unbounded allocation while Thrift messages are received and parsed. Per the assessed CVSS vector (PR:L), the attacker must already be an authenticated or otherwise accepted client of the Thrift service rather than an anonymous internet actor, which materially narrows exposure for deployments that only accept connections from trusted peers. The impact ceiling is availability loss only - no data disclosure, integrity impact, or code execution is declared - and no public exploit code or CISA KEV entry is associated with this CVE at time of analysis; the vendor-released fix is version 0.25.0.
Resource-exhaustion denial of service in Apache Thrift's Java TSaslNonblockingServer component allows remote attackers to drive the service into an unresponsive state by consuming server resources without limit (CWE-770). All Apache Thrift releases before 0.25.0 are affected, and the CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) confirms the attack is network-reachable and requires no credentials or user interaction once an exposed TSaslNonblockingServer endpoint is reachable; impact is confined to availability, with no confidentiality or integrity loss. Exploitation is only possible against deployments that specifically use the Java non-blocking SASL server class, which limits real-world exposure since blocking servers and non-SASL configurations are unaffected; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so this is a patch-now hygiene item rather than an emergency.
Repeated, attacker-triggered exceptional conditions in the Apache Thrift Java bindings can leak server-side resources and degrade or exhaust a Thrift RPC service running any version before 0.25.0. The issue is remotely reachable without authentication (CVSS PR:N) and needs no user interaction, but the assessed impact is availability only - there is no confirmed confidentiality or integrity effect, so this is a denial-of-service exposure rather than a data-compromise issue. A CVSS 4.0 attack-requirement flag (AT:P) indicates a specific precondition must be met to drive the vulnerable error path, meaning not every request triggers the leak; the precise condition is not specified in the public advisory text, and no public exploit identified at time of analysis. Deployments not using the Java bindings, or already on 0.25.0 or later, are unaffected.
Uncontrolled recursion in the Dart and Java ME bindings of Apache Thrift before 0.25.0 lets a remote, unauthenticated attacker crash or hang a service by sending a Thrift message containing deeply nested or self-referential structures that exhaust the parser's stack. Impact is availability-only (no confidentiality or integrity effect per the assessed CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and the vulnerable surface is confined to deployments that deserialize untrusted data using the Dart or Java ME bindings, so most Thrift users on Java SE, C++, Python, or Go are not exposed. No public exploit code or confirmed active exploitation was identified at time of analysis; the CVSS 4.0 base score of 8.7 should be read alongside the narrow binding-specific exposure, which makes real-world priority moderate rather than critical.
Cleartext exposure of directory data in Apache Directory LDAP API 2.1.0 through 2.1.8 occurs when an application sends a Search request and only afterwards starts a StartTLS extended operation, allowing response data to be returned in plain text before the TLS handshake completes. Exploitation requires the attacker to already hold a network interception position (passive eavesdropping or active man-in-the-middle) between the LDAP client and the directory server; no authentication or user interaction is needed on the target application itself, but the on-path prerequisite substantially limits realistic exploitation. There is no public exploit identified at time of analysis, EPSS is only 0.13% (2nd percentile) with no CISA KEV entry, and a vendor-released fix is available in version 2.1.9.
Deserialization of untrusted schema data in Apache Directory LDAP API 2.1.0 through 2.1.8 lets a rogue, compromised, or pre-TLS man-in-the-middle LDAP server return a crafted schema object when a Java client calls loadSchema(), potentially executing arbitrary code inside the client process. The flaw is remotely reachable without credentials (CVSS vector PR:N) and vendor patches are available in 2.1.9, but exploitation requires the victim application to initiate a schema-loading connection to an endpoint the attacker controls or can impersonate, which is why the assessed vector raises attack complexity to High (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) even though the published base score is 9.8 under AC:L. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and EPSS remains low at 0.39% (30th percentile), with SSVC recording Exploitation: none, Automatable: yes, Technical Impact: total.
Denial of service in the Apache Thrift Java bindings before 0.25.0 allows remote, unauthenticated attackers to crash or exhaust resources on a service that deserializes attacker-controlled Thrift messages, because exceptional conditions on the message-handling path are not handled correctly and resource allocation is not bounded or throttled. Only deployments running affected Thrift Java server code on a network-reachable endpoint are at risk; impact is confined to availability (service crash / resource exhaustion) with no loss of confidentiality or integrity, and a specific precondition must hold - the crafted input must reach the vulnerable exception-handling or allocation path rather than any arbitrary request. There is no public exploit identified at time of analysis, and no confirmed active exploitation (CISA KEV); vendor-released patch: 0.25.0.
Timing side-channel leakage in Bouncy Castle for Java (bc-java) versions before 1.86 exposes private-key information from NTRU post-quantum KEM operations because three modular-reduction helpers used the '%' operator, which compiles to an integer division whose latency depends on the secret operand. Affected call paths include key generation (secret polynomials f and g), encapsulation (message polynomials r and m), and decapsulation (coefficients recovered from the private key), and the CVSS 4.0 base score is 8.2 (assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - confidentiality only). Exploitation requires the application to actually invoke NTRU KEM operations with a persistent/reused key and an attacker able to repeatedly measure operation timing with low jitter, so practical risk is limited to deployments that use NTRU and expose those operations to a co-located or low-latency timing observer; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (no CISA KEV listing), but a vendor patch is available and should be applied.
Heap-exhaustion denial of service in the MLS implementation of Bouncy Castle for Java (bc-java) before 1.86, triggered by a single small PrivateMessage whose SenderData carries a wire-encoded uint32 leaf_index with its top bit set. Because that value is held in a signed int, it decodes as negative and passes the signed bounds checks in GroupKeySet.SecretTree.hasLeaf and Group.validateRemove, letting a sender outside the tree reach LeafIndex.directPath()/NodeIndex.parent() arithmetic that never terminates at the tree root and grows a node list until the JVM runs out of heap. Impact is confined to availability (CVSS 4.0 8.7 with VA:H and no confidentiality or integrity effect); group membership is a practical prerequisite since the triggering MLS message or Remove proposal must originate from a current group participant, and applications that do not use org.bouncycastle.mls are unaffected. No public exploit code identified at time of analysis and the issue is not in CISA KEV; the vendor has released a fix in Bouncy Castle 1.86.
Remote code execution in DHIS2 Core versions 2.42.0 through before 2.42.5.1 and 2.43.0 through before 2.43.0.1 allows an authenticated attacker with high privileges to execute arbitrary code via unsafe Java deserialization. The vulnerability is remotely reachable but requires PR:H credentials, limiting exploitation to insiders or attackers who have already compromised an administrative account; no public exploit has been identified at time of analysis. Vendor fixes are available in versions 2.42.5.1, 2.43.0.1, and 2.44.
Memory-exhaustion denial of service in FasterXML jackson-dataformats-binary affects the Smile binary parser on 2.16.0-and-later releases, where SmileParser buffers an entire JSON object property name in memory through an unconstrained _growArrayTo() call inside _handleLongFieldName() and never calls StreamReadConstraints.validateNameLength(), so the configured maxNameLength is silently ignored for this format. Any remote, unauthenticated attacker whose bytes reach SmileFactory parsing - directly or through an ObjectMapper configured with the Smile module - can embed a single unbounded property name and force heap exhaustion, because maxDocumentLength is also disabled by default (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N, availability-only impact), leaving upload capacity and available heap as the only practical limits. No public exploit identified at time of analysis, and applications that parse only standard JSON are unaffected since jackson-core's JSON parsers enforce maxNameLength incrementally during name decoding.
Improper restriction of XML external entity resolution in the XSLT support extension of Apache Camel Quarkus (camel-quarkus-support-xalan) allows an attacker who supplies the XML document being transformed to read local files and to issue requests to internal network locations, because the bundled Xalan-J 2.7.x TransformerFactory predates JAXP 1.5 and cannot honour javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD or ACCESS_EXTERNAL_STYLESHEET. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, base 8.6) rates this as network-reachable and unauthenticated with scope change and high confidentiality impact, though exploitation is conditional: the application must pull camel-quarkus-xslt, camel-quarkus-xslt-saxon, camel-quarkus-tika or camel-quarkus-xmlsecurity onto the classpath, and on the xslt component path the attacker-controlled body must reach the transformer already as a javax.xml.transform.Source rather than a String, byte[], InputStream, DOMSource or StAXSource. Affected releases are 3.2.0 before 3.33.3 and 3.34.0 before 3.40.0; patches exist in 3.33.3 and 3.40.0, and no public exploit has been identified at time of analysis.
Arbitrary code execution on OpenClaw Windows Node hosts before version 2026.7.1 is achievable by an attacker who already holds gateway or agent access to a node, because the system.run tool's environment-variable sanitizer maintains an incomplete denylist (CWE-184). The attacker supplies variables such as GIT_CONFIG_*, GIT_PAGER, DOTNET_STARTUP_HOOKS, or JAVA_TOOL_OPTIONS alongside a request that runs an allowlisted tool (git, dotnet, java), causing that otherwise-permitted tool to load and execute attacker-controlled code or commands when it is next invoked; this requires the attacker to pass the tool's own arguments unchanged, which is why the attack-complexity/attack-requirements component is elevated. Exploitation is not remote-unauthenticated-it presumes prior gateway or agent access (PR:L), it is Windows-only, and it depends on at least one of git, dotnet, or java being present and reachable through system.run. No public exploit code or confirmed active exploitation was identified at time of analysis; the vendor has released a fixed build.
Unauthenticated remote attackers can bypass authentication in Apache WSS4J (4.0.0 before 4.0.2, 3.0.0 before 3.0.6, and 2.x before 2.4.4) and forge authenticated SOAP messages by submitting a crafted unsigned SAML sender-vouches assertion that carries an attacker-controlled key, which the DOM security processor accepts as proof of identity. Any SOAP service configured to accept and validate SAML sender-vouches assertions through that processor is exposed at the network layer alone, with no credentials and no user interaction required, yielding critical confidentiality and integrity impact (CVSS 3.1 base 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). At time of analysis no public exploit code and no confirmed active exploitation were identified, but the low attack complexity and the fact that the vulnerable code path is a security trust boundary make this a genuine high-priority vulnerability rather than a high-CVSS-but-low-risk case; remediation is straightforward because vendor patches exist.
Apache WSS4J versions 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all 2.x releases before 2.4.4 can accept SOAP messages in which a required element was never signed or encrypted, because the StAX streaming WS-SecurityPolicy validator converts relative or otherwise unsupported XPath expressions into paths that never match the real XML element path. The result is a fail-open integrity failure: a remote, unauthenticated SOAP peer (CVSS 3.1 AV:N/PR:N/UI:N) can send a policy-required element without the expected signature or encryption and the validator will not object. Exploitation is conditional on the deployment using WSS4J's StAX/streaming policy validator with a security policy whose SignedElements, EncryptedElements, or RequiredElements assertions use relative or unsupported XPath; our independent assessment rates the exploit vector AC:H and limits impact to integrity (I:H) with no confidentiality or availability effect, well below the vendor's 9.1 score, and no public exploit code has been identified at time of analysis.
Denial of service in Apache WSS4J (2.x before 2.4.4, 3.x before 3.0.6, and 4.x before 4.0.2) allows unauthenticated remote attackers to force excessive CPU and memory consumption by sending crafted WS-Security messages whose derived-key Length and Offset values are not validated by the library. The issue is a CWE-20 improper input validation flaw rated by the vendor at CVSS 3.1 base 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), so the rated impact is availability only, although the same unchecked bounds could in principle yield cryptographically weak derived keys. Vendor patches are available in 4.0.2, 3.0.6, and 2.4.4; CISA SSVC lists Exploitation: none with Automatable: yes, and no public exploit identified at time of analysis.
Denial of service in Apache PLC4X (PLC4J Java) from 0.10.0 before 1.0.0 allows a remote, unauthenticated attacker who can impersonate an OPC UA server to exhaust the client application's memory or stack during connection setup. The defects are triggered while the secure channel and session are established, before server identity is bound, so trusting a configured server does not prevent exploitation. No public exploit identified at time of analysis; vendor CVSS 4.0 score is 8.7 and the independent CVSS 3.1 assessment confirms AV:N/AC:L/PR:N/UI:N with availability-only impact (A:H).
Directory traversal in Handlebars.java before 4.5.5 lets unauthenticated remote attackers read arbitrary files outside the configured template base directory in Spring MVC applications that use the handlebars-springmvc integration. The flaw specifically affects handlebars-springmvc 4.5.3 and 4.5.4, where the path-containment check added for CVE-2026-63490 validates template locations as raw percent-encoded strings while the template file is ultimately opened through a URL handler that percent-decodes the path, so a request-derived view name containing %2e%2e/ slips past both the view-resolver and loader-side checks. Exploitation is not confirmed in the wild and no public exploit code has been identified at time of analysis, but it requires two non-default conditions to hold simultaneously: a file: template location prefix and a Handlebars view name derived from untrusted request input, which keeps real-world priority moderate despite the 7.5 CVSS score. Impact is limited to confidentiality (arbitrary file read); integrity and availability are unaffected.
Authentication bypass in the optional sshd-ldap component of Apache MINA SSHD (versions 1.2.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5) lets unauthenticated remote attackers complete SSH authentication by submitting the literal username "*" with the password "*", because LDAP filter metacharacters from user-supplied credentials are not escaped before being embedded in the search filter. Rated CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), the flaw is trivially reachable but only on servers that both embed the MINA SSHD library and have deployed and configured sshd-ldap for password or publickey authentication; stock MINA SSHD deployments without that optional component are entirely unaffected, and no public exploit code was identified at time of analysis. Apache ships fixes in 2.20.0 and 3.0.0-M6, which apply proper RFC 4515 escaping.
Authentication bypass in the optional sshd-ldap component of Apache MINA SSHD allows unauthenticated remote attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) to pass password authentication checks when an SSH server is configured to use LdapPasswordAuthenticator, yielding high confidentiality and integrity impact (rated 9.1 critical). Affected builds are 1.2.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5; servers that rely on sshd-core's built-in password mechanisms, or that do not use sshd-ldap at all, are not affected. No public exploit code has been identified and the issue is not confirmed actively exploited (no CISA KEV listing), but real-world exposure is sharply limited by the non-default optional component and the explicit LDAP authenticator configuration required - the raw 9.1 score is driven by impact rather than by a broad exploitable population.
Memory exhaustion in the Apache MINA SSHD SFTP client (DefaultSftpClient, sshd-sftp component) lets an attacker-controlled SFTP server drive a client application to run out of heap and crash, because the client stores unsolicited SFTP replies that it never matches to an outstanding request and therefore never releases. The flaw affects client-side deployments of Apache MINA SSHD versions 0.9.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5; server-only deployments are not exposed, and the victim must initiate an outbound SFTP session to a malicious or compromised server. It is rated CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is a pure denial-of-service condition of the client process, with no authentication bypass, code execution, or data disclosure; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
A partial authentication bypass in Apache MINA SSHD lets a remote attacker satisfy a repeated-public-key multi-authentication policy by presenting the same public key twice, so a server configured to demand two distinct keys can be entered with only one of them. Affected are versions before 2.20.0 and 3.0.0-M1 through 3.0.0-M5 of the sshd-core component; the vendor assigns CVSS 3.1 8.1 (High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), where PR:L reflects that the attacker must already legitimately possess at least one accepted key pair. Exploitation is confined to the non-default hardened configuration that requires repeated/multiple public keys (the equivalent of OpenSSH's AuthenticationMethods "publickey,publickey"); single-key or password-based deployments are not affected, and no public exploit code or confirmed active exploitation was identified at time of analysis.
An authentication bypass in Apache MINA SSHD's sshd-core library (versions 2.0.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5) allows remote, unauthenticated attackers to skip signature verification during public-key or hostbased SSH authentication, potentially granting an attacker a valid session. The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1 critical) reflects high confidentiality and integrity impact, but exploitation is gated by a non-default precondition: the server operator must have written explicit custom code enabling the library's 'asynchronous authentication' mechanism and applied it to public-key or hostbased authentication. Apache rates this implementation choice as presumed rare, and servers that do not opt into asynchronous authentication - or that use it only with password or keyboard-interactive auth - are not exposed. No public exploit code has been identified at time of analysis and the vulnerability has not been confirmed as actively exploited (no CISA KEV listing).
Authenticated shell command injection in Apache DolphinScheduler (all versions before 3.4.3) lets a user with permission to create or upload resources execute arbitrary commands as the DolphinScheduler service account. An attacker names a resource using shell command-substitution syntax such as $(...), then passes the resulting path as the scriptPath parameter to the Alert Script plugin's /test-send endpoint; because that parameter is concatenated into a /bin/sh -c invocation without neutralization of shell metacharacters, the shell evaluates the injected command. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 8.8) confidentiality, integrity and availability impact are all High, and while valid credentials and access to the Alert Script test-send functionality are required, no victim interaction is needed; no public exploit code or confirmed active exploitation was identified at time of analysis.
Stack exhaustion in the Apache XmlSchema walker (xmlschema-walker) allows a malicious XML Schema to crash any application that parses untrusted XSD/WSDL content, because the walker performs no cycle detection across type derivations, substitution groups, model groups, or attribute groups and recurses until the stack overflows. The flaw is remotely triggerable without authentication (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is limited to availability impact - no data disclosure or code execution. It is a third-party library issue rather than a directly network-exposed service: only deployments that walk attacker-controlled or third-party schemas are realistically exploitable, no public exploit code has been identified at time of analysis, and remediation is the vendor-released patch in version 2.3.3.
Stack exhaustion in Apache XmlSchema allows remote attackers to cause a denial of service by supplying a malicious XML Schema (XSD) document with deeply nested structures that recurse until the parsing thread's stack overflows. The library is a Java component, so exposure depends entirely on the host application accepting and parsing externally supplied schemas - deployments that only process trusted, internally authored schemas are not affected, and no authentication or user interaction is inherent to the flaw. No public exploit code exists and there is no confirmed active exploitation (no CISA KEV listing); the vendor-released fix is XmlSchema 2.3.3, and the assessed severity is CVSS:3.1 7.5 (High, availability-only).
Stack overflow denial of service in Apache XmlSchema versions before 2.3.3 allows unauthenticated remote attackers to crash applications that parse attacker-controlled XML schemas by supplying a schema with deeply nested imports or includes. The library lacks a recursion depth limit during schema resolution, so a malicious schema can exhaust the call stack. No public exploit code or CISA KEV entry has been identified at time of analysis, but the flaw carries a high availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affects deployments that ingest untrusted schemas.
Remote attackers without authentication can access the HTTPPublishAdapterTestServlet on Hitachi Energy Asset Suite deployments where the test servlet is exposed, allowing configuration file uploads that can disclose sensitive information and compromise configuration integrity. The flaw is CWE-306 missing authentication, rated CVSS 4.0 8.5 (High), with high confidentiality and integrity impact but no availability impact, and exploitation requires user interaction per the CVSS vector (UI:A). Hitachi Energy states the servlet is intended only for non-production testing, so risk is concentrated in production instances that inadvertently retain it; no public exploit identified at time of analysis.
Remote authenticated attackers can write files to arbitrary locations in Flowring Agentflow 4.0 via a path traversal flaw in the /WebAgenda/download/uploadFile.jsp endpoint, affecting versions released before March 24, 2023. The vulnerability requires a low-privilege authenticated session and no user interaction, with a CVSS 4.0 base score of 7.1. No public exploit code or active exploitation has been identified at the time of analysis.
Missing authorization checks in mall4j through 4.0 let any authenticated low-privilege account read the entire customer address book via the admin-side GET endpoints /user/addr/page and /user/addr/info in UserAddrController, exposing names, phone numbers and postal addresses. Exploitation requires only a valid, low-privileged login (PR:L) reachable over the network with no user interaction and no special configuration, and publicly available exploit code exists in a GitHub proof-of-concept repository. The flaw is a data-exposure issue (confidentiality only, no write or availability impact), and no vendor-released patch was identified at time of analysis.
Unauthenticated password reset in mall4j through 4.0 allows remote attackers to take over any storefront account by supplying a target username to the PUT /user/updatePwd endpoint, which lacks authentication checks (CWE-306). Publicly available exploit code exists, and the issue is rated critical (CVSS 4.0 score 9.3; independent assessment CVSS 3.1 9.1 with PR:N). No confirmed active exploitation (CISA KEV) as of analysis, but the low attack complexity and lack of prerequisites make this a high-priority risk for any deployment where the storefront API is reachable.
Unauthenticated remote code execution affects all versions of SailPoint IdentityIQ through improper input validation in its web service API. Attackers on an adjacent network segment can submit crafted content to the API to execute arbitrary code on the server without authentication or user interaction. The vendor rates this as critical (CVSS 9.6); no public exploit code has been identified as of this analysis.
Authenticated federation peers can cause denial of service and broker state manipulation in Apache ActiveMQ Artemis before 2.34.0 by sending a crafted FEDERATION_DOWNSTREAM_CONNECT packet that forces the broker to load and instantiate arbitrary classes visible to the Artemis module classloader. The vulnerability arises from unsafe reflection (CWE-470) in FederationStreamConnectMessage.getFederationPolicy(), which passes an unvalidated class name from the CORE protocol wire buffer to Class.forName(). Although the original CVSS 3.1 vector reports PR:N (8.2 High), the described authentication requirement means the practical severity is lower; the authoritative assessment uses PR:L. No public exploit code has been identified at time of analysis.
Authenticated command injection in Apache Karaf's instance-management service lets a principal who can reach the instance:* shell commands (instance:create, instance:start, instance:restart, instance:change-opts) or the equivalent InstancesMBean JMX operations execute arbitrary OS commands as the Karaf process user, because the caller-supplied javaOpts value is concatenated into a launch string that is then handed to /bin/sh or cscript. Affected deployments are Apache Karaf instances before 4.4.12, and exploitation requires an authenticated principal (CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) with the ability to supply javaOpts; the risk is amplified by a fail-open default in which unconfigured command scopes are not role-restricted. EPSS is low (0.40%, ~32nd percentile), CISA SSVC records no known exploitation, and no public exploit code was identified at time of analysis, so this is a high-priority but not an emergency issue.
LDAP filter injection in Apache Karaf before 4.4.12 allows a crafted login name to alter the structure of LDAP search filters built by LDAPCache and LDAPBackingEngine, potentially matching an unintended directory entry, over-granting roles, or changing which account a login resolves to. The unescaped value only reaches the filter through two call paths - the GSSAPILdapLoginModule (Kerberos/SPNEGO), which passes the NameCallback name through unescaped, and the LDAPBackingEngine.listRoles path, which passes principal.getName() unescaped - because the default LDAPLoginModule and LDAPPubkeyLoginModule both pre-escape the login name via Util.doRFC2254Encoding(). The issue is remote and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, score 7.3), but real-world impact is bounded by the administrator-configured userFilter/roleFilter templates; there is no confirmed active exploitation (not in CISA KEV), no public exploit code identified at time of analysis, and EPSS is low at 0.25% (14th percentile). A vendor patch is available in Apache Karaf 4.4.12.
XML external entity (XXE) injection in Apache Roller 6.1.5 lets an authenticated user who holds entry-editing rights on any weblog force the server to fetch and parse an attacker-influenced trackback response with an XML parser that resolves external entities, disclosing files readable by the Roller process account. The Trackback control is hidden in the standard UI, but its Struts2 action remains directly reachable over HTTP and no non-default server configuration is required, so the practical prerequisite is a valid low-privileged account plus a host the attacker controls to serve the malicious trackback XML (CVSS 3.1 7.7 High, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, scope change reflecting reads outside the application's own data). No public exploit code was identified at the time of analysis, and the vendor-released fix is Apache Roller 6.1.6, which eliminates the outbound trackback response parser.
Cross-weblog authorization bypass in Apache Roller 6.1.5 lets an authenticated user holding authoring rights on one weblog read, modify, or delete resources belonging to another weblog - bookmarks, bookmark folders, media files and directories, entries, categories, and comments - by supplying identifiers that are resolved without being scoped to the acting weblog. The same flaw allows a user with administrator rights on their own weblog to overwrite a victim weblog's Velocity template, whose content is then evaluated when that weblog renders, giving code-in-context execution within the victim's blog. Rated CVSS 7.7 High (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:L), exploitation requires an authenticated author-level account and knowledge or enumeration of valid foreign resource identifiers; no public exploit was identified at time of analysis. Multi-user shared-hosting installations where weblogs are meant to be isolated are affected, while single-user or single-tenant deployments are not meaningfully exposed.
Hostname verification bypass in Netty's QUIC client affects versions 4.2.11.Final through 4.2.17.Final when the application supplies a plain javax.net.ssl.X509TrustManager rather than an X509ExtendedTrustManager, allowing an attacker positioned on the network path to present a certificate chain for the wrong hostname that the trust manager still accepts. In practice exploitation requires an active man-in-the-middle position rather than a trivial remote attack, since the attacker must intercept the QUIC connection and hold a valid-but-mis-matched certificate; the CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N) overstates this precondition. No public exploit code was identified at time of analysis, and clients using X509ExtendedTrustManager are not affected; Netty 4.2.18.Final resolves the issue.
Authority confusion in Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final allows a remote, unauthenticated attacker to make a Netty-based HTTP/1-to-HTTP/3 gateway validate, authorize, or route a request against a different authority than the one its upstream HTTP/3 peer actually receives. The flaw only manifests in gateway, proxy, or protocol-bridge deployments that pass HTTP/1 messages through Http3FrameToHttpObjectCodec(false) and then make security decisions (allow-lists, virtual-host routing, backend selection, cache keys, URL generation) based on the absolute-form request-target authority; a request such as 'GET https://trusted.example/admin HTTP/1.1' with 'Host: attacker.example' yields an RFC-compliant authority at the front door and an attacker-chosen :authority upstream. Impact is limited to integrity per the advisory and the independent assessment (no code execution, memory corruption, or availability loss); no public exploit code has been identified at time of analysis, no confirmed active exploitation (CISA KEV) has been reported, and a vendor patch is available in 4.2.18.Final.
HTTP/1-to-HTTP/3 tunnel policy bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.2.Final through 4.2.17.Final) allows a remote, unauthenticated client to desynchronize a CONNECT request so that the tunnel authority forwarded over HTTP/3 is taken from the attacker-supplied Host header rather than the validated HTTP/1 authority-form request-target. A Netty-based proxy or gateway that performs its allow-list, egress, backend-selection, or audit checks against the request-target can therefore be induced to tunnel traffic to an attacker-chosen authority, an integrity-only impact (no confidentiality or availability loss) consistent with the vendor CVSS 4.0 score of 8.7 and the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The issue is fixed in 4.2.18.Final; no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and exposure is limited to deployments that actually translate inbound HTTP/1 CONNECT requests to HTTP/3.
Unbounded per-connection heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.0.Final-4.2.17.Final) allows an unauthenticated remote peer holding an established HTTP/3 connection to exhaust server memory and trigger OutOfMemoryError, resulting in denial of service. The QPACK encoder-stream handler (QpackEncoderHandler, installed by default on the peer-initiated unidirectional encoder stream, type 0x02) accepts an attacker-declared string-literal length of up to Integer.MAX_VALUE (~2 GiB) for the Name Length and Value Length fields of the 'Insert With Literal Name' instruction, then retains and grows the per-connection decode buffer while the peer trickles fewer bytes than declared; existing HTTP/3 limits such as maxHeaderListSize, maxUnknownFramePayloadLength, and DEFAULT_MAX_FIELD_SECTION_SIZE are not applied to this handler and provide no mitigation. Netty 4.2.18.Final resolves the issue, and no public exploit code was identified at time of analysis; the practical exposure is limited to services that have explicitly adopted Netty's opt-in HTTP/3 codec.
Remote denial of service in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final lets an unauthenticated remote peer exhaust server memory and CPU by opening a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and sending an all-prefix-bits first byte followed by an endless run of 0x80 continuation bytes. Because QpackUtil.decodePrefixedInteger returns -1 ("need more bytes") without consuming input, the ByteToMessageDecoder cumulator grows without bound and each decode() call re-scans the whole accumulated buffer at O(N^2) CPU cost, producing unbounded per-connection heap growth (OutOfMemoryError) and event-loop starvation. Netty's own advisory states the flaw is reachable in every configuration with no special flag or non-default setting, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms an availability-only impact with no confidentiality or integrity exposure; no public exploit code or CISA KEV entry was identified at time of analysis, and vendor-released patch 4.2.18.Final is available.
Unbounded heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final allows a remote, unauthenticated HTTP/3 client to exhaust server memory and cause a denial of service. The QpackEncoder retains per-stream encoder state indefinitely because entries are only released when the peer sends a Section Acknowledgment or Stream Cancellation instruction, not when the HTTP/3 stream completes; an attacker advertising a non-zero QPACK dynamic-table capacity and withholding those acknowledgments across sequential requests on a single QUIC connection can accumulate unbounded tracked streams, field sections, and bytes, bypassing concurrent-stream limits. No public exploit code has been identified at time of analysis, and no CISA KEV confirmation of active exploitation is present; the practical exposure is limited because Netty's HTTP/3 (QUIC) support is not yet widely enabled in production. Vendor-released patch: 4.2.18.Final (GHSA-495p-pchh-r4mc).
XML external entity (XXE) processing in Apache Roller 6.1.5 allows an authenticated weblog administrator to read files accessible to the Roller process and to reach internal network addresses by importing a crafted OPML bookmark document, because the bookmark-import parser does not disable external entity resolution. The advisory confirms no non-default configuration is required - the administrator bookmark-import action is vulnerable out of the box on the affected release - which is consistent with the assessed CVSS 3.1 score of 7.7 High (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, scope changed, confidentiality-only impact). No public exploit code and no confirmed active exploitation have been identified at time of analysis; the issue is remediated in Apache Roller 6.1.6, which uses a hardened parser that disables external entities and document type declarations.
Denial of service in JavaCV's IPCameraFrameGrabber affects all versions prior to 1.5.14, where an attacker-influenced MJPEG stream can supply an oversized Content-Length header that overflows a 32-bit buffer-doubling loop and traps the frame-grabbing thread in a permanent 100% CPU spin. Unauthenticated remote attackers can trigger this either by operating a malicious or compromised IP camera endpoint the application connects to, or by tampering with the plaintext HTTP response in transit; the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) confirms no privileges or user interaction are required and that impact is limited to availability. No public exploit code was identified at time of analysis and there is no CISA KEV listing, and the vendor has released a fixed version (1.5.14).
Authenticated workspace members can exploit an insecure direct object reference in Shaiwz data-platform-open (through commit efeacd3) to read, modify, or delete datasources belonging to other workspaces by supplying sequential numeric IDs. The flaw exposes JDBC credentials and database schemas via endpoints /datasource/detail, /listSchemaTable, /tableDetail, /update, and /delete, with no per-workspace authorization check. No public exploit code identified; exploitation requires a valid workspace-member account (PR:L) and no user interaction, and the impact is assessed as a moderately serious authorization flaw rather than an emergency-tier vulnerability.
Unauthenticated authorization bypass in the OpenNMS Meridian and Horizon REST API lets any remote attacker who can reach /rest/** read the monitored inventory and create, modify, or delete resources without credentials. The flaw arises because the Spring Security intercept-url rules match the HTTP method as a case-sensitive uppercase token and the filter chains terminate without a deny rule, so a request using a non-canonical method token (for example 'get' or 'put' instead of 'GET'/'PUT') matches no rule and is served without authentication; the /rest/alarms chain additionally leaks whether a specific alarm exists via a difference in the response. All pre-fix Meridian and Horizon versions in default configuration are affected, the vendor-supplied CVSS 3.1 base score is 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, i.e. unauthenticated and low complexity), and no public exploit code was identified at time of analysis; the practical limiting factor is deployment posture, since the vendor states these products belong on private networks and should not be Internet-facing.
Cross-site scripting in HtmlUnit Neko (htmlunit-neko) before 5.4.0 lets an unauthenticated remote attacker smuggle executable markup out of HTML sanitizers and content filters that use the library to serialize parsed HTML. HTMLWriterFilter fails to entity-encode decoded TEXTAREA and TITLE text, so entity-encoded markup supplied inside those elements is decoded on parse and re-emitted as literal markup by printCharacters(); output rendered by a victim's browser executes in that browser, which is why the CVSS 3.1 score of 7.2 (High) carries a scope change (S:C) on the vector AV:N/AC:L/PR:N/UI:N. The flaw is only reachable in a parse-transform-serialize pipeline that both relies on HTMLWriterFilter for its output and renders that output in a browser, and no public exploit code was identified at time of analysis; the issue is fixed in 5.4.0.
Denial of service in Junrar before 7.6.1 allows unauthenticated remote attackers to exhaust CPU and archive-processing worker capacity by supplying a crafted RAR4 archive. The archive drives the built-in RAR virtual machine into an infinite loop via a VM_JMP instruction targeting an address at or beyond the prepared program's codeSize; because the VM cannot execute native code, the supported impact is availability loss rather than code execution. No public exploit code or confirmed active exploitation has been identified, and the flaw is fixed in version 7.6.1.
Denial of service in Eclipse Vert.x's vertx-pg-client component allows an attacker controlling the PostgreSQL server or positioned as a man-in-the-middle on an unencrypted connection to crash the client application. The flaw resides in the binary array decoder (DataTypeCodec.binaryDecodeArray), which allocates a Java array based on a server-supplied 32-bit dimension count without upper bound checking, leading to a multi-gigabyte heap allocation and OutOfMemoryError. Affected versions include 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0. Exploitation requires no authentication (PR:N) but does require control of the database server or a MITM position on a non-TLS connection (AC:H), and no public exploit code has been identified at time of analysis.
Eclipse Vert.x DB2 Client versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 can deserialize attacker-controlled DRDA UDT column data, enabling remote code execution if a Java deserialization gadget chain is present on the classpath or denial of service otherwise. The affected component is io.vertx:vertx-db2-client, and exploitation requires an application to connect to a malicious or man-in-the-middle DRDA server that returns a result-set column tagged with FDOCA LID 0x50; legitimate DB2 servers never emit that type, and client-side TLS is disabled by default. The CVSS 4.0 score is 9.2 with PR:N, but practical exploitation requires attacker server-side/MITM position (AC:H) and, for RCE, a classpath gadget chain; no public exploit identified at time of analysis, and the real-world blast radius is narrower than the score alone suggests.
Unbounded direct-memory allocation in Eclipse Vert.x's MSSQL client (io.vertx:vertx-mssql-client) lets a malicious, compromised, or man-in-the-middle SQL Server endpoint crash a connecting client application by streaming TDS packets that never set the END_OF_MESSAGE status flag. Affected versions are [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] and 5.2.0: the TDS message decoder aggregates inbound packets into a composite direct-memory buffer with no cumulative size cap, so the buffer grows until memory is exhausted and the process dies (availability impact only, with no confidentiality or integrity loss, per the assessed CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H). The flaw is reachable before authentication completes, meaning no valid server credentials are required, but exploitation is not available to an arbitrary remote attacker - it demands control of, or a man-in-the-middle position on, the server side of the connection, which is why access complexity is rated High. No public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in Eclipse Vert.x HTTP proxy (io.vertx:vertx-http-proxy) affects versions 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0, allowing remote unauthenticated attackers to cause indefinite heap allocation. Exploitation requires the application to explicitly configure an intercepting body transformer-a non-default, developer-enabled feature-and the flaw lies in the transformer interceptor's reliance on a max buffered bytes limit that fails to keep per-request buffers bounded. No public exploit code has been identified at time of analysis; the CVSS 4.0 score is 8.7 with high availability impact.
Unauthenticated remote denial of service in FasterXML Jackson 1.x (jackson-mapper-asl 1.8.3 and 1.9.2-1.9.13) allows an attacker to crash or exhaust the stack of an application that deserializes untrusted JSON via ObjectMapper.readValue by supplying deeply nested input. The flaw is CWE-674 uncontrolled recursion: the Jackson 1.x parser performs recursive descent without a configurable nesting-depth limit. No public exploit code identified at time of analysis, and Jackson 2.x deployments are unaffected because that branch enforces StreamReadConstraints depth limits by default.
Arbitrary file access and operating-system command execution in Stirling-PDF prior to 2.13.2 are reachable by an authenticated administrator who uploads a crafted SQL file to POST /api/v1/database/import-database on instances running the default H2 database backend with security mode enabled. DatabaseService.validateSqlContent() splits the normalized input on semicolons and accepts a statement if it merely contains an allowed keyword, so dangerous H2 constructs such as FILE_READ, CSVWRITE and CREATE ALIAS slip past the whitelist and execute when RUNSCRIPT processes the import; the demonstrated chain writes attacker-controlled startup files to a user-site location and triggers the application's Python interpreter to load them, yielding command execution as the JVM service account. The CVSS 3.1 base score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) reflects network reachability with full confidentiality, integrity and availability impact and a scope change, but PR:H means the attacker must already hold administrative privileges and non-H2 deployments are unaffected; no public exploit code identified at time of analysis, and the issue is fixed in version 2.13.2.
Unbounded HTTP request-body buffering in the Model Context Protocol (MCP) Java SDK lets an unauthenticated remote client exhaust the JVM heap and render an MCP server unavailable. The flaw affects the Servlet-based SSE, Streamable HTTP, and Stateless server transports in io.modelcontextprotocol.sdk:mcp 0.8.0-0.12.0, mcp-core 0.13.0-0.18.3, 1.0.0-1.1.3, and 2.0.0-M1-2.0.0; a client simply streams an arbitrarily large POST body (including via chunked transfer encoding) until OutOfMemory conditions make the process unresponsive. Rated CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affecting availability only, the impact is materially reduced for deployments that require authentication, enforce Origin/Host validation, or sit behind a reverse proxy, load balancer, or API gateway with a maximum-body-size limit, all of which reject the oversized request before the vulnerable read; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Improper neutralization of special elements (CWE-74) in Microsoft's Azure Storage client libraries - azure-storage-blob-batch 1.0.0 and the Azure Storage Blobs client library for Java - allows an attacker who already holds low-level authorized access (PR:L) to escalate privileges over the network by routing crafted input through the library into a downstream component that does not sanitize it. The weakness requires no user interaction (UI:N) and produces high integrity and availability impact (I:H/A:H) with no confidentiality loss (C:N), which is consistent with Microsoft's 'Code Injection' tagging. No public exploit code has been identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' and the issue as not automatable, so real-world urgency sits below what the 8.1 base score alone would imply.
SAP MII's administrative account-provisioning function fails to enforce proper authorization boundaries, enabling an attacker who already holds MII administrator privileges to craft a request that provisions an account with elevated privileges on the underlying Java application server. This can extend compromise beyond MII to the host, with high confidentiality, integrity, and availability impact, and is reflected in a CVSS 3.1 score of 9.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H). No public exploit code or confirmed active exploitation was identified at time of analysis.
Out-of-band XML External Entity (XXE) injection in Eclipse JAXB RI (jaxb-ri) lets an unauthenticated remote attacker read local files when an application unmarshals attacker-influenced XML through the affected JAXB factory helpers (XmlFactory in the core and xsom modules). The pre-patch code relied solely on XMLConstants.FEATURE_SECURE_PROCESSING, so on JAXP/SAX/DocumentBuilder implementations where that single feature does not disable DOCTYPE declarations, external general entities, external parameter entities, or external DTD loading, external entity resolution remains possible and file content can be exfiltrated out-of-band. Exploitation requires both conditions to hold - untrusted XML reaching JAXB unmarshalling, plus a parser stack where secure processing alone is insufficient - which is why the vector carries AC:H and the score is 8.3 (High) on both the supplied CVSS 4.0 vector and the independently assessed CVSS 3.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L). No confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
Denial of service in Google Guava 4.0 through 33.7.1 can be triggered by remote unauthenticated attackers who can supply crafted Java serialization streams containing CompactHashMap, CompactHashSet, or MapMakerInternalMap objects, causing Guava to allocate an attacker-controlled backing array without throttling and exhaust memory with OutOfMemoryError. This is a genuine but conditional availability-only risk: exploitation requires the target application to perform Java native deserialization (ObjectInputStream.readObject) on attacker-influenced input, and any authentication or authorization in front of the deserializing endpoint further limits reach; no code execution or data disclosure results. A vendor fix is available in Guava 33.7.2, and no public exploit identified at time of analysis.
Unbounded memory allocation in Xerial snappy-java before 1.1.10.9 lets unauthenticated remote attackers exhaust the JVM heap by declaring an oversized uncompressed length in a compressed stream header, triggering OutOfMemoryError and denial of service. Any application that passes externally supplied bytes to Snappy.uncompress, Snappy.uncompressString, SnappyInputStream or SnappyFramedInputStream - for example Kafka, Hadoop/Spark or other services using snappy-java transitively - is in scope, and a handful of crafted bytes can force allocations of up to 2 GB before decompression validates the data. Impact is limited to availability (CVSS:4.0 base 8.7; assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) with no data disclosure or modification, and no public exploit was identified at time of analysis; the practical constraint is reachability, since applications that only decompress trusted internal data are not meaningfully exposed.
Token validation bypass in Apache CXF's STSTokenValidator and Security Token Service (STS) allows unauthenticated remote attackers to impersonate another user by presenting a forged UsernameToken or self-signed SAML Assertion whose 32-bit Java hash collides with an entry already held in the validated-token cache. Because a cache hit is treated as proof of prior validation, the forged token is accepted without password validation, signature trust verification, or any call to the STS, and can subsequently be exchanged through STS validation or renewal for STS-signed tokens issued for the victim identity. Exploitation is constrained in practice: the target deployment must use STSTokenValidator or STS token validation/renewal with the validated-token cache enabled, and a legitimately validated token for the identity being impersonated must already be present in that cache; no public exploit code has been identified at time of analysis, KEV status is negative, and EPSS is low (~0.17%, 6th percentile), yet the headline CVSS of 9.1 reflects high confidentiality and integrity impact if the preconditions are met. Vendor patches are available in 4.2.4, 4.1.9, and 3.6.13.
Keystream reuse in the native one-shot CTR packet cipher of Bouncy Castle for Java LTS before 2.73.13 allows remote attackers to recover plaintext from ciphertext alone, without knowledge of the key. Exploitation is unauthenticated but conditional: the application must use the native one-shot CTR path with a 13-, 14-, or 15-byte IV, leaving only a 1-, 2-, or 3-byte block counter (256, 65,536, or 16,777,216 blocks), and must pass a single input longer than that counter space so the counter wraps and the keystream restarts within the packet. The call returns the full input length with no exception, so the caller receives no signal that some bytes were transformed under a repeated keystream; the resulting two-time-pad condition permits plaintext recovery. No public exploit code has been identified at time of analysis, and the non-default short-IV native deployment requirement keeps realistic exposure narrow, which is why this is assessed as AC:H rather than trivially exploitable.
Arbitrary memory disclosure and denial of service in Hazelcast allow a client that can reach a cluster member's listening port to read arbitrary data from that member's Java heap, off-heap storage and JVM process address space, to crash members, and - in some Hazelcast Enterprise Edition configurations - to corrupt memory with possible remote code execution. All editions prior to 5.4.5, 5.5.10, 5.6.1 and 5.7.0 are affected in both the slim and full distributions, and the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a low-privileged client credential where client authorization is enforced, while in default deployments with Hazelcast Security disabled any reachable client can connect without credentials; the vendor's CVSS 4.0 score of 9.3 assumes PR:N. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, but vendor-released patches exist (5.4.5, 5.5.10, 5.6.1, 5.7.0) and the vendor's own hardening guidance - enabling security, enforcing client authorization and defining an explicit zero-config Compact serialization allowlist - directly addresses the exposure, making this a genuine high-priority vulnerability rather than an inflated score.
SQL injection in the generated reactive entity-list endpoints of JHipster-produced applications (generator-jhipster versions 7.0.0 up to, but not including, 9.4.0) lets an authenticated user inject arbitrary SQL through the attacker-controlled `sort` request parameter on `GET /api/<entity>?sort=...` endpoints. Because the generated R2DBC code passes the sort property into the SQL ORDER BY clause unvalidated and unquoted, and the driver runs it over the simple query protocol, semicolon-separated statements are executed as well - enabling reads of sensitive tables such as `jhi_user` password hashes, modification or deletion of data, and table drops (CVSS 3.1 8.8, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Exploitation requires the app to be the reactive WebFlux + Spring Data R2DBC + SQL stack, and an account is needed, though the default self-registration flow lets a low-privileged one be self-provisioned; the vendor-released fix is version 9.4.0, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Cross-host request replay in AsyncHttpClient (AHC) before 3.0.13 and 2.16.1 can disclose the original origin's request path, Host header, Authorization credentials, or even a plaintext request to a completely different destination when an application's ResponseFilter fails over or retries a request onto a different base origin (host, scheme, or port) or downgrades HTTPS to HTTP. The assessed vector is unauthenticated from the network perspective (PR:N, AV:N), but exploitation hinges on a concrete application-side prerequisite: a ResponseFilter (or equivalent retry/failover code path) that replays requests across origins - default AHC usage with same-host retries is unaffected, and AC:H/AT:P reflect the specific sequencing that must occur. No public exploit code and no confirmed active exploitation were identified at time of analysis, and because the impact depends on configuration rather than an attacker-reachable endpoint, the CVSS 4.0 score of 9.4 and the independent CVSS 3.1 assessment point in different directions; prioritization should be driven by whether a cross-host replaying filter is deployed.
Connection-pool reuse in the AsyncHttpClient (AHC) Java library, versions prior to 3.0.13 and 2.16.1, lets an authenticated principal inherit an HTTP/1.1 socket that was authenticated by a different principal under NTLM, Kerberos, or SPNEGO/Negotiate, causing the backend to execute the second request as the first identity - a full read/act-as impersonation (VC:H/VI:H). The flaw is that the connection-pool partition key omits the authenticated principal for connection-oriented authentication schemes, while Basic and Digest, which authenticate every request, are not affected. Exploitation requires an authenticated user (PR:L) on a deployment that shares one client/pool across multiple identities, and it is timing-dependent (AC:H, AT:P) because a suitably authenticated pooled socket must exist and be handed to the mismatched request; no public exploit code was identified at time of analysis and there is no KEV entry, though EPSS data was not provided. The vendor-released patch is AsyncHttpClient 3.0.13 (3.x line) or 2.16.1 (2.x line).
Digest mutual-authentication bypass in AsyncHttpClient (AHC) 3.0.12 allows a rogue or on-path peer to be accepted as the authenticated server: when a Digest challenge advertises qop="auth-int" as the only supported quality-of-protection, the client negotiates it but cannot compute the expected rspauth, treats that as unverifiable-but-nonfatal, and accepts a response whose rspauth value is invalid. The flaw is network-reachable, unauthenticated and requires no user interaction (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, 8.8), with the primary impact on integrity (VI:H) consistent with server impersonation rather than the data theft implied by the 'Information Disclosure' tag. It only affects applications that use AHC's Digest Realm with mutual authentication and connect to a peer offering an auth-int-only challenge; deployments where the server offers 'auth' or 'auth,auth-int' are unaffected because AHC prefers and verifies 'auth'. No public exploit code and no confirmed active exploitation were identified at time of analysis; the vendor-released patch is version 3.0.13.
Cleartext credential disclosure in AsyncHttpClient (AHC) before 3.0.12 on the 3.x line and before 2.16.1 on the 2.x line causes a client configured to use an HTTP proxy to write the origin request and its Authorization credentials onto a still-plaintext proxy connection when the proxy rejects the CONNECT with anything other than 200, because the client infers an established tunnel from the last request method rather than the CONNECT result. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 HIGH), this is an unauthenticated, confidentiality-only issue: Basic credentials can be recovered directly, while NTLM responses may be cracked or relayed. Exploitation is limited to environments where the victim application routes through an HTTP proxy and the attacker controls or can man-in-the-middle the client-to-proxy hop; no public exploit identified at time of analysis.
Credential disclosure in the AsyncHttpClient (AHC) Java library allows a malicious or compromised origin server or proxy to capture plaintext-recoverable usernames and passwords from applications that configure HTTP credentials via Realm.Builder. When the attacker returns a WWW-Authenticate or Proxy-Authenticate challenge labeled 'Digest' but with the nonce parameter omitted or empty, versions prior to 3.0.13 (3.x) and 2.16.1 (2.x) silently fall back to Basic authentication and resend the credentials in reversible Base64, defeating the entire purpose of Digest. Exploitation is unauthenticated from the network (CVSS v4.0 8.7, AV:N/PR:N, independent assessment CVSS v3.1 C:H/I:N/A:N), but requires the attacker to control or tamper with the authentication challenge, so it is not exploitable against arbitrary endpoints; no public exploit code or CISA KEV entry was identified at time of analysis.
Connection-pool key scoping in AsyncHttpClient (AHC) 2.0.0 through 3.0.13 omits identity-defining fields for Kerberos, SPNEGO, NTLM, authenticated proxy and SOCKS/CONNECT login paths, so a request can be handed a pooled keep-alive socket that was already authenticated as an entirely different identity and then execute under that first identity's credentials, exposing the other identity's data or authority. Reachability is conditional: the application must use Kerberos/SPNEGO/NTLM, an authenticated proxy realm, or SOCKS/CONNECT proxy logins, and specifically the ambiguous cases where login has no configured principal, where realms are proxy realms, where distinct identities share a user name, or where proxy logins are used - clients using only HTTP Basic/Digest or a single identity/principal are not affected. Rated CVSS 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, CWE-346 Origin Validation Error); exploitation depends on timing the reuse of an already-authenticated socket across multiplexed callers, and there is no public exploit identified at time of analysis and no CISA KEV listing. Vendor-released patch: 3.0.14.
Unbounded WebSocket permessage-deflate decompression in the AsyncHttpClient (AHC) Java library versions 2.2.0 through 3.0.13 allows a malicious or compromised WebSocket peer to exhaust the JVM heap of the connecting application by sending a small compressed message that inflates into a very large Netty buffer. The flaw is remote, requires no authentication or user interaction from the peer side (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), but it only triggers when the client application itself opens an outbound WebSocket connection with permessage-deflate compression negotiated - meaning the victim must connect to an attacker-controlled endpoint or be exposed to a man-in-the-middle. Impact is availability-only: no confidentiality or integrity loss, and no public exploit code has been identified at time of analysis. The issue is fixed in version 3.0.14.
Apache Commons BCEL before 6.13.0 caches attacker-supplied class files under the symbolic name declared inside the class file itself rather than validating that name against the name it was requested under, so a class loaded via AbstractClassPathRepository or ClassLoaderRepository can poison a repository entry keyed to a different, colliding name. Applications that load class files from an attacker-influenceable classpath or input stream and later rely on the repository's name-keyed lookups or verification results can be induced to operate on the wrong class, producing an integrity-only impact (no confidentiality or availability effect). The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N - network-reachable and unauthenticated, but requiring a specific name-collision and subsequent lookup sequence (AT:P), so it is not a fully automatable drive-in exploit; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor's elevated 8.2 CVSS 4.0 score reflects the integrity impact alone.
Local authenticated attackers who share a writable Java temporary directory with a victim JVM can exploit a time-of-check/time-of-use race in lz4-java 1.7.0 through 1.11.3 to replace the native LZ4 library extracted by net.jpountz.util.Native.load(), potentially executing native code with the victim's privileges. The vulnerability is local-only and requires winning a race against native-library extraction, plus a shared java.io.tmpdir and native binding use; hardened configurations may instead fail loading and fall back to Java implementations. Version 1.11.4 fixes the issue; no public exploit identified at time of analysis.
Denial of service in the RabbitMQ Java client (com.rabbitmq:amqp-client / rabbitmq-java-client) prior to the fixed release allows a single small, malformed JSON-RPC message body to permanently hang or crash a JVM. The deprecated com.rabbitmq.tools.jsonrpc tooling - JsonRpcServer and JsonRpcClient - falls back to DefaultJsonRpcMapper when no mapper is supplied, and that mapper hands raw message bodies straight to JSONReader.read(), whose string and comment scanners fail to stop at CharacterIterator.DONE. An input truncated inside a quoted string drives the parser into an unending append loop that exhausts the heap with OutOfMemoryError, while an unterminated // line comment pins a thread at 100% CPU indefinitely; neither condition is recoverable per request. Publicly available exploit code exists (a proof-of-concept is included in the vendor advisory) and the CVE is tracked by CISA SSVC with Exploitation=poc and Technical Impact=partial, though EPSS probability is low at roughly 0.49% (40th percentile) and no CISA KEV listing is present. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates a network-reachable, unauthenticated availability-only impact.
Code injection in Microsoft Kiota 0.5.0 through pre-1.35.0 allows attacker-controlled text embedded in an OpenAPI description to break out of the generated Java or PHP documentation comment and execute in the consuming application or build environment once that generated source is compiled and loaded (Java) or loaded (PHP). The flaw is reachable unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:R) but requires user interaction: a developer or CI pipeline must generate client code from an untrusted or tampered spec and then build or load the output, making this a build-time/supply-chain path rather than an attack on already-deployed runtime services. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV; CVSS 3.1 base score is 8.8, and the issue is fixed in 1.35.0.
Unauthenticated directory traversal in kkFileView 5.0.0 through 5.0.2 lets remote attackers create arbitrary directories and write files outside the intended fileDir root via the fileUpload, createFolder, and existsFile endpoints, which concatenate an attacker-supplied 'path' parameter into the upload base path without any validation. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) confirms that no credentials and no user interaction are needed, and that the impact is integrity-only (C:N/A:N), meaning the attacker can plant content beyond the configured storage root but gains no direct read or availability effect. Exploitation is gated chiefly by exposure rather than configuration - kkFileView is typically deployed as an internal document-preview service - and no public exploit code was identified at time of analysis, so internet-facing, unauthenticated reachability of the upload endpoints is the real-world precondition for mass abuse.
Remote code execution in LibreOffice Calc allows attackers to execute arbitrary Java code by embedding a crafted external data link that loads a malicious Java database driver from a remote URL when the document is opened. This affects LibreOffice versions prior to the fix that enforces file URLs for Java class-path entries. Exploitation requires user interaction (opening the document) and a local attack vector; no public exploit has been identified at time of analysis, yet the high-severity impact can fully compromise the user's system.
Unauthenticated remote code execution is possible in Perforce P4 Search container images prior to 2026.4.2 due to an exposed Java Debug Wire Protocol (JDWP) interface. An attacker with network access to the JDWP port can execute arbitrary code as the P4 Search service account, potentially compromising the connected P4 Server. No public exploit code has been identified at time of analysis, but the issue is rated critical (CVSS 9.5 in CVSS 4.0, assessed as CVSS 3.1 with scope change) and requires the debug interface to be reachable (attack prerequisite AT:P), making it a genuine high-priority issue rather than a high-CVSS-but-low-risk artifact.
Improper authentication in AhsayCBS up to version 10.3.2 lets an unauthenticated remote attacker bypass credential verification by manipulating the 'random' parameter processed by the checkSysPwd routine in the API component (com/ahsay/obs/api/ApiStructsAction.java). Exploitation requires only network reachability to the exposed AhsayCBS API/management interface and publicly available exploit code exists, so deployments that leave the console internet-facing or broadly reachable are the most at risk. The assessed impact is limited to partial confidentiality, integrity, and availability effects, and no confirmed active exploitation (CISA KEV) has been reported, making this a moderate-priority issue that is nonetheless straightforward to trigger where the API is exposed.
Bouncy Castle for Java before 1.86 fails to tie a Remove proposal in an MLS (RFC 9420) external commit to the joining party, allowing any holder of the group's public GroupInfo to evict an arbitrary member and take over that member's slot in the ratchet tree. Exploitation requires only that an application use the library's MLS module and accept external commits through the public Group.externalJoin / Group.handle API on an affected version; no group membership, credential, or user interaction is needed, and the missing credential check existed only in the gRPC interop harness, protecting none of the other API callers. The vendor rates this 8.7 (CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N), and there is no public exploit identified at time of analysis, though the flaw is trivially reachable by anyone who legitimately receives GroupInfo.
Signature-verification bypass in Bouncy Castle for Java before 1.86 lets a phantom signer be accepted in BLS12-381 aggregate signature verification. The faulty BLS12_381BasicScheme.keyValidate() trusts the public key's own ECCurve object during the prime-order subgroup check, so an attacker-supplied ECPoint built on a foreign curve that merely shares BLS12-381's field characteristic - with its cofactor forged to 1 - passes validation despite not being a G1 point; in the pairing implementation such a point contributes the identity in the target group, so an aggregate signature verifies even though it contains no signature for that key/message pair. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key, since the standard 48-byte compressed-point decoder always supplies the canonical curve; no public exploit has been identified at time of analysis, and the assessed impact is high integrity compromise without confidentiality or availability loss (CVSS:4.0 base 7.1, network vector, no privileges required).
Bouncy Castle for Java's Messaging Layer Security (MLS, RFC 9420) implementation before 1.86 fails to bind an X.509 credential to a LeafNode's signature_key, allowing an unauthenticated remote attacker to present a victim's certificate while signing the LeafNode and KeyPackage with an unrelated key and be accepted under the victim's identity. In an MLS deployment that uses X.509 credentials and admits external commits without an independent credential-admission check, the attacker can be admitted as the victim, evict the victim via resynchronization (which compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. The flaw is rated CVSS 9.2 (CVSS:4.0) / 9.2-equivalent high impact with the vendor patch available in 1.86; no public exploit code or confirmed active exploitation was identified at time of analysis, and deployments using only basic credentials are explicitly unaffected. Note the assessed attack complexity is High because the MLS/X.509 path must be in use and the application must lack its own credential-admission validation.
Bouncy Castle for Java 1.81 through 1.85.2 fails to verify that a third-party OpenPGP signature was issued by a component key actually granted certification authority, so the high-level certificate API will attribute an attacker-made certification or trust delegation to the certificate's offline primary key. An attacker must already hold the private key of a restricted subkey (one bound only with SIGN_DATA, or a legacy RSA encryption subkey whose algorithm can still sign) that lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER flag; they can then issue a positive User ID certification or a full-trust depth-one direct-key delegation that getCertificationBy()/getDelegationBy() report as a valid chain, and any application treating isValid() as an identity or trusted-introducer decision will accept the forged assertion at the primary key's authority. The flaw is a privilege promotion of an already-compromised subkey rather than a key-recovery attack, no public exploit code has been identified at time of analysis, and vendor fixes are available in 1.86.
Signature misattribution in the high-level OpenPGP API of Bouncy Castle for Java before 1.86 lets an attacker who holds a third party's public signing subkey - entirely public material - graft that subkey onto their own primary key with a Subkey Binding signature that omits both the Key Flags subpacket and the embedded Primary Key Binding (cross-certification) signature. Because OpenPGPCertificate.isSigningKey() and verifyEmbeddedPrimaryKeyBinding() resolved the subkey's key flags two different ways, the grafted subkey was treated as signing-capable while being exempt from the cross-certification requirement, so OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true for a message the subkey genuinely signed and reported the attacker's certificate as its issuer; GnuPG rejects the identical certificate and message. This yields misattribution of an existing genuine signature under an attacker-chosen, self-asserted identity - no private key is recovered and no new signature can be forged - and only affects relying parties that pin trust on the subkey's fingerprint or key ID while taking the signer identity from the enclosing certificate. The vendor rates it 8.2 (CVSS 4.0) with integrity-only impact; an independent assessment scores it CVSS 3.1 8.2-equivalent integrity-only (AC:H, PR:N, UI:N), no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
In-place encryption over a secret key buffer in Bouncy Castle for Java LTS before 2.73.13 can silently replace freshly produced ciphertext with the raw AES key, because native one-shot packet ciphers release read-only input arrays with JNI mode 0 and a later copy-back overwrites the output. The trigger is narrow and application-dependent-it requires the non-default pattern of passing the same Java array as both input and destination (for example, encrypting over KeyParameter.getKey()) on a JVM that copies rather than pins JNI array elements-so real-world exploitability is far lower than the 8.2 base score implies; bcprov, pure-Java packet ciphers, and native streaming modes are unaffected. No public exploit identified at time of analysis.
Improper validation of the digestAlgorithm/authAttrs pairing in Bouncy Castle's CMS AuthenticatedData handling lets a man-in-the-middle make the parser return authenticated attributes that the message MAC never covered, in Bouncy Castle for Java before 1.86, Bouncy Castle LTS before 2.73.13, and the BC-FJA/FIPS releases (bcpkix-fips before 1.0.13/2.0.13/2.1.13 and bcutil-fips before 2.0.8/2.1.8). Because the streaming CMSAuthenticatedDataParser picks in its constructor whether the MAC covers the DER encoding of authAttrs or the eContent OCTET STRING based solely on whether digestAlgorithm is present - a field that precedes authAttrs in the SEQUENCE - a message crafted with digestAlgorithm absent but authAttrs present passes the genuine content-MAC check and then exposes attacker-chosen attributes through getAuthAttrs(). Exploitation is unauthenticated at the network layer (CVSS:4.0 PR:N, no keys of either the key-encryption or content-MAC type are needed) but requires an in-transit tampering position and a victim application that makes an authorization, routing, or labelling decision from those attributes; the eContent payload itself remains MAC-bound, no public exploit has been identified at time of analysis, and signals conflict on whether this merits urgent prioritization (vendor CVSS 4.0 8.7 with AC:L versus an independent CVSS 3.1 assessment of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
Certificate-validation bypass in Bouncy Castle for Java lets a PKIXCertPathReviewer accept an end-entity certificate that violates a NameConstraints extension imposed by its own issuing CA, causing isValidCertPath() to return true with an empty error list for a chain the real PKIX validator rejects. Affected are BC-Java before 1.86, BC-LTS-Java before 2.73.13, and BC-FJA (bcpkix-fips) before 1.0.13 / 2.0.13 / 2.1.13; exploitation requires an application that uses org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer (or the legacy org.bouncycastle.x509 copy) to make the trust decision rather than the unaffected CertPathValidator "PKIX"/"BC", and a chain whose leaf actually breaches the CA's permitted or excluded subtrees. No public exploit code has been identified at time of analysis, the vulnerability is unauthenticated (CVSS PR:N) per the vendor vector, and the vendor scores it CVSS 4.0 8.7 (High) for high integrity impact; note that an independent assessment rates attack complexity higher (CVSS 3.1 AV:N/AC:H) because the exposure depends entirely on non-default application architecture rather than on anything the attacker controls.
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Opening a crafted untrusted document in Apache OpenOffice 4.1.16 and earlier can execute arbitrary code at the opening user's privilege level, including code fetched from a remote location, because the document's Java integration fails to authorize the external links it resolves. Exploitation is unauthenticated but requires user interaction: Java runtime integration must be enabled (the default configuration) and the victim must actively open an attacker-supplied file, making social engineering the primary delivery vector. There is no public exploit identified at time of analysis, no confirmed active exploitation (CISA KEV and SSVC both report none), and EPSS is only 0.22% (12th percentile); a vendor fix is expected in Apache OpenOffice 4.1.17, which is still in the release-candidate phase, so the recommended interim mitigation is to disable Java runtime integration in the Preferences dialog or to avoid opening untrusted documents entirely.
Denial of service in the Java bindings of Apache Thrift (all versions before 0.25.0) allows an accepted protocol peer to exhaust server resources by triggering unbounded allocation while Thrift messages are received and parsed. Per the assessed CVSS vector (PR:L), the attacker must already be an authenticated or otherwise accepted client of the Thrift service rather than an anonymous internet actor, which materially narrows exposure for deployments that only accept connections from trusted peers. The impact ceiling is availability loss only - no data disclosure, integrity impact, or code execution is declared - and no public exploit code or CISA KEV entry is associated with this CVE at time of analysis; the vendor-released fix is version 0.25.0.
Resource-exhaustion denial of service in Apache Thrift's Java TSaslNonblockingServer component allows remote attackers to drive the service into an unresponsive state by consuming server resources without limit (CWE-770). All Apache Thrift releases before 0.25.0 are affected, and the CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) confirms the attack is network-reachable and requires no credentials or user interaction once an exposed TSaslNonblockingServer endpoint is reachable; impact is confined to availability, with no confidentiality or integrity loss. Exploitation is only possible against deployments that specifically use the Java non-blocking SASL server class, which limits real-world exposure since blocking servers and non-SASL configurations are unaffected; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so this is a patch-now hygiene item rather than an emergency.
Repeated, attacker-triggered exceptional conditions in the Apache Thrift Java bindings can leak server-side resources and degrade or exhaust a Thrift RPC service running any version before 0.25.0. The issue is remotely reachable without authentication (CVSS PR:N) and needs no user interaction, but the assessed impact is availability only - there is no confirmed confidentiality or integrity effect, so this is a denial-of-service exposure rather than a data-compromise issue. A CVSS 4.0 attack-requirement flag (AT:P) indicates a specific precondition must be met to drive the vulnerable error path, meaning not every request triggers the leak; the precise condition is not specified in the public advisory text, and no public exploit identified at time of analysis. Deployments not using the Java bindings, or already on 0.25.0 or later, are unaffected.
Uncontrolled recursion in the Dart and Java ME bindings of Apache Thrift before 0.25.0 lets a remote, unauthenticated attacker crash or hang a service by sending a Thrift message containing deeply nested or self-referential structures that exhaust the parser's stack. Impact is availability-only (no confidentiality or integrity effect per the assessed CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and the vulnerable surface is confined to deployments that deserialize untrusted data using the Dart or Java ME bindings, so most Thrift users on Java SE, C++, Python, or Go are not exposed. No public exploit code or confirmed active exploitation was identified at time of analysis; the CVSS 4.0 base score of 8.7 should be read alongside the narrow binding-specific exposure, which makes real-world priority moderate rather than critical.
Cleartext exposure of directory data in Apache Directory LDAP API 2.1.0 through 2.1.8 occurs when an application sends a Search request and only afterwards starts a StartTLS extended operation, allowing response data to be returned in plain text before the TLS handshake completes. Exploitation requires the attacker to already hold a network interception position (passive eavesdropping or active man-in-the-middle) between the LDAP client and the directory server; no authentication or user interaction is needed on the target application itself, but the on-path prerequisite substantially limits realistic exploitation. There is no public exploit identified at time of analysis, EPSS is only 0.13% (2nd percentile) with no CISA KEV entry, and a vendor-released fix is available in version 2.1.9.
Deserialization of untrusted schema data in Apache Directory LDAP API 2.1.0 through 2.1.8 lets a rogue, compromised, or pre-TLS man-in-the-middle LDAP server return a crafted schema object when a Java client calls loadSchema(), potentially executing arbitrary code inside the client process. The flaw is remotely reachable without credentials (CVSS vector PR:N) and vendor patches are available in 2.1.9, but exploitation requires the victim application to initiate a schema-loading connection to an endpoint the attacker controls or can impersonate, which is why the assessed vector raises attack complexity to High (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) even though the published base score is 9.8 under AC:L. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and EPSS remains low at 0.39% (30th percentile), with SSVC recording Exploitation: none, Automatable: yes, Technical Impact: total.
Denial of service in the Apache Thrift Java bindings before 0.25.0 allows remote, unauthenticated attackers to crash or exhaust resources on a service that deserializes attacker-controlled Thrift messages, because exceptional conditions on the message-handling path are not handled correctly and resource allocation is not bounded or throttled. Only deployments running affected Thrift Java server code on a network-reachable endpoint are at risk; impact is confined to availability (service crash / resource exhaustion) with no loss of confidentiality or integrity, and a specific precondition must hold - the crafted input must reach the vulnerable exception-handling or allocation path rather than any arbitrary request. There is no public exploit identified at time of analysis, and no confirmed active exploitation (CISA KEV); vendor-released patch: 0.25.0.
Timing side-channel leakage in Bouncy Castle for Java (bc-java) versions before 1.86 exposes private-key information from NTRU post-quantum KEM operations because three modular-reduction helpers used the '%' operator, which compiles to an integer division whose latency depends on the secret operand. Affected call paths include key generation (secret polynomials f and g), encapsulation (message polynomials r and m), and decapsulation (coefficients recovered from the private key), and the CVSS 4.0 base score is 8.2 (assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N - confidentiality only). Exploitation requires the application to actually invoke NTRU KEM operations with a persistent/reused key and an attacker able to repeatedly measure operation timing with low jitter, so practical risk is limited to deployments that use NTRU and expose those operations to a co-located or low-latency timing observer; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (no CISA KEV listing), but a vendor patch is available and should be applied.
Heap-exhaustion denial of service in the MLS implementation of Bouncy Castle for Java (bc-java) before 1.86, triggered by a single small PrivateMessage whose SenderData carries a wire-encoded uint32 leaf_index with its top bit set. Because that value is held in a signed int, it decodes as negative and passes the signed bounds checks in GroupKeySet.SecretTree.hasLeaf and Group.validateRemove, letting a sender outside the tree reach LeafIndex.directPath()/NodeIndex.parent() arithmetic that never terminates at the tree root and grows a node list until the JVM runs out of heap. Impact is confined to availability (CVSS 4.0 8.7 with VA:H and no confidentiality or integrity effect); group membership is a practical prerequisite since the triggering MLS message or Remove proposal must originate from a current group participant, and applications that do not use org.bouncycastle.mls are unaffected. No public exploit code identified at time of analysis and the issue is not in CISA KEV; the vendor has released a fix in Bouncy Castle 1.86.
Remote code execution in DHIS2 Core versions 2.42.0 through before 2.42.5.1 and 2.43.0 through before 2.43.0.1 allows an authenticated attacker with high privileges to execute arbitrary code via unsafe Java deserialization. The vulnerability is remotely reachable but requires PR:H credentials, limiting exploitation to insiders or attackers who have already compromised an administrative account; no public exploit has been identified at time of analysis. Vendor fixes are available in versions 2.42.5.1, 2.43.0.1, and 2.44.
Memory-exhaustion denial of service in FasterXML jackson-dataformats-binary affects the Smile binary parser on 2.16.0-and-later releases, where SmileParser buffers an entire JSON object property name in memory through an unconstrained _growArrayTo() call inside _handleLongFieldName() and never calls StreamReadConstraints.validateNameLength(), so the configured maxNameLength is silently ignored for this format. Any remote, unauthenticated attacker whose bytes reach SmileFactory parsing - directly or through an ObjectMapper configured with the Smile module - can embed a single unbounded property name and force heap exhaustion, because maxDocumentLength is also disabled by default (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N, availability-only impact), leaving upload capacity and available heap as the only practical limits. No public exploit identified at time of analysis, and applications that parse only standard JSON are unaffected since jackson-core's JSON parsers enforce maxNameLength incrementally during name decoding.
Improper restriction of XML external entity resolution in the XSLT support extension of Apache Camel Quarkus (camel-quarkus-support-xalan) allows an attacker who supplies the XML document being transformed to read local files and to issue requests to internal network locations, because the bundled Xalan-J 2.7.x TransformerFactory predates JAXP 1.5 and cannot honour javax.xml.XMLConstants.ACCESS_EXTERNAL_DTD or ACCESS_EXTERNAL_STYLESHEET. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, base 8.6) rates this as network-reachable and unauthenticated with scope change and high confidentiality impact, though exploitation is conditional: the application must pull camel-quarkus-xslt, camel-quarkus-xslt-saxon, camel-quarkus-tika or camel-quarkus-xmlsecurity onto the classpath, and on the xslt component path the attacker-controlled body must reach the transformer already as a javax.xml.transform.Source rather than a String, byte[], InputStream, DOMSource or StAXSource. Affected releases are 3.2.0 before 3.33.3 and 3.34.0 before 3.40.0; patches exist in 3.33.3 and 3.40.0, and no public exploit has been identified at time of analysis.
Arbitrary code execution on OpenClaw Windows Node hosts before version 2026.7.1 is achievable by an attacker who already holds gateway or agent access to a node, because the system.run tool's environment-variable sanitizer maintains an incomplete denylist (CWE-184). The attacker supplies variables such as GIT_CONFIG_*, GIT_PAGER, DOTNET_STARTUP_HOOKS, or JAVA_TOOL_OPTIONS alongside a request that runs an allowlisted tool (git, dotnet, java), causing that otherwise-permitted tool to load and execute attacker-controlled code or commands when it is next invoked; this requires the attacker to pass the tool's own arguments unchanged, which is why the attack-complexity/attack-requirements component is elevated. Exploitation is not remote-unauthenticated-it presumes prior gateway or agent access (PR:L), it is Windows-only, and it depends on at least one of git, dotnet, or java being present and reachable through system.run. No public exploit code or confirmed active exploitation was identified at time of analysis; the vendor has released a fixed build.
Unauthenticated remote attackers can bypass authentication in Apache WSS4J (4.0.0 before 4.0.2, 3.0.0 before 3.0.6, and 2.x before 2.4.4) and forge authenticated SOAP messages by submitting a crafted unsigned SAML sender-vouches assertion that carries an attacker-controlled key, which the DOM security processor accepts as proof of identity. Any SOAP service configured to accept and validate SAML sender-vouches assertions through that processor is exposed at the network layer alone, with no credentials and no user interaction required, yielding critical confidentiality and integrity impact (CVSS 3.1 base 9.8, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). At time of analysis no public exploit code and no confirmed active exploitation were identified, but the low attack complexity and the fact that the vulnerable code path is a security trust boundary make this a genuine high-priority vulnerability rather than a high-CVSS-but-low-risk case; remediation is straightforward because vendor patches exist.
Apache WSS4J versions 4.0.0 through 4.0.1, 3.0.0 through 3.0.5, and all 2.x releases before 2.4.4 can accept SOAP messages in which a required element was never signed or encrypted, because the StAX streaming WS-SecurityPolicy validator converts relative or otherwise unsupported XPath expressions into paths that never match the real XML element path. The result is a fail-open integrity failure: a remote, unauthenticated SOAP peer (CVSS 3.1 AV:N/PR:N/UI:N) can send a policy-required element without the expected signature or encryption and the validator will not object. Exploitation is conditional on the deployment using WSS4J's StAX/streaming policy validator with a security policy whose SignedElements, EncryptedElements, or RequiredElements assertions use relative or unsupported XPath; our independent assessment rates the exploit vector AC:H and limits impact to integrity (I:H) with no confidentiality or availability effect, well below the vendor's 9.1 score, and no public exploit code has been identified at time of analysis.
Denial of service in Apache WSS4J (2.x before 2.4.4, 3.x before 3.0.6, and 4.x before 4.0.2) allows unauthenticated remote attackers to force excessive CPU and memory consumption by sending crafted WS-Security messages whose derived-key Length and Offset values are not validated by the library. The issue is a CWE-20 improper input validation flaw rated by the vendor at CVSS 3.1 base 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), so the rated impact is availability only, although the same unchecked bounds could in principle yield cryptographically weak derived keys. Vendor patches are available in 4.0.2, 3.0.6, and 2.4.4; CISA SSVC lists Exploitation: none with Automatable: yes, and no public exploit identified at time of analysis.
Denial of service in Apache PLC4X (PLC4J Java) from 0.10.0 before 1.0.0 allows a remote, unauthenticated attacker who can impersonate an OPC UA server to exhaust the client application's memory or stack during connection setup. The defects are triggered while the secure channel and session are established, before server identity is bound, so trusting a configured server does not prevent exploitation. No public exploit identified at time of analysis; vendor CVSS 4.0 score is 8.7 and the independent CVSS 3.1 assessment confirms AV:N/AC:L/PR:N/UI:N with availability-only impact (A:H).
Directory traversal in Handlebars.java before 4.5.5 lets unauthenticated remote attackers read arbitrary files outside the configured template base directory in Spring MVC applications that use the handlebars-springmvc integration. The flaw specifically affects handlebars-springmvc 4.5.3 and 4.5.4, where the path-containment check added for CVE-2026-63490 validates template locations as raw percent-encoded strings while the template file is ultimately opened through a URL handler that percent-decodes the path, so a request-derived view name containing %2e%2e/ slips past both the view-resolver and loader-side checks. Exploitation is not confirmed in the wild and no public exploit code has been identified at time of analysis, but it requires two non-default conditions to hold simultaneously: a file: template location prefix and a Handlebars view name derived from untrusted request input, which keeps real-world priority moderate despite the 7.5 CVSS score. Impact is limited to confidentiality (arbitrary file read); integrity and availability are unaffected.
Authentication bypass in the optional sshd-ldap component of Apache MINA SSHD (versions 1.2.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5) lets unauthenticated remote attackers complete SSH authentication by submitting the literal username "*" with the password "*", because LDAP filter metacharacters from user-supplied credentials are not escaped before being embedded in the search filter. Rated CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), the flaw is trivially reachable but only on servers that both embed the MINA SSHD library and have deployed and configured sshd-ldap for password or publickey authentication; stock MINA SSHD deployments without that optional component are entirely unaffected, and no public exploit code was identified at time of analysis. Apache ships fixes in 2.20.0 and 3.0.0-M6, which apply proper RFC 4515 escaping.
Authentication bypass in the optional sshd-ldap component of Apache MINA SSHD allows unauthenticated remote attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) to pass password authentication checks when an SSH server is configured to use LdapPasswordAuthenticator, yielding high confidentiality and integrity impact (rated 9.1 critical). Affected builds are 1.2.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5; servers that rely on sshd-core's built-in password mechanisms, or that do not use sshd-ldap at all, are not affected. No public exploit code has been identified and the issue is not confirmed actively exploited (no CISA KEV listing), but real-world exposure is sharply limited by the non-default optional component and the explicit LDAP authenticator configuration required - the raw 9.1 score is driven by impact rather than by a broad exploitable population.
Memory exhaustion in the Apache MINA SSHD SFTP client (DefaultSftpClient, sshd-sftp component) lets an attacker-controlled SFTP server drive a client application to run out of heap and crash, because the client stores unsolicited SFTP replies that it never matches to an outstanding request and therefore never releases. The flaw affects client-side deployments of Apache MINA SSHD versions 0.9.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5; server-only deployments are not exposed, and the victim must initiate an outbound SFTP session to a malicious or compromised server. It is rated CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is a pure denial-of-service condition of the client process, with no authentication bypass, code execution, or data disclosure; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
A partial authentication bypass in Apache MINA SSHD lets a remote attacker satisfy a repeated-public-key multi-authentication policy by presenting the same public key twice, so a server configured to demand two distinct keys can be entered with only one of them. Affected are versions before 2.20.0 and 3.0.0-M1 through 3.0.0-M5 of the sshd-core component; the vendor assigns CVSS 3.1 8.1 (High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), where PR:L reflects that the attacker must already legitimately possess at least one accepted key pair. Exploitation is confined to the non-default hardened configuration that requires repeated/multiple public keys (the equivalent of OpenSSH's AuthenticationMethods "publickey,publickey"); single-key or password-based deployments are not affected, and no public exploit code or confirmed active exploitation was identified at time of analysis.
An authentication bypass in Apache MINA SSHD's sshd-core library (versions 2.0.0 through 2.19.0 and 3.0.0-M1 through 3.0.0-M5) allows remote, unauthenticated attackers to skip signature verification during public-key or hostbased SSH authentication, potentially granting an attacker a valid session. The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1 critical) reflects high confidentiality and integrity impact, but exploitation is gated by a non-default precondition: the server operator must have written explicit custom code enabling the library's 'asynchronous authentication' mechanism and applied it to public-key or hostbased authentication. Apache rates this implementation choice as presumed rare, and servers that do not opt into asynchronous authentication - or that use it only with password or keyboard-interactive auth - are not exposed. No public exploit code has been identified at time of analysis and the vulnerability has not been confirmed as actively exploited (no CISA KEV listing).
Authenticated shell command injection in Apache DolphinScheduler (all versions before 3.4.3) lets a user with permission to create or upload resources execute arbitrary commands as the DolphinScheduler service account. An attacker names a resource using shell command-substitution syntax such as $(...), then passes the resulting path as the scriptPath parameter to the Alert Script plugin's /test-send endpoint; because that parameter is concatenated into a /bin/sh -c invocation without neutralization of shell metacharacters, the shell evaluates the injected command. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 8.8) confidentiality, integrity and availability impact are all High, and while valid credentials and access to the Alert Script test-send functionality are required, no victim interaction is needed; no public exploit code or confirmed active exploitation was identified at time of analysis.
Stack exhaustion in the Apache XmlSchema walker (xmlschema-walker) allows a malicious XML Schema to crash any application that parses untrusted XSD/WSDL content, because the walker performs no cycle detection across type derivations, substitution groups, model groups, or attribute groups and recurses until the stack overflows. The flaw is remotely triggerable without authentication (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is limited to availability impact - no data disclosure or code execution. It is a third-party library issue rather than a directly network-exposed service: only deployments that walk attacker-controlled or third-party schemas are realistically exploitable, no public exploit code has been identified at time of analysis, and remediation is the vendor-released patch in version 2.3.3.
Stack exhaustion in Apache XmlSchema allows remote attackers to cause a denial of service by supplying a malicious XML Schema (XSD) document with deeply nested structures that recurse until the parsing thread's stack overflows. The library is a Java component, so exposure depends entirely on the host application accepting and parsing externally supplied schemas - deployments that only process trusted, internally authored schemas are not affected, and no authentication or user interaction is inherent to the flaw. No public exploit code exists and there is no confirmed active exploitation (no CISA KEV listing); the vendor-released fix is XmlSchema 2.3.3, and the assessed severity is CVSS:3.1 7.5 (High, availability-only).
Stack overflow denial of service in Apache XmlSchema versions before 2.3.3 allows unauthenticated remote attackers to crash applications that parse attacker-controlled XML schemas by supplying a schema with deeply nested imports or includes. The library lacks a recursion depth limit during schema resolution, so a malicious schema can exhaust the call stack. No public exploit code or CISA KEV entry has been identified at time of analysis, but the flaw carries a high availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affects deployments that ingest untrusted schemas.
Remote attackers without authentication can access the HTTPPublishAdapterTestServlet on Hitachi Energy Asset Suite deployments where the test servlet is exposed, allowing configuration file uploads that can disclose sensitive information and compromise configuration integrity. The flaw is CWE-306 missing authentication, rated CVSS 4.0 8.5 (High), with high confidentiality and integrity impact but no availability impact, and exploitation requires user interaction per the CVSS vector (UI:A). Hitachi Energy states the servlet is intended only for non-production testing, so risk is concentrated in production instances that inadvertently retain it; no public exploit identified at time of analysis.
Remote authenticated attackers can write files to arbitrary locations in Flowring Agentflow 4.0 via a path traversal flaw in the /WebAgenda/download/uploadFile.jsp endpoint, affecting versions released before March 24, 2023. The vulnerability requires a low-privilege authenticated session and no user interaction, with a CVSS 4.0 base score of 7.1. No public exploit code or active exploitation has been identified at the time of analysis.
Missing authorization checks in mall4j through 4.0 let any authenticated low-privilege account read the entire customer address book via the admin-side GET endpoints /user/addr/page and /user/addr/info in UserAddrController, exposing names, phone numbers and postal addresses. Exploitation requires only a valid, low-privileged login (PR:L) reachable over the network with no user interaction and no special configuration, and publicly available exploit code exists in a GitHub proof-of-concept repository. The flaw is a data-exposure issue (confidentiality only, no write or availability impact), and no vendor-released patch was identified at time of analysis.
Unauthenticated password reset in mall4j through 4.0 allows remote attackers to take over any storefront account by supplying a target username to the PUT /user/updatePwd endpoint, which lacks authentication checks (CWE-306). Publicly available exploit code exists, and the issue is rated critical (CVSS 4.0 score 9.3; independent assessment CVSS 3.1 9.1 with PR:N). No confirmed active exploitation (CISA KEV) as of analysis, but the low attack complexity and lack of prerequisites make this a high-priority risk for any deployment where the storefront API is reachable.
Unauthenticated remote code execution affects all versions of SailPoint IdentityIQ through improper input validation in its web service API. Attackers on an adjacent network segment can submit crafted content to the API to execute arbitrary code on the server without authentication or user interaction. The vendor rates this as critical (CVSS 9.6); no public exploit code has been identified as of this analysis.
Authenticated federation peers can cause denial of service and broker state manipulation in Apache ActiveMQ Artemis before 2.34.0 by sending a crafted FEDERATION_DOWNSTREAM_CONNECT packet that forces the broker to load and instantiate arbitrary classes visible to the Artemis module classloader. The vulnerability arises from unsafe reflection (CWE-470) in FederationStreamConnectMessage.getFederationPolicy(), which passes an unvalidated class name from the CORE protocol wire buffer to Class.forName(). Although the original CVSS 3.1 vector reports PR:N (8.2 High), the described authentication requirement means the practical severity is lower; the authoritative assessment uses PR:L. No public exploit code has been identified at time of analysis.
Authenticated command injection in Apache Karaf's instance-management service lets a principal who can reach the instance:* shell commands (instance:create, instance:start, instance:restart, instance:change-opts) or the equivalent InstancesMBean JMX operations execute arbitrary OS commands as the Karaf process user, because the caller-supplied javaOpts value is concatenated into a launch string that is then handed to /bin/sh or cscript. Affected deployments are Apache Karaf instances before 4.4.12, and exploitation requires an authenticated principal (CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) with the ability to supply javaOpts; the risk is amplified by a fail-open default in which unconfigured command scopes are not role-restricted. EPSS is low (0.40%, ~32nd percentile), CISA SSVC records no known exploitation, and no public exploit code was identified at time of analysis, so this is a high-priority but not an emergency issue.
LDAP filter injection in Apache Karaf before 4.4.12 allows a crafted login name to alter the structure of LDAP search filters built by LDAPCache and LDAPBackingEngine, potentially matching an unintended directory entry, over-granting roles, or changing which account a login resolves to. The unescaped value only reaches the filter through two call paths - the GSSAPILdapLoginModule (Kerberos/SPNEGO), which passes the NameCallback name through unescaped, and the LDAPBackingEngine.listRoles path, which passes principal.getName() unescaped - because the default LDAPLoginModule and LDAPPubkeyLoginModule both pre-escape the login name via Util.doRFC2254Encoding(). The issue is remote and unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L, score 7.3), but real-world impact is bounded by the administrator-configured userFilter/roleFilter templates; there is no confirmed active exploitation (not in CISA KEV), no public exploit code identified at time of analysis, and EPSS is low at 0.25% (14th percentile). A vendor patch is available in Apache Karaf 4.4.12.
XML external entity (XXE) injection in Apache Roller 6.1.5 lets an authenticated user who holds entry-editing rights on any weblog force the server to fetch and parse an attacker-influenced trackback response with an XML parser that resolves external entities, disclosing files readable by the Roller process account. The Trackback control is hidden in the standard UI, but its Struts2 action remains directly reachable over HTTP and no non-default server configuration is required, so the practical prerequisite is a valid low-privileged account plus a host the attacker controls to serve the malicious trackback XML (CVSS 3.1 7.7 High, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, scope change reflecting reads outside the application's own data). No public exploit code was identified at the time of analysis, and the vendor-released fix is Apache Roller 6.1.6, which eliminates the outbound trackback response parser.
Cross-weblog authorization bypass in Apache Roller 6.1.5 lets an authenticated user holding authoring rights on one weblog read, modify, or delete resources belonging to another weblog - bookmarks, bookmark folders, media files and directories, entries, categories, and comments - by supplying identifiers that are resolved without being scoped to the acting weblog. The same flaw allows a user with administrator rights on their own weblog to overwrite a victim weblog's Velocity template, whose content is then evaluated when that weblog renders, giving code-in-context execution within the victim's blog. Rated CVSS 7.7 High (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:L), exploitation requires an authenticated author-level account and knowledge or enumeration of valid foreign resource identifiers; no public exploit was identified at time of analysis. Multi-user shared-hosting installations where weblogs are meant to be isolated are affected, while single-user or single-tenant deployments are not meaningfully exposed.
Hostname verification bypass in Netty's QUIC client affects versions 4.2.11.Final through 4.2.17.Final when the application supplies a plain javax.net.ssl.X509TrustManager rather than an X509ExtendedTrustManager, allowing an attacker positioned on the network path to present a certificate chain for the wrong hostname that the trust manager still accepts. In practice exploitation requires an active man-in-the-middle position rather than a trivial remote attack, since the attacker must intercept the QUIC connection and hold a valid-but-mis-matched certificate; the CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N) overstates this precondition. No public exploit code was identified at time of analysis, and clients using X509ExtendedTrustManager are not affected; Netty 4.2.18.Final resolves the issue.
Authority confusion in Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final allows a remote, unauthenticated attacker to make a Netty-based HTTP/1-to-HTTP/3 gateway validate, authorize, or route a request against a different authority than the one its upstream HTTP/3 peer actually receives. The flaw only manifests in gateway, proxy, or protocol-bridge deployments that pass HTTP/1 messages through Http3FrameToHttpObjectCodec(false) and then make security decisions (allow-lists, virtual-host routing, backend selection, cache keys, URL generation) based on the absolute-form request-target authority; a request such as 'GET https://trusted.example/admin HTTP/1.1' with 'Host: attacker.example' yields an RFC-compliant authority at the front door and an attacker-chosen :authority upstream. Impact is limited to integrity per the advisory and the independent assessment (no code execution, memory corruption, or availability loss); no public exploit code has been identified at time of analysis, no confirmed active exploitation (CISA KEV) has been reported, and a vendor patch is available in 4.2.18.Final.
HTTP/1-to-HTTP/3 tunnel policy bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.2.Final through 4.2.17.Final) allows a remote, unauthenticated client to desynchronize a CONNECT request so that the tunnel authority forwarded over HTTP/3 is taken from the attacker-supplied Host header rather than the validated HTTP/1 authority-form request-target. A Netty-based proxy or gateway that performs its allow-list, egress, backend-selection, or audit checks against the request-target can therefore be induced to tunnel traffic to an attacker-chosen authority, an integrity-only impact (no confidentiality or availability loss) consistent with the vendor CVSS 4.0 score of 8.7 and the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The issue is fixed in 4.2.18.Final; no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and exposure is limited to deployments that actually translate inbound HTTP/1 CONNECT requests to HTTP/3.
Unbounded per-connection heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.0.Final-4.2.17.Final) allows an unauthenticated remote peer holding an established HTTP/3 connection to exhaust server memory and trigger OutOfMemoryError, resulting in denial of service. The QPACK encoder-stream handler (QpackEncoderHandler, installed by default on the peer-initiated unidirectional encoder stream, type 0x02) accepts an attacker-declared string-literal length of up to Integer.MAX_VALUE (~2 GiB) for the Name Length and Value Length fields of the 'Insert With Literal Name' instruction, then retains and grows the per-connection decode buffer while the peer trickles fewer bytes than declared; existing HTTP/3 limits such as maxHeaderListSize, maxUnknownFramePayloadLength, and DEFAULT_MAX_FIELD_SECTION_SIZE are not applied to this handler and provide no mitigation. Netty 4.2.18.Final resolves the issue, and no public exploit code was identified at time of analysis; the practical exposure is limited to services that have explicitly adopted Netty's opt-in HTTP/3 codec.
Remote denial of service in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final lets an unauthenticated remote peer exhaust server memory and CPU by opening a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and sending an all-prefix-bits first byte followed by an endless run of 0x80 continuation bytes. Because QpackUtil.decodePrefixedInteger returns -1 ("need more bytes") without consuming input, the ByteToMessageDecoder cumulator grows without bound and each decode() call re-scans the whole accumulated buffer at O(N^2) CPU cost, producing unbounded per-connection heap growth (OutOfMemoryError) and event-loop starvation. Netty's own advisory states the flaw is reachable in every configuration with no special flag or non-default setting, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms an availability-only impact with no confidentiality or integrity exposure; no public exploit code or CISA KEV entry was identified at time of analysis, and vendor-released patch 4.2.18.Final is available.
Unbounded heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final allows a remote, unauthenticated HTTP/3 client to exhaust server memory and cause a denial of service. The QpackEncoder retains per-stream encoder state indefinitely because entries are only released when the peer sends a Section Acknowledgment or Stream Cancellation instruction, not when the HTTP/3 stream completes; an attacker advertising a non-zero QPACK dynamic-table capacity and withholding those acknowledgments across sequential requests on a single QUIC connection can accumulate unbounded tracked streams, field sections, and bytes, bypassing concurrent-stream limits. No public exploit code has been identified at time of analysis, and no CISA KEV confirmation of active exploitation is present; the practical exposure is limited because Netty's HTTP/3 (QUIC) support is not yet widely enabled in production. Vendor-released patch: 4.2.18.Final (GHSA-495p-pchh-r4mc).
XML external entity (XXE) processing in Apache Roller 6.1.5 allows an authenticated weblog administrator to read files accessible to the Roller process and to reach internal network addresses by importing a crafted OPML bookmark document, because the bookmark-import parser does not disable external entity resolution. The advisory confirms no non-default configuration is required - the administrator bookmark-import action is vulnerable out of the box on the affected release - which is consistent with the assessed CVSS 3.1 score of 7.7 High (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, scope changed, confidentiality-only impact). No public exploit code and no confirmed active exploitation have been identified at time of analysis; the issue is remediated in Apache Roller 6.1.6, which uses a hardened parser that disables external entities and document type declarations.