Apache Software Foundation
Monthly
XML external entity injection in Apache Abdera (all versions) allows unauthenticated remote attackers to read sensitive data or trigger server-side requests when an application feeds attacker-controlled XML into Abdera's parser or JDBC adapter parsing paths. The project is retired and unsupported, so Apache states it will not issue a fix, and downstream products that still bundle the Abdera artifact remain exposed. No public exploit identified at time of analysis, and exploitation is deployment-dependent: the target must still embed Abdera and route untrusted XML to it.
Apache Traffic Server 9.2.15, 10.1.4, and 10.2.0 can be crashed by a remote, unauthenticated attacker through a null pointer dereference (CWE-476) while proxying chunked origin responses. The race requires a client POST request to be torn down via TCP half-close at the moment ATS reparses a chunked origin response from a reentrant write-ready callback, so it is timing-dependent and typically needs repeated attempts; impact is limited to denial of service (crash), with no code execution, data disclosure, or integrity loss. No public exploit was identified at time of analysis, and vendor-released fixed versions are 9.2.16, 10.1.5, and 10.2.1.
Unauthenticated remote clients can force Apache Traffic Server's origin_server_auth plugin to sign attacker-chosen AWS request headers with the proxy's own AWS credentials, potentially allowing access to or modification of origin resources permitted to that identity. The issue affects ATS 8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0, but only installations using the non-default plugin to sign origin requests with AWS credentials are exposed. The vendor rates it High with a CVSS 4.0 base score of 7.0; no public exploit identified at time of analysis.
Unauthenticated network access to the shared proxy cache is possible in Apache Traffic Server deployments that load and enable the experimental tsmemcache plugin, allowing remote attackers to read, modify, and delete cached objects without credentials. Affected releases span 8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0; the exposure is gated by the plugin being explicitly enabled and its memcache-style interface being network-reachable, since it is not active in a default installation. No public exploit code or confirmed active exploitation was identified at time of analysis, though the CVSS 4.0 base score of 9.4 and the unauthenticated nature of the interface once exposed make this a high-priority fix for anyone running the plugin.
Apache Traffic Server 9.2.15, 10.1.4, and 10.2.0 can be driven into a denial-of-service condition through log amplification: each internal '@' header stripped from a request causes an unthrottled diagnostic log line, so requests carrying many such headers generate disproportionate log writes. The issue is network-reachable and unauthenticated, with high availability impact when log storage, rotation, or retention is constrained; no public exploit identified at time of analysis.
Client-certificate authentication bypass in Apache Traffic Server (8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0) lets an unauthenticated remote attacker resume a previously negotiated TLS session against an SNI virtual host that is configured with the verify_client STRICT policy, reaching backends that should have demanded a client certificate. The attacker only needs to first establish a resumable session on a virtual host that does not require client certificates, then resume it against the protected host; deployments that do not use verify_client STRICT, or that do not share session state across SNI hosts, are not exposed. No public exploit code or active exploitation has been identified at time of analysis, and the practical risk is concentrated in multi-tenant TLS-termination front ends that mix mutual-TLS and non-mTLS virtual hosts on the same instance.
TLS client-certificate cross-contamination in Apache Traffic Server 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 lets an outbound (origin-facing) transaction configured to present one client certificate instead reuse a pooled TLS session that was authenticated with a different client certificate, so the origin may see, authorize, and log the wrong client identity. The issue only manifests where ATS is configured for outbound mutual TLS with more than one distinct client certificate while the default outbound session-sharing/pooling policy is left enabled; deployments without outbound client certificates, with a single client identity, or with session sharing disabled are not affected. Apache assigned the maximum CVSS 3.1 score of 10.0, while this assessment scores it AV:N/AC:H because triggering the wrong reuse depends on session-pool state and timing rather than an attacker-injected payload; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis. Vendor-released patches exist in 9.2.16, 10.1.5, and 10.2.1.
Malformed padded HTTP/2 DATA frames sent to Apache Traffic Server 8.x, 9.x, or 10.x proxies that forward to HTTP/1.1 origins can trigger an integer underflow and exhaust the origin's worker pool, causing denial of service for proxied traffic. The issue is remotely reachable without authentication or user interaction when HTTP/2 is enabled on the client-facing listener (CVSS 4.0 AV:N/AC:L/PR:N/UI:N; CVSS 3.1 S:C/A:H), and the availability impact is scored against the downstream origin rather than the ATS process itself. No public exploit identified at time of analysis.
Denial of service in Apache Traffic Server 8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 allows unauthenticated remote attackers to exhaust a downstream HTTP/1.1 origin's worker pool by sending a truncated HTTP/2 Content-Length value that ATS mishandles when relaying the request. The issue is limited to proxy deployments where ATS accepts HTTP/2 client connections and forwards traffic to an HTTP/1.1 origin; no public exploit code or confirmed active exploitation was identified at time of analysis.
Response-framing desync in Apache Traffic Server (8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0) allows a malformed 302 response that should have been rejected as a parse error to pass the rejection path through the Transfer-Encoding: chunked carve-out, so the proxy stores and serves a response that different peers interpret differently. Per the CVSS vector the issue is remote and unauthenticated (AV:N/AC:L/PR:N/UI:N, scope changed, I:H/C:L), enabling cache poisoning and response-framing desync against deployments acting as caching or forwarding proxies. No public exploit code or CISA KEV entry is associated at time of analysis; the practical precondition is that a suitable malformed upstream response actually traverses the proxy. Fixed versions 9.2.16, 10.1.5, and 10.2.1 are published by the vendor.
Unauthenticated remote attackers can drive HTTP transactions to completion against Apache Traffic Server instances that have loaded the experimental WebAssembly plugin and trigger a use-after-free in the plugin's transaction-close handler, producing memory corruption that primarily threatens availability (high) with a limited integrity impact. The same plugin also passes unvalidated guest-supplied metric IDs straight into ATS's internal stats API, a path that requires the attacker to control or supply the wasm guest module. Exposure is limited to deployments that explicitly enable this non-default experimental plugin on versions 10.0.0 through 10.1.4 or 10.2.0; no public exploit identified at time of analysis.
Apache Traffic Server versions 8.0.1 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 ship an experimental 'magick' plugin that, in its default unsigned configuration, passes client-controlled data into ImageMagick 'convert' arguments, letting remote attackers inject command-line options (CWE-88 argument injection) with no authentication or user interaction. Because the plugin is experimental and not enabled by default, only deployments that deliberately loaded it without enabling request signing are exposed; those that are exposed face a CVSS 3.1 score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) with scope change and full confidentiality, integrity, and availability impact, since injected arguments can drive ImageMagick into reading or writing arbitrary files or executing delegated commands. No public exploit code or CISA KEV entry is associated with this CVE at time of analysis, but the impact on a vulnerable, enabled instance is total, and upgrading to 9.2.16, 10.1.5, or 10.2.1 is recommended.
Apache Pulsar deployments using the filesystem packages storage provider allow an authenticated user holding packages permission on any namespace to traverse out of their authorized tenant/namespace and download, overwrite, or delete packages belonging to other tenants or namespaces. The flaw is a CWE-22 path traversal in the unvalidated package version component; exploitation requires package management to be explicitly enabled and the non-default FileSystemPackagesStorageProvider to be configured, so default BookKeeper-backed deployments are not affected. No public exploit code was identified at time of analysis, and exploitation requires at least low-privilege authenticated access unless broker authentication is disabled, in which case any client able to reach the admin REST API can perform the operations without credentials.
Unauthenticated remote attackers can take full administrative control of Apache Pulsar Manager 0.3.0 and later by creating an administrator account through an endpoint that remains reachable after initialization, and every account has effective full privileges. In all versions, the manager proxies requests to the Pulsar admin API without enforcing its own authentication and can attach its configured Pulsar credential to a requester-chosen destination, allowing unauthenticated users to perform permitted admin operations and steal the credential. No public exploit code was identified at time of analysis, but the product is retired, unsupported, and will not receive fixes, so exposure persists until deployments are removed.
Apache Pulsar 2.8.1 through 4.0.13 and 4.1.0 through 4.2.4 can grant an authenticated low-privileged user the proxy's full privilege set - including superuser and tenant-admin rights - on the broker admin REST API, the functions worker, and the binary protocol when their requests are relayed by a Pulsar proxy. Two distinct weaknesses in the proxy-to-broker principal check (CWE-863) are involved: the original principal is authorized with the proxy's authentication data, letting MultiRolesTokenAuthorizationProvider or a custom data-driven provider expand the caller's roles to every role in the proxy's token, and a separate tenant-admin check succeeds whenever the proxy role itself is an admin of the tenant, even under the default provider. No public exploit code has been identified at time of analysis; exposure is limited to deployments that use the multi-role token provider or a data-driven custom provider, or that list a proxy role as a tenant admin.
Missing authorization in Apache Pulsar's shadow topic feature allows an authenticated tenant administrator to bind a topic in their own tenant to a persistent topic in another tenant through the PULSAR.SHADOW_SOURCE property, exposing retained messages and enabling destructive retention or deletion of the source topic's ledgers. This affects shadow-topic-capable releases before the fixed 4.0.14 and 4.2.5 versions under the default authorization provider, and no public exploit was identified at time of analysis.
Truncating a partitioned topic through the Apache Pulsar broker admin REST API succeeds without the caller holding tenant admin or superuser rights, letting an authenticated user wipe consumer backlog and destroy retained data on topics they merely have lookup permission for. The broker proxies each per-partition truncate request through its own internal admin client, so the tenant-admin authorization check is evaluated against the broker's configured identity rather than the caller's, and passes whenever that internal role is a superuser or tenant admin (the usual setup when authorization is enabled). Affected releases are 2.8.0 through 4.0.13 and 4.1.0 through 4.2.4, with fixes in 4.0.14 and 4.2.5; successful exploitation requires a valid authenticated identity, lookup permission on the target, a partitioned topic addressed by its partitioned name, and a suitably privileged broker internal client, and yields high integrity and availability impact with no confidentiality impact. No CISA KEV entry or public exploit code was identified at the time of analysis, and no EPSS score was supplied.
Unauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrary roles and have those roles honored when the broker uses MultiRolesTokenAuthorizationProvider alongside a non-empty anonymousUserRole. The flaw is reachable over the broker's HTTP surfaces, including the admin REST API and the WebSocket API, where failed credentials can fall back to the anonymous role while the original Authorization header is retained and later trusted without signature verification; an attacker who names a role configured in superUserRoles can obtain super-user access to tenants, namespaces, topics, permissions and broker configuration. Only deployments combining MultiRolesTokenAuthorizationProvider with a non-empty anonymousUserRole and the fallback conditions are exposed, while installations using the default PulsarAuthorizationProvider, another authorization provider, or an unset anonymousUserRole are unaffected. Vendor-released patch: 4.0.14 and 4.2.5; no public exploit identified at time of analysis, and exploitation also requires the specific non-default configuration described.
Denial of service in Apache bRPC servers that accept HTTP/2 traffic is caused by a malformed DATA frame with the PADDED flag set and a zero-length payload. An unauthenticated remote attacker with network reachability to an h2c- or TLS-ALPN-exposed HTTP/2 listener can trigger an integer underflow and out-of-bounds read, leading to high availability impact; versions before 1.18.0 are affected. No public exploit was identified at time of analysis, and the independent assessment rates the issue as network-reachable, low complexity, and requiring no privileges or user interaction.
Unauthenticated read access to the complete contents of prefixed system databases is possible in Apache CouchDB 3.5.2 and earlier because chttpd fails to enforce authorization on an API endpoint that serves those databases. Only deployments that have renamed their system databases with a prefix (a configuration the vendor calls 'very rare') are exposed - instances using the default _users and _replicator names are not exploitable - but where that condition holds, a remote attacker with network reach to the HTTP API can dump user credential documents or replication definitions without credentials or user interaction. Our assessment rates confidentiality impact as high with no integrity or availability effect, and no public exploit code or CISA KEV entry was identified at the time of analysis.
Memory-exhaustion denial of service in Apache CouchDB 3.5.2 and earlier allows any unauthenticated remote client to crash or hang the database by submitting a gzip-encoded HTTP request body that chttpd decompresses without any upper size bound. Impact is limited to availability - no data disclosure or modification - and the only practical prerequisite is network reachability of the CouchDB HTTP interface (typically 5984/6984), with no account, privileges, or victim interaction required. No public exploit code or confirmed active exploitation was identified at time of analysis; Apache has released CouchDB 3.5.3 to fix the issue, and instances sitting behind a proxy or WAF that caps request body size are substantially less exposed.
Arbitrary shell command execution in Apache CouchDB 3.5.2 and earlier on all platforms allows an authenticated CouchDB server administrator to run commands as the CouchDB operating-system user by setting an unvalidated runtime configuration value. The flaw crosses from application administration into host command execution, so the main risk is privilege escalation from CouchDB admin to the underlying host or misuse of stolen admin credentials; exploitation requires high-privilege authentication (PR:H) and is not remote-unauthenticated. Vendor-released patch: 3.5.3; no public exploit identified at time of analysis.
Apache Tomcat 11.0.0-M25 through 11.0.26 can split the body of a large non-blocking (NIO) response across the current request and the next request received on the same reused keep-alive connection, most likely causing the second request to fail and potentially leaking fragments of the first response to a different client. Remote, unauthenticated attackers can trigger the condition (CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H, 9.1 as published; our assessment raises attack complexity to High because the target must both perform large non-blocking writes and reuse the connection, and the corruption outcome is non-deterministic), so reliable attacker control over which or how much data leaks is not established. No public exploit code and no CISA KEV entry were identified at time of analysis, and 11.0.27 resolves the flaw.
Apache Tomcat 11.0.22-11.0.26, 10.1.55-10.1.60, and 9.0.118-9.0.122 contain an object-recycling race in HTTP/2 processing of asynchronous servlets that can mix up requests or responses between users. The issue is network-reachable and unauthenticated, but exploitation requires both HTTP/2 and asynchronous servlet use on the same deployment and depends on concurrent in-flight requests, so impact is probabilistic rather than deterministic. No public exploit code was identified at time of analysis and no CISA KEV confirmation was provided; fixed versions are 11.0.27, 10.1.61, and 9.0.123.
Authentication bypass in Apache Tomcat's JNDI realm allows unauthenticated remote attackers to log in without a valid password when the realm is configured with a non-GSSAPI SASL mechanism. The flaw affects 11.0.0-M1 through 11.0.26, 10.1.0-M1 through 10.1.60, and 9.0.0.M1 through 9.0.122, plus EOL 8.5.x and 7.0.x branches, and Apache has released fixes in 11.0.27, 10.1.61, and 9.0.123. No public exploit has been identified at time of analysis, and exploitation requires the non-default JNDIRealm/non-GSSAPI SASL configuration.
Unauthenticated information disclosure in Apache Cocoon can expose diagnostic interfaces, cache-triggering operations, verbose debug logging, and profile information to any user who can reach those endpoints; all versions are affected. The project is retired and no vendor fix is planned, so exposure is limited to deployments that leave diagnostic/debug endpoints accessible beyond trusted networks. No public exploit code or CISA KEV entry was identified at time of analysis.
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to remote code execution in the Camel process. Any host that can reach the JGroups cluster's multicast group or bind port - adjacent network only, given the default UDP multicast stack - can join without credentials and deliver a crafted serialized object that JGroups deserializes on its own receive thread before Camel's routing logic ever runs. Code execution still depends on a usable gadget chain being present on the application classpath and on no JVM-wide -Djdk.serialFilter being configured, which is why the issue is assessed as high rather than critical; no public exploit code or confirmed active exploitation was identified at time of analysis. Deployments that explicitly configure a channel/channelProperties with AUTH and encryption, or that set a JVM-wide serialization filter, are not exploitable through this path.
XML external entity injection in the camel-smooks component of Apache Camel (versions 4.7.0 through 4.18.4 and 4.19.0 through 4.22.0) lets remote attackers who can supply or influence an XML message body that is unmarshalled by Smooks read files accessible to the Camel process and force it to issue requests to internal network hosts. No privileges or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N), and no non-default configuration is needed because external entity resolution was the default behaviour of the Woodstox SAX reader Smooks used; the confidentiality impact is high with a low availability impact, giving a base score of 8.2. The flaw is only reachable on routes that unmarshal XML through .unmarshal().smooks(...) or the smooks: component with its default reader, and full return of exfiltrated content depends on an InOut route binding the resolved entity into the reply, so no public exploit code or active exploitation has been identified at time of analysis, though the vendor has released fixed versions.
Credential disclosure in the Apache Camel camel-http component lets a malicious or compromised remote endpoint harvest OAuth2 bearer tokens and basic/digest credentials by answering a request with an HTTP redirect to a host it controls. The leak occurs because OAuth2ClientConfigurer's request interceptor sits in ProtocolExec, below RedirectExec, so 'Authorization: Bearer' headers are re-attached on every redirect hop, and because basic/digest credentials were registered against an AuthScope that matched any host. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0; exploitation requires an endpoint with credentials configured and followRedirects=true (not the default) plus an attacker positioned to influence the target server's responses, and no public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
XML external entity injection in the Apache Camel XPath component lets unauthenticated remote attackers read files accessible to the Camel process and induce it to make outbound requests to attacker-named hosts when an expression is configured with documentType=InputSource and evaluates XML from an untrusted sender. The flaw is configuration-gated rather than default: Camel's default document type already refuses a DOCTYPE, so stock deployments are not exposed, but a deployment that selected InputSource for streaming reasons unknowingly also selected a weaker parser. Fixed in 4.23.0, 4.18.5 and 4.22.1; no public exploit identified at time of analysis, and the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects confidentiality impact only.
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message on a transport feeding that endpoint to choose both the expression language and the predicate expression that Camel compiles and then evaluates against every exchange routed through the corresponding dynamic-router endpoint, running with the full privileges of the Camel process - effectively code execution. The issue affects Camel 4.4.0 through 4.18.4 and 4.19.0 through 4.22.0 (releases before 4.4.0 are not affected), scored CVSS 3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), so some access to the feeding transport is expected but no application-level authentication or user interaction is required. Exposure is limited to deployments that expose the control endpoint through a route forwarding messages from an external, shared or untrusted transport; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Unauthenticated remote AS2 partners can turn an Apache Camel camel-as2 receiver into a server-side request forgery pivot: the component reads the asynchronous Message Disposition Notification (MDN) return address out of the inbound message and dials it verbatim, so the sender chooses the host the Camel instance connects to, including addresses only routable from inside the deployment's network. Deployments running Apache Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 with an exposed camel-as2 receiver are affected; where mdnUserName, mdnPassword or mdnAccessToken are configured, the outbound receipt presents those MDN-delivery credentials to the attacker-chosen destination, which drives the high confidentiality component of the CVSS 3.1 score of 8.2 (CWE-918). No public exploit code has been identified at time of analysis, and vendor fixes are released in 4.23.0, 4.18.5 and 4.22.1; real-world urgency is moderated by whether the receiver is reachable by untrusted partners and whether credentials are attached to MDN delivery.
Authorization bypass in Apache Camel's camel-netty-http component allows remote unauthenticated attackers to reach protected routes by changing the case of characters in the request path so the security constraint no longer recognizes it while routing still dispatches to the endpoint. It affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1, with a CVSS score of 8.2; no public exploit identified at time of analysis.
Apache Camel's camel-oauth route guards fail open: when authentication cannot be completed, the OAuthBearerTokenProcessor and OAuthCodeFlow processors set an error status and body but never stop the exchange, so the request falls through and continues into the protected part of the route as if the caller had authenticated. Camel 4.11.0 through 4.18.4 and 4.19.0 through 4.22.0 are affected wherever camel-oauth is used to protect an HTTP-reachable endpoint, and exploitation needs no credentials, user interaction, or special configuration - simply omitting the Authorization header, sending a non-Bearer header, presenting an invalid token, or arriving without an authorization code is enough (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). The gap is a confidentiality problem first and foremost, exposing whatever the protected route returns, with limited integrity impact; no public exploit identified at time of analysis, and the vendor-released patch is 4.23.0, with backports in 4.18.5 and 4.22.1.
Path traversal in Apache Camel's remote-file consumers - the azure-files scheme named in this CVE plus the FTP/SFTP consumers sharing the RemoteFileConsumer base class - lets a malicious, compromised, or multi-tenant remote file server (or an on-path attacker on the integrity-free FTP control channel) cause Camel to read, delete, or rename files outside the directory it was configured to poll, using the endpoint's own credentials. Retrieval is reachable in the default consumer configuration because remote consumers download every listed file; deletion and renaming additionally require delete=true, move, preMove, moveFailed, or readLock=rename. The jailStartingDirectory option, enabled by default and documented as a boundary, did not constrain this remote operand before the fix, so it offered no protection; triggering the traversal requires control over a listing name returned by the server, and for azure-files specifically the Azure Files REST service does not normally return multi-segment names, making exploitation there impractical. No public exploit code or confirmed active exploitation was identified at time of analysis; vendor patches are available.
Path traversal in Apache Camel's remote-file consumers (including the SMB component's share-walking consumer) lets a directory listing entry that is not a single path segment resolve outside the polled remote directory, so Camel will retrieve, delete, or rename files outside that directory using the endpoint's own credentials. Affected are Camel 4.2.0 through 4.18.5-exclusive and 4.19.0 through 4.22.1-exclusive; file retrieval is reachable in a default consumer configuration, while deletion requires delete=true and renaming requires move, preMove, moveFailed, or readLock=rename. The CVSS 3.1 vector (7.4, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects unauthenticated reachability over the network with a high attack-complexity prerequisite: the remote server - or an on-path attacker rewriting an unprotected FTP LIST response, or a malicious, compromised, multi-tenant, or virtual-filesystem-backed server - must emit a qualifying listing name; for the SMB scheme a conforming SMB2 server will not do so, and no public exploit identified at time of analysis.
Path traversal in Apache Camel's remote-file consumers (the FTP, SFTP and mina-sftp schemes) lets a name reported in a remote server's directory listing resolve outside the directory Camel was configured to poll, so Camel will read, delete or rename files elsewhere using that endpoint's own credentials. Affected are Camel 4.18.0 through 4.18.4 and 4.19.0 through 4.22.0, with retrieval reachable in a default consumer configuration because remote consumers download every listed file (CVSS 3.1 base score 7.4, AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:N). The attacker must influence the LIST/SFTP listing output - via a malicious, compromised or multi-tenant server, a virtual-filesystem-backed server, or an on-path attacker against plaintext FTP whose control channel has no integrity protection - and no public exploit has been identified at time of analysis.
Apache Camel's ftp, ftps and sftp remote-file consumers build each file's remote path by concatenating the polled directory with the name returned in the server's directory listing, without any lexical normalization or containment check, so a listing entry containing parent-directory segments resolves outside the configured directory and is then read, deleted or renamed with the endpoint's own credentials. Affected are Camel 4.0.0 through 4.18.4, 4.19.0 through 4.22.0, and earlier; the 4.14.x stream is end-of-life and unfixed, while patches ship in 4.18.5, 4.22.1 and 4.23.0 (CPE: apache_software_foundation:apache_camel). Retrieval is reachable in a default consumer route, whereas deletion needs delete=true and renaming needs move, preMove, moveFailed or readLock=rename; the crucial caveat is that the jailStartingDirectory option, on by default and documented as confining Camel to the starting directory, does not constrain this remote path, so it cannot be used as a mitigation. There is confirmed no active exploitation tracked (not in CISA KEV) and no public exploit code identified at time of analysis, although the reporter privately demonstrated the issue end to end against an FTP endpoint; CVSS 7.4 with AC:H reflects that the attacker must first control or influence the remote server's LIST response rather than attack Camel directly.
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticated attacker who can either PUBLISH to a channel the route subscribes to, or write attacker-controlled bytes into a key the component later reads, to instantiate an arbitrary class graph in the application's JVM and execute its readObject method. Every release from 2.11.0 up to (but not including) 4.18.5 and 4.22.1 ships the affected default, which lazily builds a bare JdkSerializationRedisSerializer with no java.io.ObjectInputFilter whenever no serializer option is configured. No public exploit code was identified at time of analysis, but exploitation needs only a viable gadget on the classpath, which is why this carries CVSS 8.8 with high confidentiality and integrity impact.
Header-driven URI resolution in Apache Camel's HTTP producer components causes message-supplied CamelHttpUri and CamelRestHttpUri values to be expanded through CamelContext.resolvePropertyPlaceholders() before use, so an attacker who can influence those headers turns a URI string into a configuration-evaluation context and can read OS environment variables, JVM system properties, every registered secret-backend PropertiesFunction (AWS, Azure, GCP, HashiCorp, IBM, CyberArk, Kubernetes) and even invoke no-argument methods on beans in the registry. The flaw affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1 across camel-http, camel-http-common, camel-vertx-http, camel-undertow and camel-netty-http, and a plain static to(http://backend/api) route is enough to be exposed; no authentication is required where a route is reachable by untrusted senders (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). Exploitation yields a high-confidentiality but limited-integrity impact, and while no public exploit code or CISA KEV entry exists at time of analysis, the preconditions are ordinary and the vendor has shipped fixes, so this warrants prioritised patching.
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, where two self-built Hazelcast bootstrap paths create instances without the default JavaSerializationFilterConfig added for CVE-2026-43865. A route using ReplicatedHazelcastAggregationRepository without an injected hazelcastInstance, or a client-mode endpoint built by HazelcastDefaultComponent#getOrCreateHzClientInstance() when neither a ClientConfig nor hazelcastConfigUri is supplied, will accept and deserialize arbitrary Java objects published into the backing cluster, letting an attacker who can write into that cluster execute code before Camel ever processes the exchange. Hazelcast clusters ship without authentication or TLS by default, so the write prerequisite is often met in practice; no public exploit code or CISA KEV entry was identified at time of analysis, but the vendor has published fixed releases and the missing-filter condition requires no unsafe opt-in by the deployer.
Apache Kylin versions 4 through 5.0.4 expose sensitive information to unauthorized actors through a CWE-200 flaw that, per the CVSS vector, can be reached remotely without authentication or user interaction (CVSS 3.1: 7.5). The advisory does not specify the exact endpoint or configuration condition, so practical exposure depends on whether a vulnerable Kylin instance is network-reachable; Kylin is typically deployed inside internal big-data and analytics clusters. No public exploit code or CISA KEV entry was identified at time of analysis, and EPSS is low at 0.20% (9th percentile).
Code injection in Apache Kylin 4.0.0 through 5.0.4 allows an authenticated low-privilege user who can supply or influence a JDBC connection URL to inject a crafted special parameter and execute arbitrary code. The vendor limits practical exposure to Kylin services directly reachable from the public network, noting that in-house deployments are mostly unaffected; no public exploit code has been identified at time of analysis and EPSS is low at roughly 0.23%.
Unauthenticated SQL injection in Apache Kylin 5.0.0 through 5.0.4 lets a remote network attacker reach a backend cache API that lacks authentication and execute injected SQL against the underlying data store, carrying CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, full confidentiality, integrity and availability impact). Exploitation is primarily gated by exposure rather than by attacker capability: the vendor states the issue mainly threatens Kylin services directly reachable from the public internet, which it describes as uncommon, and in-house deployments kept on internal networks are largely unaffected. No public exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is low at 0.30% (21st percentile).
Apache Kylin 4 through 5.0.4 performs unsafe Java deserialization of data returned by a configured external cache service, enabling remote code execution if an attacker can control or impersonate that cache. The authoritative assessment rates this as network-reachable with high attack complexity and no privileges required, because exploitation depends on the external-cache precondition rather than a default Kylin endpoint. No public exploit identified at time of analysis or CISA KEV entry was available; EPSS is 0.36% (28th percentile), and the vendor-released fix is 5.0.5.
Unauthenticated retrieval of sensitive backend metadata is possible in Apache Kylin 4.x through 5.0.4 because the metadata dump API performs no authorization check and does not confine the requested path to an intended location. The CVSS vector (AV:N/AC:L/PR:N/UI:N) means any party who can reach that API over the network can invoke it without credentials or user interaction; per our assessment the confirmed impact is confidentiality only (C:H/I:N/A:N), even though the NVD-published score of 9.1 also claims integrity impact. Apache explicitly limits the practical risk to installations where the Kylin backend is directly exposed to the public internet - an uncommon posture - so standard internally segmented deployments are largely unaffected. No public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is low at 0.19% (8th percentile), which reinforces that this is an exposure-dependent issue rather than a broadly exploited one.
Unauthenticated exposure of system-level configuration information in Apache Kylin 4.0.0 through 5.0.4 lets any client that can reach the Kylin service retrieve sensitive deployment details, rated CVSS 3.1 base 7.5 (HIGH) with high confidentiality impact but no integrity or availability effect. Per the assessed vector (AV:N/AC:L/PR:N/UI:N), no authentication, user interaction, or non-default configuration is required, so default-reachable instances are exposed; exposure is limited mainly by whether the instance is network-reachable, and deployments confined to internal networks or placed behind authenticating proxies are significantly less at risk. No public exploit code and no CISA KEV entry were identified at time of analysis, and no EPSS score was supplied, so prioritization should be driven by network exposure of Kylin installations rather than by observed exploitation. Upgrading to 5.0.5 is the vendor-recommended fix.
Apache Airflow's SSH and SFTP provider hooks accept any server host key by default, so an attacker positioned as a machine-in-the-middle between an Airflow worker and an SSH or SFTP endpoint can impersonate that server and capture task credentials or transferred data. All releases of apache-airflow-providers-ssh and apache-airflow-providers-sftp before 7.0.0 are affected when a connection has neither host_key configured nor no_host_key_check explicitly disabled; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, i.e. unauthenticated from the attacker's side but gated on the high-complexity MITM prerequisite, which is why the input's 9.1 rating overstates practical urgency. No public exploit code has been identified and EPSS is only 0.18% (7th percentile); vendor patches (provider 7.0.0) are released, and the related deferrable-SFTP path is tracked separately as CVE-2026-94135, which the same SFTP 7.0.0 release also fixes.
Out-of-bounds read in Apache DataSketches C++ (datasketches-cpp) allows an attacker who controls a serialized VarOpt union image to trigger reads of up to 24 bytes past the end of the supplied buffer, causing a crash (denial of service) and potentially leaking adjacent heap memory into the deserialized union's state. Applications are exposed only if they call var_opt_union::deserialize() on data from untrusted sources; affected releases are 2.0.0-incubating through 5.2.0, and the library is not exploitable on its own. No public exploit code has been identified at time of analysis, EPSS is low at 0.24% (14th percentile), and the issue is not listed in CISA KEV, so the practical priority is moderate rather than urgent. The vendor-released fix is version 5.3.0, which also remediates four other deserialization flaws.
Out-of-bounds read in Apache DataSketches C++ versions 3.1.0 through 5.2.0 is reachable when an application deserializes a compact Theta sketch from an untrusted source, allowing unauthenticated remote attackers to crash the process (denial of service) and potentially disclose adjacent memory contents. The flaw sits in compact_theta_sketch::deserialize() and wrapped_compact_theta_sketch::wrap(), which parse header fields before verifying the input length; in the compressed format a 32-bit integer overflow defeats the length check and two decoding-controlling header fields go unvalidated, and the stream-based deserialization path is affected as well. Apache rates this issue low severity in its 5.3.0 release notes, no public exploit code has been identified at time of analysis, the vulnerability is not in CISA KEV, and EPSS is only 0.20% (9th percentile); exploitation requires the explicit, non-default precondition that the host application accept Theta sketch images from untrusted sources, so the practical priority is lower than the raw 9.1 CVSS might suggest.
Out-of-bounds read and write in the CPC sketch deserialization path of Apache DataSketches C++ (datasketches-cpp) - specifically cpc_sketch::deserialize() called on a byte buffer or a stream - allows a crafted serialized sketch to corrupt heap memory: the decompressor reads past the end of the compressed data because the read position was only checked after decoding finished, and in the hybrid flavor it writes outside an internal heap buffer because decoded row indices were not validated, crashing the process with potential for further exploitation. All releases from 2.0.0-incubating before 5.3.0 are affected, and the CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), indicating remote, unauthenticated impact, but reachability is conditional: only applications that deserialize CPC sketches from untrusted sources are exposed, since the flaw lives in a C++ library whose attack surface depends on the embedding application. Exploitation signals are mixed and should be weighed carefully - EPSS is only 0.19% (8th percentile), there is no CISA KEV entry, and no public exploit identified at time of analysis.
Heap buffer overflow in Apache DataSketches C++ (versions 1.0.0-incubating through 5.2.0) allows an unauthenticated remote attacker who can supply a crafted HLL sketch for deserialization to write up to 988 bytes past a fixed 8-entry internal heap buffer, corrupting memory, crashing the process, and potentially enabling further exploitation. The vulnerable code is a library routine with no network listener of its own, so real-world exposure hinges on whether the consuming application deserializes sketch images from untrusted byte buffers or streams; services that only process trusted or internally generated sketches are not realistically exposed despite the AV:N vector. No public exploit code has been identified at time of analysis, and EPSS is low at 0.21% (11th percentile), while the assessed CVSS 3.1 base of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects the worst case for applications that do accept untrusted sketches, meaning the high score and low observed exploitation signal must be weighed together.
Apache CXF versions prior to 4.2.4, 4.1.9, and 3.6.13 allow remote, unauthenticated attackers to cause a denial of service by submitting a very large XML document that exhausts memory and CPU during parsing. The flaw lies in StaxUtils, which by default imposes no limit on the total number of elements or characters, and is most impactful when CXF builds a DOM from the input, such as in SAAJ or WS-Security processing. No public exploit code has been identified, and deployments that enforce a request size limit are largely protected.
Man-in-the-middle attackers can impersonate any TLS server contacted by Apache CXF's optional Netty-based HTTP client transport, because cxf-rt-transports-http-netty-client validates the server certificate chain against the configured trust store but never checks that the certificate's hostname matches the host actually being called - a gap present over both HTTP/1.1 and HTTP/2 and present even with disableCNCheck left at its secure default of false. Applications running Apache CXF before 3.6.13, 4.1.9 or 4.2.4 that use this transport for outbound TLS calls are affected; an unauthenticated attacker who already holds a traffic-interception position and any certificate issued by a CA in the client's trust store (for example, a free publicly issued certificate for an attacker-controlled domain) can read or modify exchanged messages and credentials. No public exploit identified at time of analysis, and exploitation is gated by the requirement for an on-path MITM position plus a trusted-chain certificate, which is reflected in our assessed vector returning High attack complexity rather than the published AC:L; EPSS is correspondingly low at 0.11% (1st percentile), so this is a serious TLS trust failure rather than an immediate mass-exploitation priority. Vendor fixes are available in 3.6.13, 4.1.9 and 4.2.4.
Unbounded memory allocation in Apache CXF's multipart/MTOM attachment part-header parser lets a remote, unauthenticated attacker exhaust server memory and cause a denial of service by sending a single crafted multipart request. The parser applies attachment-max-header-size (default 300 characters) only per physical line and enforces attachment-headers-max-count (default 500) against distinct header names rather than total header lines, so folded continuation lines or a repeated header name slip past both limits and inflate the parsed value without bound. Affected are CXF 4.2.0 through 4.2.3, 4.0.0 through 4.1.8, and all releases before 3.6.13 that expose a multipart/MTOM-accepting endpoint; fixed releases are 4.2.4, 4.1.9 and 3.6.13. Exploitation requires no authentication (CVSS PR:N/UI:N) and no non-default configuration, but it is limited to availability impact only; EPSS is low at 0.24% (14th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis.
XML signature wrapping in Apache CXF's JAX-RS XML Security module allows remote, unauthenticated attackers to have unsigned content accepted as if it were covered by a trusted XML signature. Only deployments that consume inbound XML through CXF's XML Signature interceptors (XmlSigInHandler, XmlSigInInterceptor, or the streaming XmlSecInInterceptor) are exposed, and the attacker must first hold any XML document signed by a key the target trusts; that signed document can then be wrapped in forged content and repeatedly presented. Fixed versions 4.2.4, 4.1.9, and 3.6.13 address the issue; no public exploit code has been identified and EPSS is low (0.17%, 6th percentile), though integrity impact is rated High (CVSS 7.5).
Trust bypass in Apache CXF's STSTokenValidator allows a remote, unauthenticated attacker to have a forged SAML assertion signed with an untrusted certificate accepted as trusted without the assertion ever being validated by the Security Token Service. Only deployments that use STSTokenValidator to validate SAML tokens while leaving alwaysValidateToSts unset are affected, and exploitation additionally requires a race window in which the result of a concurrent legitimate request's successful trust check is read from shared state. No public exploit code or CISA KEV listing has been identified at time of analysis, EPSS is 0.17% (6th percentile), and vendor fixes are available in Apache CXF 4.2.4, 4.1.9 and 3.6.13.
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.
CPU exhaustion denial of service in Apache CXF's FIQL query parser allows remote attackers to degrade or stall a server by submitting a long search expression containing no recognizable operator, which drives the parser's operator-search logic into excessive combinatorial matching and burns CPU on a request-handling thread. Affected are CXF 3.6.x, 4.1.x and 4.2.x deployments that expose FIQL-based search/filter endpoints; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (base 7.5), meaning availability impact only, with confidentiality and integrity unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor-released fixes - 4.2.4, 4.1.9 and 3.6.13 - neutralize the long-input vector by capping FIQL expressions at 4 KiB by default while still permitting normal queries.
A remote, unauthenticated attacker can exhaust server heap memory in Apache CXF by submitting a small (kilobyte-scale) DEFLATE payload that inflates to gigabytes when the framework decompresses it without any output-size cap. The flaw is reachable through two deployment-specific paths: JWE decryption when the 'zip=DEF' compression header is present (for example a JoseSessionTokenProvider configured with RSA-OAEP key wrap), and SAML token inflation over the HTTP redirect or POST binding - in both cases decompression occurs before or independently of any trust, signature, or key validation, so no credentials or valid keys are needed. Impact is availability only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), with confirmed exploitation limited to reachable configurations; EPSS is 0.16% (4th percentile), no CISA KEV listing, and no public exploit identified at time of analysis. Vendor-released patches are available in 4.2.4, 4.1.9, and 3.6.13, which introduce a configurable 10 MiB inflation cap.
Concurrent token-exchange requests against Apache CXF's JPA-backed OAuth2 authorization code grant provider can redeem a single authorization code more than once, yielding multiple valid access tokens from one code. Only deployments running the JPA authorization code provider that persists codes to a shared relational database under READ_COMMITTED isolation and that expose the token endpoint to remote callers are affected; versions below 3.6.13, 4.0.0 through 4.1.8, and 4.2.0 through 4.2.3 are in scope. Exploitation is unauthenticated per the CVSS vector (PR:N) but carries a high attack-complexity rating because the attacker must already hold one unredeemed code and win a timing race, so success is probabilistic; EPSS is low at 0.22% (11th percentile) and no public exploit identified at time of analysis, making this a real-but-conditional risk rather than a mass-exploitation emergency.
Authentication bypass in Apache CXF's OidcClientCodeRequestFilter renders the max_age authentication-freshness check inoperative, allowing stale OIDC sessions to be accepted regardless of age when a relying party has configured setMaxAgeOffset to enforce step-up re-authentication. The defect stems from a milliseconds/seconds unit mismatch and inverted comparison polarity, silently defeating session-age validation; affected releases are Apache CXF 4.2.0 before 4.2.4, 4.0.0 before 4.1.9, and 3.6.x before 3.6.13. Vendor patches are available, no public exploit identified at time of analysis, and EPSS is low (0.23%), though exploitation requires the non-default setMaxAgeOffset setting, limiting real-world impact to deployments that opt into max_age policies.
Session fixation and cross-user session reuse in the Apache Jackrabbit WebDAV server lets remote attackers ride on a cached authenticated session, yielding high confidentiality and integrity impact with no credential check performed. The flaw affects Jackrabbit 2.20.0 through 2.20.17, 2.22.0 through 2.22.4, and 2.23.0 through 2.23.5, and is triggered whenever a request carries a Lock-Token, TransactionId, SubscriptionId, or If-header token value that matches a token bound to a session already held in the server's authenticated session cache. Per the vendor CVSS 4.0 vector the attack is network-reachable, requires no privileges (PR:N) and no user interaction (UI:N), with the practical limiting factor being that the attacker must obtain or guess a token that currently maps to a live cached session; no public exploit code has been identified at time of analysis, and the product does not confirm active exploitation.
Improper access control in Apache Traffic Server 9.0.0-9.2.14 and 10.0.0-10.1.3 allows unauthenticated remote requests that should have been denied to be forwarded to backend systems the proxy is meant to protect, yielding high confidentiality and integrity impact on those subsequent systems (SC:H/SI:H) with no direct impact on the Traffic Server host itself (VC:N/VI:N/VA:N). Exploitation is conditional, not routine: the CVSS 4.0 vector carries AT:P, meaning a specific attack requirement outside the attacker's direct control must be satisfied before a request succeeds, and this is corroborated by the independent assessment as a genuine but conditional risk rather than an urgent emergency. No public exploit code or confirmed active exploitation was identified at time of analysis; fixed versions are 9.2.15 and 10.1.4, and this CVE supersedes CVE-2026-41920, whose record understated the 9.x affected range as 9.0.0-9.1.14.
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.
Remote, unauthenticated attackers can crash applications built against Apache Thrift's c_glib (C/GLib) language bindings before version 0.25.0 by supplying crafted Thrift protocol input that triggers access of an uninitialized pointer (CWE-824), degrading availability with no confidentiality or integrity impact. The flaw carries a CVSS 4.0 score of 8.7 (assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and only deployments that use the c_glib binding and expose a Thrift endpoint to an attacker-reachable network are affected - services using Java, Python, Go or other bindings are not exposed to this particular defect. No public exploit code has been identified at time of analysis and there is no indication of confirmed active exploitation (CISA KEV); a vendor-released patch, version 0.25.0, is available.
Unauthenticated, network-reachable denial of service in Apache Thrift's PHP bindings before 0.25.0 lets attackers crash a Thrift service by sending crafted serialized messages that trigger a stack-based buffer overflow during protocol parsing. The vendor-supplied CVSS 4.0 score of 8.7 reflects high availability impact with no confidentiality or integrity impact (VC:N/VI:N/VA:H) and no privileges or user interaction required (PR:N/UI:N), and the assessed CVSS 3.1 vector agrees (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). No public exploit code or active exploitation has been identified at time of analysis, and the vendor scope bounds the consequence to service crash/denial of service rather than data disclosure or code execution.
Stack exhaustion in Apache Thrift before 0.25.0 allows remote, unauthenticated attackers to crash processes that deserialize attacker-controlled Thrift messages, because the protocol skip routine in several language bindings fails to apply the binding's recursion limit when skipping unknown fields. The affected bindings are the Python C++ accelerator (the pure-Python protocols are not affected), the PHP library and its thrift_protocol extension, and the Perl, Lua, Smalltalk and OCaml libraries; the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms the bug is reachable over the network with no privileges or user interaction, but the impact metrics (VC:N/VI:N/VA:H) restrict the consequence to availability loss. There is no code execution or data exposure, no public exploit code and no confirmed active exploitation at time of analysis, and Apache has released version 0.25.0 which restores the recursion limit.
Denial of service in Apache Thrift's c_glib (C/GLib) language bindings before 0.25.0, where a crafted or malformed message reaching the deserialization/parsing path triggers a NULL pointer dereference and uninitialized-variable use that crashes the process. The issue is remotely reachable and unauthenticated (CVSS:4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N with availability-high impact only), so any network-exposed Thrift service built on the c_glib binding is at risk of abrupt termination; confidentiality and integrity are unaffected. Only the c_glib binding is implicated - other Thrift bindings are not affected - and no public exploit code has been identified at time of analysis, with the vendor shipping a fix in 0.25.0.
Heap-based memory corruption in Apache Thrift versions before 0.25.0 lets unauthenticated remote attackers who can send Thrift protocol messages to a parsing service trigger an integer-overflow-driven undersized heap allocation followed by an out-of-bounds write, resulting in a crash (denial of service) or potentially attacker-controlled memory corruption with high confidentiality, integrity, and availability impact. The affected surface is any service that deserializes untrusted Thrift traffic; the CVSS v4.0 score of 9.2 reflects network reachability and no required privileges or user interaction, while the AC:H and AT:P metrics (mirrored by the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) indicate that a successful exploit depends on crafting malformed messages that reliably hit the overflow condition and on runtime factors such as heap layout, memory limits, and the specific protocol/transport in use. No public exploit code or confirmed active exploitation was identified at time of analysis, but the framework's broad embedding in RPC and serialization pipelines makes prompt upgrade to 0.25.0 the clear priority. Services that never parse Thrift input from untrusted or remote peers are not reachable through this vector.
Denial of service in Apache Thrift's Go bindings (all versions before 0.25.0) allows an unauthenticated remote peer to crash an entire Thrift-serving process by sending a single crafted frame over the TFramedTransport or THeaderTransport. A frame that yields no payload bytes causes the transport to recurse into Read rather than loop, so a peer can drive unbounded recursion with only 4 bytes (declared frame size of zero) or 18 bytes (a header block that fills the frame) until the Go stack limit is hit; the resulting runtime fatal error is not catchable by recover() and kills the process. The impact is availability-only - no confidentiality or integrity effect - and no public exploit code has been identified at time of analysis, though exploitation needs only network reachability to the Thrift listener with no authentication or user interaction (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/.../VA:H).
Memory exhaustion in Apache Thrift's Node.js and D language WebSocket server transports (all versions before 0.25.0) lets unauthenticated remote attackers commit 513 MiB on a Node.js server, or up to 2 GiB on the D transport, by sending a single ~14-byte frame that merely declares a huge payload length. The transport reads the length out of the WebSocket frame header and allocates that many bytes immediately, before the payload has actually arrived, so an extremely small request causes disproportionate memory growth; in the Node.js case the connection is left open afterwards, allowing the same frame to be resent repeatedly until the service is exhausted or killed. Impact is limited to availability (CVSS 4.0 8.7, CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), no authentication or user interaction is required, and no public exploit code was identified at time of analysis. Affected deployments are those exposing the Thrift WebSocket server transport from the Node.js or D bindings; other Thrift transports and language bindings are out of scope.
Denial of service in Apache Thrift's c_glib (C/GLib) language bindings, affecting all versions before 0.25.0, where a crafted or malformed Thrift message can drive the decoder into an infinite loop with an unreachable exit condition (CWE-835). The issue is remotely reachable and requires no authentication per the published CVSS 4.0 vector (PR:N), though the AT:P attack-requirements flag and our independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both indicate a specific input condition must be satisfied rather than arbitrary traffic. Impact is confined to availability - a hung thread, pinned CPU, or resource exhaustion that can stall or crash the service - with no data exposure, modification, or code execution; only applications that compile and use the c_glib bindings are affected, and no public exploit code has been identified at time of analysis. Upgrading to 0.25.0 removes the condition.
Denial of service in the PHP bindings of Apache Thrift before 0.25.0 allows unauthenticated remote attackers to exhaust process stack space and crash the parsing worker by supplying deeply nested or self-referential serialized Thrift messages. The flaw is an uncontrolled recursion (CWE-674) in the deserialization path, rated 8.2 High under CVSS 4.0 (AV:N/AC:L/AT:P/PR:N/UI:N/VA:H, with no confidentiality or integrity impact) and 8.2-equivalent High under the assessed CVSS 3.1 vector (A:H only), confirming that impact is confined to availability. Exploitation is not unconditional: the CVSS 4.0 AT:P attack-requirement flag reflects that the target service must actually accept and deserialize attacker-controllable Thrift payloads through the PHP bindings, so internal services processing only trusted, bounded data are not realistically exposed. There is no public exploit code and no confirmed active exploitation at time of analysis, and a vendor-released fix is available in Apache Thrift 0.25.0.
Denial of service in the Apache Thrift Perl bindings affects all releases before 0.25.0, allowing unauthenticated remote attackers to exhaust CPU or memory resources on services that deserialize attacker-controlled Thrift messages through the Perl language runtime. Only deployments using the Perl bindings are exposed; services built on the Java, Python, C++, or Go bindings are not affected by this specific flaw, and no public exploit code was identified at time of analysis, nor is there any CISA KEV confirmation of active exploitation. Impact is availability-only (no confidentiality or integrity loss), the vendor-released fix is Apache Thrift 0.25.0, and exploitation depends on the malicious input actually reaching the vulnerable parsing routine (the CVSS 4.0 AT:P / assessed AC:H condition).
Services that parse attacker-supplied input through Apache Thrift's Perl bindings before version 0.25.0 can be driven into an uncaught exception, crashing the hosting process or thread and causing a denial of service. The flaw is network-reachable and requires no authentication or user interaction (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N, score 8.2), but its impact is confined to availability (VA:H) with no confidentiality or integrity effect, and the CVSS 4.0 AT:P metric indicates a specific precondition - the attacker's input must actually reach the vulnerable Perl deserialization/handler path. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is resolved by the vendor's 0.25.0 release.
Uncaught exception handling in the Apache Thrift Ruby bindings lets unauthenticated remote attackers crash network-reachable Thrift RPC services running any version before 0.25.0. Per the assessed vector (AV:N/AC:L/PR:N/UI:N), no credentials, user interaction, or special configuration are required: any reachable Thrift Ruby service that parses attacker-supplied protocol messages can be knocked offline, though impact is limited to availability with no confidentiality or integrity loss. The flaw carries a CVSS 4.0 score of 8.7 (High) and an assessed CVSS 3.1 of 7.5, and no public exploit identified at time of analysis; exposure is confined to deployments using the Ruby language bindings rather than Thrift bindings for other languages.
Inefficient algorithmic complexity (CWE-407) in Apache Thrift's Lua bindings prior to version 0.25.0 allows remote, unauthenticated attackers to exhaust CPU and cause denial of service by supplying crafted input that the Lua binding parses. Only deployments that specifically use the Thrift Lua language binding and expose it to attacker-influenced data are affected; applications using other Thrift language bindings (Java, Python, C++, Go, etc.) are not impacted. The impact is limited to availability - no confidentiality or integrity loss is indicated by the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 8.7), and no public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in Apache Thrift's JavaME bindings (versions before 0.25.0) allows unauthenticated remote attackers to exhaust server resources by sending crafted Thrift protocol input, causing service outages. The flaw is CWE-770 (uncontrolled resource allocation) and is limited to availability impact; there is no confidentiality or integrity exposure. No public exploit code or active exploitation has been identified at time of analysis, and upgrading to 0.25.0 resolves the issue.
Unbounded resource allocation in the Ruby bindings of Apache Thrift (versions before 0.25.0) lets unauthenticated remote clients exhaust server memory or CPU by sending Thrift messages whose declared structure or container sizes trigger excessive allocation while the service deserializes them. Only network-reachable services that actually accept and parse untrusted Thrift payloads through the Ruby bindings are exposed, and the impact is confined to availability, with no data disclosure or modification (C:N/I:N/A:H). The Apache Software Foundation has released 0.25.0 as the fix; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor rates this 8.2 (High) under CVSS 4.0, while our independent assessment also treats it as High severity but notes a higher attack complexity (AC:H in v3.1 terms) because the attacker must reach a service that parses untrusted Thrift messages.
Denial of service in the Lua language bindings of Apache Thrift before 0.25.0 allows unauthenticated remote attackers to exhaust server resources by sending crafted Thrift messages that trigger uncontrolled allocation or inefficient algorithmic paths. The issue is limited to deployments that actively use the Lua bindings; other language bindings are unaffected. At time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified, and the impact is confined to availability-no data disclosure or code execution.
Denial of service in Apache Thrift Python bindings before 0.25.0 allows unauthenticated remote attackers to hang the service by sending crafted Thrift messages that drive the parser into an infinite loop (CWE-835). Exploitation is network-based but requires a specific condition, such as a particular protocol/transport or malformed message structure, to trigger the loop (AT:P / AC:H). The impact is limited to availability-no data disclosure or code execution-and only services exposing a Thrift endpoint that processes untrusted input using the Python bindings are affected; no public exploit code has been identified at time of analysis.
Denial of service in the Apache Thrift PHP bindings before version 0.25.0 allows unauthenticated remote attackers to exhaust server resources by sending crafted Thrift protocol messages that trigger inefficient algorithmic complexity (CWE-407). The vulnerability affects only applications that use the PHP bindings to deserialize untrusted Thrift input; other language bindings are unaffected. No public exploit code has been identified at the time of analysis, and the CVSS 4.0 AT:P metric indicates a specific attack precondition must be met, so exploitation is not guaranteed against every deployment.
Denial of service in the Dart language bindings of Apache Thrift before 0.25.0 allows unauthenticated remote attackers to exhaust server memory and CPU by sending crafted Thrift messages to a network-reachable Dart-based service that deserializes untrusted input (CWE-770, allocation of resources without limits or throttling). Impact is limited to availability (service slowdown or crash); there is no confidentiality or integrity consequence, and deployments using other Thrift language bindings such as C++, Java, Python or Go are not affected. No public exploit code was identified at time of analysis and the vendor-released fix that resolves the issue is Apache Thrift 0.25.0.
Denial of service in the Apache Thrift Node.js bindings (all versions before 0.25.0) lets remote, unauthenticated attackers crash the hosting Node.js process by delivering a crafted Thrift message that triggers an uncaught exception during deserialization. The vendor-supplied CVSS 4.0 score of 8.7 is driven entirely by availability impact (VA:H) with no confidentiality or integrity impact (VC:N/VI:N), and our independent assessment maps this to CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - no authentication, user interaction, or non-default configuration is required, so any deployment that parses untrusted Thrift input over the network is exposed. The practical risk is bounded by reachability: services that only accept trusted internal Thrift traffic are far less exposed. No public exploit code or confirmed active exploitation was identified at time of analysis. The description also cites improper validation of input quantities and prototype pollution, but the assessed impact per the vendor metrics remains availability-only.
Denial of service in Apache Thrift's Go bindings (versions before 0.25.0) lets unauthenticated remote attackers exhaust memory or CPU by sending highly compressed payloads over a compressed transport, so a tiny request expands into a disproportionately large in-memory buffer (CWE-409 data amplification / decompression bomb). Exploitation is conditional: per the vendor's CVSS 4.0 score the AT:P metric applies, meaning the affected service must actually accept attacker-supplied compressed data (for example a zlib-backed transport carrying untrusted input) - deployments of the Go bindings that do not parse compressed payloads from external sources are not exposed. Impact is availability-only (service crash, hang, or memory exhaustion) with no code execution or data disclosure; no public exploit code and no confirmed active exploitation were identified at time of analysis, and our independent assessment uses a 3.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflecting that precondition.
Denial of service in Apache Thrift's Python bindings before 0.25.0 arises from improper handling of highly compressed data (CWE-409), letting a remote, unauthenticated attacker send a small compressed Thrift payload that expands dramatically during parsing and exhausts server memory or CPU. Exploitation requires a service that accepts externally supplied Thrift data and decompresses or size-expands it, and the impact is confined to availability with no data disclosure or code execution. No public exploit code has been identified at time of analysis, and upgrading to 0.25.0 eliminates the vulnerability.
Denial of service in the D-language binding of Apache Thrift (thrift.server.nonblocking.TNonblockingServer) allows unauthenticated remote attackers to crash the server by sending a crafted or malformed message that provokes an uncaught exception and improper resource shutdown. Only deployments built with the D binding at versions before 0.25.0 and specifically using TNonblockingServer are affected, and the impact is limited to availability with no data exposure or modification. No public exploit code has been identified at time of analysis, and the vendor has released version 0.25.0 to fix the issue.
Unauthenticated remote attackers can crash applications that use the Apache Thrift PHP bindings prior to version 0.25.0 by supplying crafted Thrift protocol messages that trigger a NULL pointer dereference (CWE-476). The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) indicates the flaw is remotely reachable with low complexity and requires no authentication or user interaction, but the impact profile is availability-only (VC:N/VI:N/VA:H) - there is no confidentiality or integrity exposure, so the 8.7 score reflects a pure denial-of-service outcome rather than code execution. Exploitation is conditional on the target PHP service actually accepting and deserializing attacker-controlled Thrift input, and no public exploit code has been identified at time of analysis. A vendor patch is available in Apache Thrift 0.25.0, which per the advisory fixes the issue.
Denial of service in Apache Thrift deployments that use the D language bindings before version 0.25.0, where malformed input reaching the service endpoint triggers an uncaught exception, an infinite loop with an unreachable exit condition, and an integer underflow that can crash or hang the service. The assessed impact is availability-only (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor CVSS 4.0 base 8.7), meaning unauthenticated remote attackers who can reach a D-bindings Thrift service need no credentials, user interaction, or non-default configuration to cause disruption. Exposure is narrow because only services compiled against the D bindings are affected - Java, Python, C++, Go and other language binding deployments are not - and no public exploit code has been identified at time of analysis.
XML external entity injection in Apache Abdera (all versions) allows unauthenticated remote attackers to read sensitive data or trigger server-side requests when an application feeds attacker-controlled XML into Abdera's parser or JDBC adapter parsing paths. The project is retired and unsupported, so Apache states it will not issue a fix, and downstream products that still bundle the Abdera artifact remain exposed. No public exploit identified at time of analysis, and exploitation is deployment-dependent: the target must still embed Abdera and route untrusted XML to it.
Apache Traffic Server 9.2.15, 10.1.4, and 10.2.0 can be crashed by a remote, unauthenticated attacker through a null pointer dereference (CWE-476) while proxying chunked origin responses. The race requires a client POST request to be torn down via TCP half-close at the moment ATS reparses a chunked origin response from a reentrant write-ready callback, so it is timing-dependent and typically needs repeated attempts; impact is limited to denial of service (crash), with no code execution, data disclosure, or integrity loss. No public exploit was identified at time of analysis, and vendor-released fixed versions are 9.2.16, 10.1.5, and 10.2.1.
Unauthenticated remote clients can force Apache Traffic Server's origin_server_auth plugin to sign attacker-chosen AWS request headers with the proxy's own AWS credentials, potentially allowing access to or modification of origin resources permitted to that identity. The issue affects ATS 8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0, but only installations using the non-default plugin to sign origin requests with AWS credentials are exposed. The vendor rates it High with a CVSS 4.0 base score of 7.0; no public exploit identified at time of analysis.
Unauthenticated network access to the shared proxy cache is possible in Apache Traffic Server deployments that load and enable the experimental tsmemcache plugin, allowing remote attackers to read, modify, and delete cached objects without credentials. Affected releases span 8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0; the exposure is gated by the plugin being explicitly enabled and its memcache-style interface being network-reachable, since it is not active in a default installation. No public exploit code or confirmed active exploitation was identified at time of analysis, though the CVSS 4.0 base score of 9.4 and the unauthenticated nature of the interface once exposed make this a high-priority fix for anyone running the plugin.
Apache Traffic Server 9.2.15, 10.1.4, and 10.2.0 can be driven into a denial-of-service condition through log amplification: each internal '@' header stripped from a request causes an unthrottled diagnostic log line, so requests carrying many such headers generate disproportionate log writes. The issue is network-reachable and unauthenticated, with high availability impact when log storage, rotation, or retention is constrained; no public exploit identified at time of analysis.
Client-certificate authentication bypass in Apache Traffic Server (8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0) lets an unauthenticated remote attacker resume a previously negotiated TLS session against an SNI virtual host that is configured with the verify_client STRICT policy, reaching backends that should have demanded a client certificate. The attacker only needs to first establish a resumable session on a virtual host that does not require client certificates, then resume it against the protected host; deployments that do not use verify_client STRICT, or that do not share session state across SNI hosts, are not exposed. No public exploit code or active exploitation has been identified at time of analysis, and the practical risk is concentrated in multi-tenant TLS-termination front ends that mix mutual-TLS and non-mTLS virtual hosts on the same instance.
TLS client-certificate cross-contamination in Apache Traffic Server 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 lets an outbound (origin-facing) transaction configured to present one client certificate instead reuse a pooled TLS session that was authenticated with a different client certificate, so the origin may see, authorize, and log the wrong client identity. The issue only manifests where ATS is configured for outbound mutual TLS with more than one distinct client certificate while the default outbound session-sharing/pooling policy is left enabled; deployments without outbound client certificates, with a single client identity, or with session sharing disabled are not affected. Apache assigned the maximum CVSS 3.1 score of 10.0, while this assessment scores it AV:N/AC:H because triggering the wrong reuse depends on session-pool state and timing rather than an attacker-injected payload; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis. Vendor-released patches exist in 9.2.16, 10.1.5, and 10.2.1.
Malformed padded HTTP/2 DATA frames sent to Apache Traffic Server 8.x, 9.x, or 10.x proxies that forward to HTTP/1.1 origins can trigger an integer underflow and exhaust the origin's worker pool, causing denial of service for proxied traffic. The issue is remotely reachable without authentication or user interaction when HTTP/2 is enabled on the client-facing listener (CVSS 4.0 AV:N/AC:L/PR:N/UI:N; CVSS 3.1 S:C/A:H), and the availability impact is scored against the downstream origin rather than the ATS process itself. No public exploit identified at time of analysis.
Denial of service in Apache Traffic Server 8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 allows unauthenticated remote attackers to exhaust a downstream HTTP/1.1 origin's worker pool by sending a truncated HTTP/2 Content-Length value that ATS mishandles when relaying the request. The issue is limited to proxy deployments where ATS accepts HTTP/2 client connections and forwards traffic to an HTTP/1.1 origin; no public exploit code or confirmed active exploitation was identified at time of analysis.
Response-framing desync in Apache Traffic Server (8.0.0 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0) allows a malformed 302 response that should have been rejected as a parse error to pass the rejection path through the Transfer-Encoding: chunked carve-out, so the proxy stores and serves a response that different peers interpret differently. Per the CVSS vector the issue is remote and unauthenticated (AV:N/AC:L/PR:N/UI:N, scope changed, I:H/C:L), enabling cache poisoning and response-framing desync against deployments acting as caching or forwarding proxies. No public exploit code or CISA KEV entry is associated at time of analysis; the practical precondition is that a suitable malformed upstream response actually traverses the proxy. Fixed versions 9.2.16, 10.1.5, and 10.2.1 are published by the vendor.
Unauthenticated remote attackers can drive HTTP transactions to completion against Apache Traffic Server instances that have loaded the experimental WebAssembly plugin and trigger a use-after-free in the plugin's transaction-close handler, producing memory corruption that primarily threatens availability (high) with a limited integrity impact. The same plugin also passes unvalidated guest-supplied metric IDs straight into ATS's internal stats API, a path that requires the attacker to control or supply the wasm guest module. Exposure is limited to deployments that explicitly enable this non-default experimental plugin on versions 10.0.0 through 10.1.4 or 10.2.0; no public exploit identified at time of analysis.
Apache Traffic Server versions 8.0.1 through 8.1.11, 9.0.0 through 9.2.15, 10.0.0 through 10.1.4, and 10.2.0 ship an experimental 'magick' plugin that, in its default unsigned configuration, passes client-controlled data into ImageMagick 'convert' arguments, letting remote attackers inject command-line options (CWE-88 argument injection) with no authentication or user interaction. Because the plugin is experimental and not enabled by default, only deployments that deliberately loaded it without enabling request signing are exposed; those that are exposed face a CVSS 3.1 score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) with scope change and full confidentiality, integrity, and availability impact, since injected arguments can drive ImageMagick into reading or writing arbitrary files or executing delegated commands. No public exploit code or CISA KEV entry is associated with this CVE at time of analysis, but the impact on a vulnerable, enabled instance is total, and upgrading to 9.2.16, 10.1.5, or 10.2.1 is recommended.
Apache Pulsar deployments using the filesystem packages storage provider allow an authenticated user holding packages permission on any namespace to traverse out of their authorized tenant/namespace and download, overwrite, or delete packages belonging to other tenants or namespaces. The flaw is a CWE-22 path traversal in the unvalidated package version component; exploitation requires package management to be explicitly enabled and the non-default FileSystemPackagesStorageProvider to be configured, so default BookKeeper-backed deployments are not affected. No public exploit code was identified at time of analysis, and exploitation requires at least low-privilege authenticated access unless broker authentication is disabled, in which case any client able to reach the admin REST API can perform the operations without credentials.
Unauthenticated remote attackers can take full administrative control of Apache Pulsar Manager 0.3.0 and later by creating an administrator account through an endpoint that remains reachable after initialization, and every account has effective full privileges. In all versions, the manager proxies requests to the Pulsar admin API without enforcing its own authentication and can attach its configured Pulsar credential to a requester-chosen destination, allowing unauthenticated users to perform permitted admin operations and steal the credential. No public exploit code was identified at time of analysis, but the product is retired, unsupported, and will not receive fixes, so exposure persists until deployments are removed.
Apache Pulsar 2.8.1 through 4.0.13 and 4.1.0 through 4.2.4 can grant an authenticated low-privileged user the proxy's full privilege set - including superuser and tenant-admin rights - on the broker admin REST API, the functions worker, and the binary protocol when their requests are relayed by a Pulsar proxy. Two distinct weaknesses in the proxy-to-broker principal check (CWE-863) are involved: the original principal is authorized with the proxy's authentication data, letting MultiRolesTokenAuthorizationProvider or a custom data-driven provider expand the caller's roles to every role in the proxy's token, and a separate tenant-admin check succeeds whenever the proxy role itself is an admin of the tenant, even under the default provider. No public exploit code has been identified at time of analysis; exposure is limited to deployments that use the multi-role token provider or a data-driven custom provider, or that list a proxy role as a tenant admin.
Missing authorization in Apache Pulsar's shadow topic feature allows an authenticated tenant administrator to bind a topic in their own tenant to a persistent topic in another tenant through the PULSAR.SHADOW_SOURCE property, exposing retained messages and enabling destructive retention or deletion of the source topic's ledgers. This affects shadow-topic-capable releases before the fixed 4.0.14 and 4.2.5 versions under the default authorization provider, and no public exploit was identified at time of analysis.
Truncating a partitioned topic through the Apache Pulsar broker admin REST API succeeds without the caller holding tenant admin or superuser rights, letting an authenticated user wipe consumer backlog and destroy retained data on topics they merely have lookup permission for. The broker proxies each per-partition truncate request through its own internal admin client, so the tenant-admin authorization check is evaluated against the broker's configured identity rather than the caller's, and passes whenever that internal role is a superuser or tenant admin (the usual setup when authorization is enabled). Affected releases are 2.8.0 through 4.0.13 and 4.1.0 through 4.2.4, with fixes in 4.0.14 and 4.2.5; successful exploitation requires a valid authenticated identity, lookup permission on the target, a partitioned topic addressed by its partitioned name, and a suitably privileged broker internal client, and yields high integrity and availability impact with no confidentiality impact. No CISA KEV entry or public exploit code was identified at the time of analysis, and no EPSS score was supplied.
Unauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrary roles and have those roles honored when the broker uses MultiRolesTokenAuthorizationProvider alongside a non-empty anonymousUserRole. The flaw is reachable over the broker's HTTP surfaces, including the admin REST API and the WebSocket API, where failed credentials can fall back to the anonymous role while the original Authorization header is retained and later trusted without signature verification; an attacker who names a role configured in superUserRoles can obtain super-user access to tenants, namespaces, topics, permissions and broker configuration. Only deployments combining MultiRolesTokenAuthorizationProvider with a non-empty anonymousUserRole and the fallback conditions are exposed, while installations using the default PulsarAuthorizationProvider, another authorization provider, or an unset anonymousUserRole are unaffected. Vendor-released patch: 4.0.14 and 4.2.5; no public exploit identified at time of analysis, and exploitation also requires the specific non-default configuration described.
Denial of service in Apache bRPC servers that accept HTTP/2 traffic is caused by a malformed DATA frame with the PADDED flag set and a zero-length payload. An unauthenticated remote attacker with network reachability to an h2c- or TLS-ALPN-exposed HTTP/2 listener can trigger an integer underflow and out-of-bounds read, leading to high availability impact; versions before 1.18.0 are affected. No public exploit was identified at time of analysis, and the independent assessment rates the issue as network-reachable, low complexity, and requiring no privileges or user interaction.
Unauthenticated read access to the complete contents of prefixed system databases is possible in Apache CouchDB 3.5.2 and earlier because chttpd fails to enforce authorization on an API endpoint that serves those databases. Only deployments that have renamed their system databases with a prefix (a configuration the vendor calls 'very rare') are exposed - instances using the default _users and _replicator names are not exploitable - but where that condition holds, a remote attacker with network reach to the HTTP API can dump user credential documents or replication definitions without credentials or user interaction. Our assessment rates confidentiality impact as high with no integrity or availability effect, and no public exploit code or CISA KEV entry was identified at the time of analysis.
Memory-exhaustion denial of service in Apache CouchDB 3.5.2 and earlier allows any unauthenticated remote client to crash or hang the database by submitting a gzip-encoded HTTP request body that chttpd decompresses without any upper size bound. Impact is limited to availability - no data disclosure or modification - and the only practical prerequisite is network reachability of the CouchDB HTTP interface (typically 5984/6984), with no account, privileges, or victim interaction required. No public exploit code or confirmed active exploitation was identified at time of analysis; Apache has released CouchDB 3.5.3 to fix the issue, and instances sitting behind a proxy or WAF that caps request body size are substantially less exposed.
Arbitrary shell command execution in Apache CouchDB 3.5.2 and earlier on all platforms allows an authenticated CouchDB server administrator to run commands as the CouchDB operating-system user by setting an unvalidated runtime configuration value. The flaw crosses from application administration into host command execution, so the main risk is privilege escalation from CouchDB admin to the underlying host or misuse of stolen admin credentials; exploitation requires high-privilege authentication (PR:H) and is not remote-unauthenticated. Vendor-released patch: 3.5.3; no public exploit identified at time of analysis.
Apache Tomcat 11.0.0-M25 through 11.0.26 can split the body of a large non-blocking (NIO) response across the current request and the next request received on the same reused keep-alive connection, most likely causing the second request to fail and potentially leaking fragments of the first response to a different client. Remote, unauthenticated attackers can trigger the condition (CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H, 9.1 as published; our assessment raises attack complexity to High because the target must both perform large non-blocking writes and reuse the connection, and the corruption outcome is non-deterministic), so reliable attacker control over which or how much data leaks is not established. No public exploit code and no CISA KEV entry were identified at time of analysis, and 11.0.27 resolves the flaw.
Apache Tomcat 11.0.22-11.0.26, 10.1.55-10.1.60, and 9.0.118-9.0.122 contain an object-recycling race in HTTP/2 processing of asynchronous servlets that can mix up requests or responses between users. The issue is network-reachable and unauthenticated, but exploitation requires both HTTP/2 and asynchronous servlet use on the same deployment and depends on concurrent in-flight requests, so impact is probabilistic rather than deterministic. No public exploit code was identified at time of analysis and no CISA KEV confirmation was provided; fixed versions are 11.0.27, 10.1.61, and 9.0.123.
Authentication bypass in Apache Tomcat's JNDI realm allows unauthenticated remote attackers to log in without a valid password when the realm is configured with a non-GSSAPI SASL mechanism. The flaw affects 11.0.0-M1 through 11.0.26, 10.1.0-M1 through 10.1.60, and 9.0.0.M1 through 9.0.122, plus EOL 8.5.x and 7.0.x branches, and Apache has released fixes in 11.0.27, 10.1.61, and 9.0.123. No public exploit has been identified at time of analysis, and exploitation requires the non-default JNDIRealm/non-GSSAPI SASL configuration.
Unauthenticated information disclosure in Apache Cocoon can expose diagnostic interfaces, cache-triggering operations, verbose debug logging, and profile information to any user who can reach those endpoints; all versions are affected. The project is retired and no vendor fix is planned, so exposure is limited to deployments that leave diagnostic/debug endpoints accessible beyond trusted networks. No public exploit code or CISA KEV entry was identified at time of analysis.
Unauthenticated deserialization of attacker-controlled messages in Apache Camel's camel-jgroups consumer can lead to remote code execution in the Camel process. Any host that can reach the JGroups cluster's multicast group or bind port - adjacent network only, given the default UDP multicast stack - can join without credentials and deliver a crafted serialized object that JGroups deserializes on its own receive thread before Camel's routing logic ever runs. Code execution still depends on a usable gadget chain being present on the application classpath and on no JVM-wide -Djdk.serialFilter being configured, which is why the issue is assessed as high rather than critical; no public exploit code or confirmed active exploitation was identified at time of analysis. Deployments that explicitly configure a channel/channelProperties with AUTH and encryption, or that set a JVM-wide serialization filter, are not exploitable through this path.
XML external entity injection in the camel-smooks component of Apache Camel (versions 4.7.0 through 4.18.4 and 4.19.0 through 4.22.0) lets remote attackers who can supply or influence an XML message body that is unmarshalled by Smooks read files accessible to the Camel process and force it to issue requests to internal network hosts. No privileges or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N), and no non-default configuration is needed because external entity resolution was the default behaviour of the Woodstox SAX reader Smooks used; the confidentiality impact is high with a low availability impact, giving a base score of 8.2. The flaw is only reachable on routes that unmarshal XML through .unmarshal().smooks(...) or the smooks: component with its default reader, and full return of exfiltrated content depends on an InOut route binding the resolved entity into the reply, so no public exploit code or active exploitation has been identified at time of analysis, though the vendor has released fixed versions.
Credential disclosure in the Apache Camel camel-http component lets a malicious or compromised remote endpoint harvest OAuth2 bearer tokens and basic/digest credentials by answering a request with an HTTP redirect to a host it controls. The leak occurs because OAuth2ClientConfigurer's request interceptor sits in ProtocolExec, below RedirectExec, so 'Authorization: Bearer' headers are re-attached on every redirect hop, and because basic/digest credentials were registered against an AuthScope that matched any host. Affected are Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0; exploitation requires an endpoint with credentials configured and followRedirects=true (not the default) plus an attacker positioned to influence the target server's responses, and no public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
XML external entity injection in the Apache Camel XPath component lets unauthenticated remote attackers read files accessible to the Camel process and induce it to make outbound requests to attacker-named hosts when an expression is configured with documentType=InputSource and evaluates XML from an untrusted sender. The flaw is configuration-gated rather than default: Camel's default document type already refuses a DOCTYPE, so stock deployments are not exposed, but a deployment that selected InputSource for streaming reasons unknowingly also selected a weaker parser. Fixed in 4.23.0, 4.18.5 and 4.22.1; no public exploit identified at time of analysis, and the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects confidentiality impact only.
Expression language injection in the Apache Camel dynamic-router-control endpoint allows a party who can place a message on a transport feeding that endpoint to choose both the expression language and the predicate expression that Camel compiles and then evaluates against every exchange routed through the corresponding dynamic-router endpoint, running with the full privileges of the Camel process - effectively code execution. The issue affects Camel 4.4.0 through 4.18.4 and 4.19.0 through 4.22.0 (releases before 4.4.0 are not affected), scored CVSS 3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), so some access to the feeding transport is expected but no application-level authentication or user interaction is required. Exposure is limited to deployments that expose the control endpoint through a route forwarding messages from an external, shared or untrusted transport; no public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV).
Unauthenticated remote AS2 partners can turn an Apache Camel camel-as2 receiver into a server-side request forgery pivot: the component reads the asynchronous Message Disposition Notification (MDN) return address out of the inbound message and dials it verbatim, so the sender chooses the host the Camel instance connects to, including addresses only routable from inside the deployment's network. Deployments running Apache Camel 4.0.0 through 4.18.4 or 4.19.0 through 4.22.0 with an exposed camel-as2 receiver are affected; where mdnUserName, mdnPassword or mdnAccessToken are configured, the outbound receipt presents those MDN-delivery credentials to the attacker-chosen destination, which drives the high confidentiality component of the CVSS 3.1 score of 8.2 (CWE-918). No public exploit code has been identified at time of analysis, and vendor fixes are released in 4.23.0, 4.18.5 and 4.22.1; real-world urgency is moderated by whether the receiver is reachable by untrusted partners and whether credentials are attached to MDN delivery.
Authorization bypass in Apache Camel's camel-netty-http component allows remote unauthenticated attackers to reach protected routes by changing the case of characters in the request path so the security constraint no longer recognizes it while routing still dispatches to the endpoint. It affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1, with a CVSS score of 8.2; no public exploit identified at time of analysis.
Apache Camel's camel-oauth route guards fail open: when authentication cannot be completed, the OAuthBearerTokenProcessor and OAuthCodeFlow processors set an error status and body but never stop the exchange, so the request falls through and continues into the protected part of the route as if the caller had authenticated. Camel 4.11.0 through 4.18.4 and 4.19.0 through 4.22.0 are affected wherever camel-oauth is used to protect an HTTP-reachable endpoint, and exploitation needs no credentials, user interaction, or special configuration - simply omitting the Authorization header, sending a non-Bearer header, presenting an invalid token, or arriving without an authorization code is enough (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). The gap is a confidentiality problem first and foremost, exposing whatever the protected route returns, with limited integrity impact; no public exploit identified at time of analysis, and the vendor-released patch is 4.23.0, with backports in 4.18.5 and 4.22.1.
Path traversal in Apache Camel's remote-file consumers - the azure-files scheme named in this CVE plus the FTP/SFTP consumers sharing the RemoteFileConsumer base class - lets a malicious, compromised, or multi-tenant remote file server (or an on-path attacker on the integrity-free FTP control channel) cause Camel to read, delete, or rename files outside the directory it was configured to poll, using the endpoint's own credentials. Retrieval is reachable in the default consumer configuration because remote consumers download every listed file; deletion and renaming additionally require delete=true, move, preMove, moveFailed, or readLock=rename. The jailStartingDirectory option, enabled by default and documented as a boundary, did not constrain this remote operand before the fix, so it offered no protection; triggering the traversal requires control over a listing name returned by the server, and for azure-files specifically the Azure Files REST service does not normally return multi-segment names, making exploitation there impractical. No public exploit code or confirmed active exploitation was identified at time of analysis; vendor patches are available.
Path traversal in Apache Camel's remote-file consumers (including the SMB component's share-walking consumer) lets a directory listing entry that is not a single path segment resolve outside the polled remote directory, so Camel will retrieve, delete, or rename files outside that directory using the endpoint's own credentials. Affected are Camel 4.2.0 through 4.18.5-exclusive and 4.19.0 through 4.22.1-exclusive; file retrieval is reachable in a default consumer configuration, while deletion requires delete=true and renaming requires move, preMove, moveFailed, or readLock=rename. The CVSS 3.1 vector (7.4, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects unauthenticated reachability over the network with a high attack-complexity prerequisite: the remote server - or an on-path attacker rewriting an unprotected FTP LIST response, or a malicious, compromised, multi-tenant, or virtual-filesystem-backed server - must emit a qualifying listing name; for the SMB scheme a conforming SMB2 server will not do so, and no public exploit identified at time of analysis.
Path traversal in Apache Camel's remote-file consumers (the FTP, SFTP and mina-sftp schemes) lets a name reported in a remote server's directory listing resolve outside the directory Camel was configured to poll, so Camel will read, delete or rename files elsewhere using that endpoint's own credentials. Affected are Camel 4.18.0 through 4.18.4 and 4.19.0 through 4.22.0, with retrieval reachable in a default consumer configuration because remote consumers download every listed file (CVSS 3.1 base score 7.4, AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:N). The attacker must influence the LIST/SFTP listing output - via a malicious, compromised or multi-tenant server, a virtual-filesystem-backed server, or an on-path attacker against plaintext FTP whose control channel has no integrity protection - and no public exploit has been identified at time of analysis.
Apache Camel's ftp, ftps and sftp remote-file consumers build each file's remote path by concatenating the polled directory with the name returned in the server's directory listing, without any lexical normalization or containment check, so a listing entry containing parent-directory segments resolves outside the configured directory and is then read, deleted or renamed with the endpoint's own credentials. Affected are Camel 4.0.0 through 4.18.4, 4.19.0 through 4.22.0, and earlier; the 4.14.x stream is end-of-life and unfixed, while patches ship in 4.18.5, 4.22.1 and 4.23.0 (CPE: apache_software_foundation:apache_camel). Retrieval is reachable in a default consumer route, whereas deletion needs delete=true and renaming needs move, preMove, moveFailed or readLock=rename; the crucial caveat is that the jailStartingDirectory option, on by default and documented as confining Camel to the starting directory, does not constrain this remote path, so it cannot be used as a mitigation. There is confirmed no active exploitation tracked (not in CISA KEV) and no public exploit code identified at time of analysis, although the reporter privately demonstrated the issue end to end against an FTP endpoint; CVSS 7.4 with AC:H reflects that the attacker must first control or influence the remote server's LIST response rather than attack Camel directly.
Deserialization of untrusted data in the Apache Camel Spring Redis component (camel-spring-redis) allows an authenticated attacker who can either PUBLISH to a channel the route subscribes to, or write attacker-controlled bytes into a key the component later reads, to instantiate an arbitrary class graph in the application's JVM and execute its readObject method. Every release from 2.11.0 up to (but not including) 4.18.5 and 4.22.1 ships the affected default, which lazily builds a bare JdkSerializationRedisSerializer with no java.io.ObjectInputFilter whenever no serializer option is configured. No public exploit code was identified at time of analysis, but exploitation needs only a viable gadget on the classpath, which is why this carries CVSS 8.8 with high confidentiality and integrity impact.
Header-driven URI resolution in Apache Camel's HTTP producer components causes message-supplied CamelHttpUri and CamelRestHttpUri values to be expanded through CamelContext.resolvePropertyPlaceholders() before use, so an attacker who can influence those headers turns a URI string into a configuration-evaluation context and can read OS environment variables, JVM system properties, every registered secret-backend PropertiesFunction (AWS, Azure, GCP, HashiCorp, IBM, CyberArk, Kubernetes) and even invoke no-argument methods on beans in the registry. The flaw affects Apache Camel 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1 across camel-http, camel-http-common, camel-vertx-http, camel-undertow and camel-netty-http, and a plain static to(http://backend/api) route is enough to be exposed; no authentication is required where a route is reachable by untrusted senders (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, 8.2). Exploitation yields a high-confidentiality but limited-integrity impact, and while no public exploit code or CISA KEV entry exists at time of analysis, the preconditions are ordinary and the vendor has shipped fixes, so this warrants prioritised patching.
Unauthenticated remote code execution affects the camel-hazelcast component of Apache Camel 4.0.0 through 4.18.4 and 4.19.0 through 4.22.0, where two self-built Hazelcast bootstrap paths create instances without the default JavaSerializationFilterConfig added for CVE-2026-43865. A route using ReplicatedHazelcastAggregationRepository without an injected hazelcastInstance, or a client-mode endpoint built by HazelcastDefaultComponent#getOrCreateHzClientInstance() when neither a ClientConfig nor hazelcastConfigUri is supplied, will accept and deserialize arbitrary Java objects published into the backing cluster, letting an attacker who can write into that cluster execute code before Camel ever processes the exchange. Hazelcast clusters ship without authentication or TLS by default, so the write prerequisite is often met in practice; no public exploit code or CISA KEV entry was identified at time of analysis, but the vendor has published fixed releases and the missing-filter condition requires no unsafe opt-in by the deployer.
Apache Kylin versions 4 through 5.0.4 expose sensitive information to unauthorized actors through a CWE-200 flaw that, per the CVSS vector, can be reached remotely without authentication or user interaction (CVSS 3.1: 7.5). The advisory does not specify the exact endpoint or configuration condition, so practical exposure depends on whether a vulnerable Kylin instance is network-reachable; Kylin is typically deployed inside internal big-data and analytics clusters. No public exploit code or CISA KEV entry was identified at time of analysis, and EPSS is low at 0.20% (9th percentile).
Code injection in Apache Kylin 4.0.0 through 5.0.4 allows an authenticated low-privilege user who can supply or influence a JDBC connection URL to inject a crafted special parameter and execute arbitrary code. The vendor limits practical exposure to Kylin services directly reachable from the public network, noting that in-house deployments are mostly unaffected; no public exploit code has been identified at time of analysis and EPSS is low at roughly 0.23%.
Unauthenticated SQL injection in Apache Kylin 5.0.0 through 5.0.4 lets a remote network attacker reach a backend cache API that lacks authentication and execute injected SQL against the underlying data store, carrying CVSS 9.8 (AV:N/AC:L/PR:N/UI:N, full confidentiality, integrity and availability impact). Exploitation is primarily gated by exposure rather than by attacker capability: the vendor states the issue mainly threatens Kylin services directly reachable from the public internet, which it describes as uncommon, and in-house deployments kept on internal networks are largely unaffected. No public exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is low at 0.30% (21st percentile).
Apache Kylin 4 through 5.0.4 performs unsafe Java deserialization of data returned by a configured external cache service, enabling remote code execution if an attacker can control or impersonate that cache. The authoritative assessment rates this as network-reachable with high attack complexity and no privileges required, because exploitation depends on the external-cache precondition rather than a default Kylin endpoint. No public exploit identified at time of analysis or CISA KEV entry was available; EPSS is 0.36% (28th percentile), and the vendor-released fix is 5.0.5.
Unauthenticated retrieval of sensitive backend metadata is possible in Apache Kylin 4.x through 5.0.4 because the metadata dump API performs no authorization check and does not confine the requested path to an intended location. The CVSS vector (AV:N/AC:L/PR:N/UI:N) means any party who can reach that API over the network can invoke it without credentials or user interaction; per our assessment the confirmed impact is confidentiality only (C:H/I:N/A:N), even though the NVD-published score of 9.1 also claims integrity impact. Apache explicitly limits the practical risk to installations where the Kylin backend is directly exposed to the public internet - an uncommon posture - so standard internally segmented deployments are largely unaffected. No public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is low at 0.19% (8th percentile), which reinforces that this is an exposure-dependent issue rather than a broadly exploited one.
Unauthenticated exposure of system-level configuration information in Apache Kylin 4.0.0 through 5.0.4 lets any client that can reach the Kylin service retrieve sensitive deployment details, rated CVSS 3.1 base 7.5 (HIGH) with high confidentiality impact but no integrity or availability effect. Per the assessed vector (AV:N/AC:L/PR:N/UI:N), no authentication, user interaction, or non-default configuration is required, so default-reachable instances are exposed; exposure is limited mainly by whether the instance is network-reachable, and deployments confined to internal networks or placed behind authenticating proxies are significantly less at risk. No public exploit code and no CISA KEV entry were identified at time of analysis, and no EPSS score was supplied, so prioritization should be driven by network exposure of Kylin installations rather than by observed exploitation. Upgrading to 5.0.5 is the vendor-recommended fix.
Apache Airflow's SSH and SFTP provider hooks accept any server host key by default, so an attacker positioned as a machine-in-the-middle between an Airflow worker and an SSH or SFTP endpoint can impersonate that server and capture task credentials or transferred data. All releases of apache-airflow-providers-ssh and apache-airflow-providers-sftp before 7.0.0 are affected when a connection has neither host_key configured nor no_host_key_check explicitly disabled; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, i.e. unauthenticated from the attacker's side but gated on the high-complexity MITM prerequisite, which is why the input's 9.1 rating overstates practical urgency. No public exploit code has been identified and EPSS is only 0.18% (7th percentile); vendor patches (provider 7.0.0) are released, and the related deferrable-SFTP path is tracked separately as CVE-2026-94135, which the same SFTP 7.0.0 release also fixes.
Out-of-bounds read in Apache DataSketches C++ (datasketches-cpp) allows an attacker who controls a serialized VarOpt union image to trigger reads of up to 24 bytes past the end of the supplied buffer, causing a crash (denial of service) and potentially leaking adjacent heap memory into the deserialized union's state. Applications are exposed only if they call var_opt_union::deserialize() on data from untrusted sources; affected releases are 2.0.0-incubating through 5.2.0, and the library is not exploitable on its own. No public exploit code has been identified at time of analysis, EPSS is low at 0.24% (14th percentile), and the issue is not listed in CISA KEV, so the practical priority is moderate rather than urgent. The vendor-released fix is version 5.3.0, which also remediates four other deserialization flaws.
Out-of-bounds read in Apache DataSketches C++ versions 3.1.0 through 5.2.0 is reachable when an application deserializes a compact Theta sketch from an untrusted source, allowing unauthenticated remote attackers to crash the process (denial of service) and potentially disclose adjacent memory contents. The flaw sits in compact_theta_sketch::deserialize() and wrapped_compact_theta_sketch::wrap(), which parse header fields before verifying the input length; in the compressed format a 32-bit integer overflow defeats the length check and two decoding-controlling header fields go unvalidated, and the stream-based deserialization path is affected as well. Apache rates this issue low severity in its 5.3.0 release notes, no public exploit code has been identified at time of analysis, the vulnerability is not in CISA KEV, and EPSS is only 0.20% (9th percentile); exploitation requires the explicit, non-default precondition that the host application accept Theta sketch images from untrusted sources, so the practical priority is lower than the raw 9.1 CVSS might suggest.
Out-of-bounds read and write in the CPC sketch deserialization path of Apache DataSketches C++ (datasketches-cpp) - specifically cpc_sketch::deserialize() called on a byte buffer or a stream - allows a crafted serialized sketch to corrupt heap memory: the decompressor reads past the end of the compressed data because the read position was only checked after decoding finished, and in the hybrid flavor it writes outside an internal heap buffer because decoded row indices were not validated, crashing the process with potential for further exploitation. All releases from 2.0.0-incubating before 5.3.0 are affected, and the CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), indicating remote, unauthenticated impact, but reachability is conditional: only applications that deserialize CPC sketches from untrusted sources are exposed, since the flaw lives in a C++ library whose attack surface depends on the embedding application. Exploitation signals are mixed and should be weighed carefully - EPSS is only 0.19% (8th percentile), there is no CISA KEV entry, and no public exploit identified at time of analysis.
Heap buffer overflow in Apache DataSketches C++ (versions 1.0.0-incubating through 5.2.0) allows an unauthenticated remote attacker who can supply a crafted HLL sketch for deserialization to write up to 988 bytes past a fixed 8-entry internal heap buffer, corrupting memory, crashing the process, and potentially enabling further exploitation. The vulnerable code is a library routine with no network listener of its own, so real-world exposure hinges on whether the consuming application deserializes sketch images from untrusted byte buffers or streams; services that only process trusted or internally generated sketches are not realistically exposed despite the AV:N vector. No public exploit code has been identified at time of analysis, and EPSS is low at 0.21% (11th percentile), while the assessed CVSS 3.1 base of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects the worst case for applications that do accept untrusted sketches, meaning the high score and low observed exploitation signal must be weighed together.
Apache CXF versions prior to 4.2.4, 4.1.9, and 3.6.13 allow remote, unauthenticated attackers to cause a denial of service by submitting a very large XML document that exhausts memory and CPU during parsing. The flaw lies in StaxUtils, which by default imposes no limit on the total number of elements or characters, and is most impactful when CXF builds a DOM from the input, such as in SAAJ or WS-Security processing. No public exploit code has been identified, and deployments that enforce a request size limit are largely protected.
Man-in-the-middle attackers can impersonate any TLS server contacted by Apache CXF's optional Netty-based HTTP client transport, because cxf-rt-transports-http-netty-client validates the server certificate chain against the configured trust store but never checks that the certificate's hostname matches the host actually being called - a gap present over both HTTP/1.1 and HTTP/2 and present even with disableCNCheck left at its secure default of false. Applications running Apache CXF before 3.6.13, 4.1.9 or 4.2.4 that use this transport for outbound TLS calls are affected; an unauthenticated attacker who already holds a traffic-interception position and any certificate issued by a CA in the client's trust store (for example, a free publicly issued certificate for an attacker-controlled domain) can read or modify exchanged messages and credentials. No public exploit identified at time of analysis, and exploitation is gated by the requirement for an on-path MITM position plus a trusted-chain certificate, which is reflected in our assessed vector returning High attack complexity rather than the published AC:L; EPSS is correspondingly low at 0.11% (1st percentile), so this is a serious TLS trust failure rather than an immediate mass-exploitation priority. Vendor fixes are available in 3.6.13, 4.1.9 and 4.2.4.
Unbounded memory allocation in Apache CXF's multipart/MTOM attachment part-header parser lets a remote, unauthenticated attacker exhaust server memory and cause a denial of service by sending a single crafted multipart request. The parser applies attachment-max-header-size (default 300 characters) only per physical line and enforces attachment-headers-max-count (default 500) against distinct header names rather than total header lines, so folded continuation lines or a repeated header name slip past both limits and inflate the parsed value without bound. Affected are CXF 4.2.0 through 4.2.3, 4.0.0 through 4.1.8, and all releases before 3.6.13 that expose a multipart/MTOM-accepting endpoint; fixed releases are 4.2.4, 4.1.9 and 3.6.13. Exploitation requires no authentication (CVSS PR:N/UI:N) and no non-default configuration, but it is limited to availability impact only; EPSS is low at 0.24% (14th percentile) and no public exploit code or confirmed active exploitation was identified at time of analysis.
XML signature wrapping in Apache CXF's JAX-RS XML Security module allows remote, unauthenticated attackers to have unsigned content accepted as if it were covered by a trusted XML signature. Only deployments that consume inbound XML through CXF's XML Signature interceptors (XmlSigInHandler, XmlSigInInterceptor, or the streaming XmlSecInInterceptor) are exposed, and the attacker must first hold any XML document signed by a key the target trusts; that signed document can then be wrapped in forged content and repeatedly presented. Fixed versions 4.2.4, 4.1.9, and 3.6.13 address the issue; no public exploit code has been identified and EPSS is low (0.17%, 6th percentile), though integrity impact is rated High (CVSS 7.5).
Trust bypass in Apache CXF's STSTokenValidator allows a remote, unauthenticated attacker to have a forged SAML assertion signed with an untrusted certificate accepted as trusted without the assertion ever being validated by the Security Token Service. Only deployments that use STSTokenValidator to validate SAML tokens while leaving alwaysValidateToSts unset are affected, and exploitation additionally requires a race window in which the result of a concurrent legitimate request's successful trust check is read from shared state. No public exploit code or CISA KEV listing has been identified at time of analysis, EPSS is 0.17% (6th percentile), and vendor fixes are available in Apache CXF 4.2.4, 4.1.9 and 3.6.13.
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.
CPU exhaustion denial of service in Apache CXF's FIQL query parser allows remote attackers to degrade or stall a server by submitting a long search expression containing no recognizable operator, which drives the parser's operator-search logic into excessive combinatorial matching and burns CPU on a request-handling thread. Affected are CXF 3.6.x, 4.1.x and 4.2.x deployments that expose FIQL-based search/filter endpoints; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (base 7.5), meaning availability impact only, with confidentiality and integrity unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor-released fixes - 4.2.4, 4.1.9 and 3.6.13 - neutralize the long-input vector by capping FIQL expressions at 4 KiB by default while still permitting normal queries.
A remote, unauthenticated attacker can exhaust server heap memory in Apache CXF by submitting a small (kilobyte-scale) DEFLATE payload that inflates to gigabytes when the framework decompresses it without any output-size cap. The flaw is reachable through two deployment-specific paths: JWE decryption when the 'zip=DEF' compression header is present (for example a JoseSessionTokenProvider configured with RSA-OAEP key wrap), and SAML token inflation over the HTTP redirect or POST binding - in both cases decompression occurs before or independently of any trust, signature, or key validation, so no credentials or valid keys are needed. Impact is availability only (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5), with confirmed exploitation limited to reachable configurations; EPSS is 0.16% (4th percentile), no CISA KEV listing, and no public exploit identified at time of analysis. Vendor-released patches are available in 4.2.4, 4.1.9, and 3.6.13, which introduce a configurable 10 MiB inflation cap.
Concurrent token-exchange requests against Apache CXF's JPA-backed OAuth2 authorization code grant provider can redeem a single authorization code more than once, yielding multiple valid access tokens from one code. Only deployments running the JPA authorization code provider that persists codes to a shared relational database under READ_COMMITTED isolation and that expose the token endpoint to remote callers are affected; versions below 3.6.13, 4.0.0 through 4.1.8, and 4.2.0 through 4.2.3 are in scope. Exploitation is unauthenticated per the CVSS vector (PR:N) but carries a high attack-complexity rating because the attacker must already hold one unredeemed code and win a timing race, so success is probabilistic; EPSS is low at 0.22% (11th percentile) and no public exploit identified at time of analysis, making this a real-but-conditional risk rather than a mass-exploitation emergency.
Authentication bypass in Apache CXF's OidcClientCodeRequestFilter renders the max_age authentication-freshness check inoperative, allowing stale OIDC sessions to be accepted regardless of age when a relying party has configured setMaxAgeOffset to enforce step-up re-authentication. The defect stems from a milliseconds/seconds unit mismatch and inverted comparison polarity, silently defeating session-age validation; affected releases are Apache CXF 4.2.0 before 4.2.4, 4.0.0 before 4.1.9, and 3.6.x before 3.6.13. Vendor patches are available, no public exploit identified at time of analysis, and EPSS is low (0.23%), though exploitation requires the non-default setMaxAgeOffset setting, limiting real-world impact to deployments that opt into max_age policies.
Session fixation and cross-user session reuse in the Apache Jackrabbit WebDAV server lets remote attackers ride on a cached authenticated session, yielding high confidentiality and integrity impact with no credential check performed. The flaw affects Jackrabbit 2.20.0 through 2.20.17, 2.22.0 through 2.22.4, and 2.23.0 through 2.23.5, and is triggered whenever a request carries a Lock-Token, TransactionId, SubscriptionId, or If-header token value that matches a token bound to a session already held in the server's authenticated session cache. Per the vendor CVSS 4.0 vector the attack is network-reachable, requires no privileges (PR:N) and no user interaction (UI:N), with the practical limiting factor being that the attacker must obtain or guess a token that currently maps to a live cached session; no public exploit code has been identified at time of analysis, and the product does not confirm active exploitation.
Improper access control in Apache Traffic Server 9.0.0-9.2.14 and 10.0.0-10.1.3 allows unauthenticated remote requests that should have been denied to be forwarded to backend systems the proxy is meant to protect, yielding high confidentiality and integrity impact on those subsequent systems (SC:H/SI:H) with no direct impact on the Traffic Server host itself (VC:N/VI:N/VA:N). Exploitation is conditional, not routine: the CVSS 4.0 vector carries AT:P, meaning a specific attack requirement outside the attacker's direct control must be satisfied before a request succeeds, and this is corroborated by the independent assessment as a genuine but conditional risk rather than an urgent emergency. No public exploit code or confirmed active exploitation was identified at time of analysis; fixed versions are 9.2.15 and 10.1.4, and this CVE supersedes CVE-2026-41920, whose record understated the 9.x affected range as 9.0.0-9.1.14.
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.
Remote, unauthenticated attackers can crash applications built against Apache Thrift's c_glib (C/GLib) language bindings before version 0.25.0 by supplying crafted Thrift protocol input that triggers access of an uninitialized pointer (CWE-824), degrading availability with no confidentiality or integrity impact. The flaw carries a CVSS 4.0 score of 8.7 (assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and only deployments that use the c_glib binding and expose a Thrift endpoint to an attacker-reachable network are affected - services using Java, Python, Go or other bindings are not exposed to this particular defect. No public exploit code has been identified at time of analysis and there is no indication of confirmed active exploitation (CISA KEV); a vendor-released patch, version 0.25.0, is available.
Unauthenticated, network-reachable denial of service in Apache Thrift's PHP bindings before 0.25.0 lets attackers crash a Thrift service by sending crafted serialized messages that trigger a stack-based buffer overflow during protocol parsing. The vendor-supplied CVSS 4.0 score of 8.7 reflects high availability impact with no confidentiality or integrity impact (VC:N/VI:N/VA:H) and no privileges or user interaction required (PR:N/UI:N), and the assessed CVSS 3.1 vector agrees (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). No public exploit code or active exploitation has been identified at time of analysis, and the vendor scope bounds the consequence to service crash/denial of service rather than data disclosure or code execution.
Stack exhaustion in Apache Thrift before 0.25.0 allows remote, unauthenticated attackers to crash processes that deserialize attacker-controlled Thrift messages, because the protocol skip routine in several language bindings fails to apply the binding's recursion limit when skipping unknown fields. The affected bindings are the Python C++ accelerator (the pure-Python protocols are not affected), the PHP library and its thrift_protocol extension, and the Perl, Lua, Smalltalk and OCaml libraries; the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms the bug is reachable over the network with no privileges or user interaction, but the impact metrics (VC:N/VI:N/VA:H) restrict the consequence to availability loss. There is no code execution or data exposure, no public exploit code and no confirmed active exploitation at time of analysis, and Apache has released version 0.25.0 which restores the recursion limit.
Denial of service in Apache Thrift's c_glib (C/GLib) language bindings before 0.25.0, where a crafted or malformed message reaching the deserialization/parsing path triggers a NULL pointer dereference and uninitialized-variable use that crashes the process. The issue is remotely reachable and unauthenticated (CVSS:4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N with availability-high impact only), so any network-exposed Thrift service built on the c_glib binding is at risk of abrupt termination; confidentiality and integrity are unaffected. Only the c_glib binding is implicated - other Thrift bindings are not affected - and no public exploit code has been identified at time of analysis, with the vendor shipping a fix in 0.25.0.
Heap-based memory corruption in Apache Thrift versions before 0.25.0 lets unauthenticated remote attackers who can send Thrift protocol messages to a parsing service trigger an integer-overflow-driven undersized heap allocation followed by an out-of-bounds write, resulting in a crash (denial of service) or potentially attacker-controlled memory corruption with high confidentiality, integrity, and availability impact. The affected surface is any service that deserializes untrusted Thrift traffic; the CVSS v4.0 score of 9.2 reflects network reachability and no required privileges or user interaction, while the AC:H and AT:P metrics (mirrored by the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) indicate that a successful exploit depends on crafting malformed messages that reliably hit the overflow condition and on runtime factors such as heap layout, memory limits, and the specific protocol/transport in use. No public exploit code or confirmed active exploitation was identified at time of analysis, but the framework's broad embedding in RPC and serialization pipelines makes prompt upgrade to 0.25.0 the clear priority. Services that never parse Thrift input from untrusted or remote peers are not reachable through this vector.
Denial of service in Apache Thrift's Go bindings (all versions before 0.25.0) allows an unauthenticated remote peer to crash an entire Thrift-serving process by sending a single crafted frame over the TFramedTransport or THeaderTransport. A frame that yields no payload bytes causes the transport to recurse into Read rather than loop, so a peer can drive unbounded recursion with only 4 bytes (declared frame size of zero) or 18 bytes (a header block that fills the frame) until the Go stack limit is hit; the resulting runtime fatal error is not catchable by recover() and kills the process. The impact is availability-only - no confidentiality or integrity effect - and no public exploit code has been identified at time of analysis, though exploitation needs only network reachability to the Thrift listener with no authentication or user interaction (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/.../VA:H).
Memory exhaustion in Apache Thrift's Node.js and D language WebSocket server transports (all versions before 0.25.0) lets unauthenticated remote attackers commit 513 MiB on a Node.js server, or up to 2 GiB on the D transport, by sending a single ~14-byte frame that merely declares a huge payload length. The transport reads the length out of the WebSocket frame header and allocates that many bytes immediately, before the payload has actually arrived, so an extremely small request causes disproportionate memory growth; in the Node.js case the connection is left open afterwards, allowing the same frame to be resent repeatedly until the service is exhausted or killed. Impact is limited to availability (CVSS 4.0 8.7, CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), no authentication or user interaction is required, and no public exploit code was identified at time of analysis. Affected deployments are those exposing the Thrift WebSocket server transport from the Node.js or D bindings; other Thrift transports and language bindings are out of scope.
Denial of service in Apache Thrift's c_glib (C/GLib) language bindings, affecting all versions before 0.25.0, where a crafted or malformed Thrift message can drive the decoder into an infinite loop with an unreachable exit condition (CWE-835). The issue is remotely reachable and requires no authentication per the published CVSS 4.0 vector (PR:N), though the AT:P attack-requirements flag and our independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both indicate a specific input condition must be satisfied rather than arbitrary traffic. Impact is confined to availability - a hung thread, pinned CPU, or resource exhaustion that can stall or crash the service - with no data exposure, modification, or code execution; only applications that compile and use the c_glib bindings are affected, and no public exploit code has been identified at time of analysis. Upgrading to 0.25.0 removes the condition.
Denial of service in the PHP bindings of Apache Thrift before 0.25.0 allows unauthenticated remote attackers to exhaust process stack space and crash the parsing worker by supplying deeply nested or self-referential serialized Thrift messages. The flaw is an uncontrolled recursion (CWE-674) in the deserialization path, rated 8.2 High under CVSS 4.0 (AV:N/AC:L/AT:P/PR:N/UI:N/VA:H, with no confidentiality or integrity impact) and 8.2-equivalent High under the assessed CVSS 3.1 vector (A:H only), confirming that impact is confined to availability. Exploitation is not unconditional: the CVSS 4.0 AT:P attack-requirement flag reflects that the target service must actually accept and deserialize attacker-controllable Thrift payloads through the PHP bindings, so internal services processing only trusted, bounded data are not realistically exposed. There is no public exploit code and no confirmed active exploitation at time of analysis, and a vendor-released fix is available in Apache Thrift 0.25.0.
Denial of service in the Apache Thrift Perl bindings affects all releases before 0.25.0, allowing unauthenticated remote attackers to exhaust CPU or memory resources on services that deserialize attacker-controlled Thrift messages through the Perl language runtime. Only deployments using the Perl bindings are exposed; services built on the Java, Python, C++, or Go bindings are not affected by this specific flaw, and no public exploit code was identified at time of analysis, nor is there any CISA KEV confirmation of active exploitation. Impact is availability-only (no confidentiality or integrity loss), the vendor-released fix is Apache Thrift 0.25.0, and exploitation depends on the malicious input actually reaching the vulnerable parsing routine (the CVSS 4.0 AT:P / assessed AC:H condition).
Services that parse attacker-supplied input through Apache Thrift's Perl bindings before version 0.25.0 can be driven into an uncaught exception, crashing the hosting process or thread and causing a denial of service. The flaw is network-reachable and requires no authentication or user interaction (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N, score 8.2), but its impact is confined to availability (VA:H) with no confidentiality or integrity effect, and the CVSS 4.0 AT:P metric indicates a specific precondition - the attacker's input must actually reach the vulnerable Perl deserialization/handler path. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is resolved by the vendor's 0.25.0 release.
Uncaught exception handling in the Apache Thrift Ruby bindings lets unauthenticated remote attackers crash network-reachable Thrift RPC services running any version before 0.25.0. Per the assessed vector (AV:N/AC:L/PR:N/UI:N), no credentials, user interaction, or special configuration are required: any reachable Thrift Ruby service that parses attacker-supplied protocol messages can be knocked offline, though impact is limited to availability with no confidentiality or integrity loss. The flaw carries a CVSS 4.0 score of 8.7 (High) and an assessed CVSS 3.1 of 7.5, and no public exploit identified at time of analysis; exposure is confined to deployments using the Ruby language bindings rather than Thrift bindings for other languages.
Inefficient algorithmic complexity (CWE-407) in Apache Thrift's Lua bindings prior to version 0.25.0 allows remote, unauthenticated attackers to exhaust CPU and cause denial of service by supplying crafted input that the Lua binding parses. Only deployments that specifically use the Thrift Lua language binding and expose it to attacker-influenced data are affected; applications using other Thrift language bindings (Java, Python, C++, Go, etc.) are not impacted. The impact is limited to availability - no confidentiality or integrity loss is indicated by the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 8.7), and no public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in Apache Thrift's JavaME bindings (versions before 0.25.0) allows unauthenticated remote attackers to exhaust server resources by sending crafted Thrift protocol input, causing service outages. The flaw is CWE-770 (uncontrolled resource allocation) and is limited to availability impact; there is no confidentiality or integrity exposure. No public exploit code or active exploitation has been identified at time of analysis, and upgrading to 0.25.0 resolves the issue.
Unbounded resource allocation in the Ruby bindings of Apache Thrift (versions before 0.25.0) lets unauthenticated remote clients exhaust server memory or CPU by sending Thrift messages whose declared structure or container sizes trigger excessive allocation while the service deserializes them. Only network-reachable services that actually accept and parse untrusted Thrift payloads through the Ruby bindings are exposed, and the impact is confined to availability, with no data disclosure or modification (C:N/I:N/A:H). The Apache Software Foundation has released 0.25.0 as the fix; no public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor rates this 8.2 (High) under CVSS 4.0, while our independent assessment also treats it as High severity but notes a higher attack complexity (AC:H in v3.1 terms) because the attacker must reach a service that parses untrusted Thrift messages.
Denial of service in the Lua language bindings of Apache Thrift before 0.25.0 allows unauthenticated remote attackers to exhaust server resources by sending crafted Thrift messages that trigger uncontrolled allocation or inefficient algorithmic paths. The issue is limited to deployments that actively use the Lua bindings; other language bindings are unaffected. At time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified, and the impact is confined to availability-no data disclosure or code execution.
Denial of service in Apache Thrift Python bindings before 0.25.0 allows unauthenticated remote attackers to hang the service by sending crafted Thrift messages that drive the parser into an infinite loop (CWE-835). Exploitation is network-based but requires a specific condition, such as a particular protocol/transport or malformed message structure, to trigger the loop (AT:P / AC:H). The impact is limited to availability-no data disclosure or code execution-and only services exposing a Thrift endpoint that processes untrusted input using the Python bindings are affected; no public exploit code has been identified at time of analysis.
Denial of service in the Apache Thrift PHP bindings before version 0.25.0 allows unauthenticated remote attackers to exhaust server resources by sending crafted Thrift protocol messages that trigger inefficient algorithmic complexity (CWE-407). The vulnerability affects only applications that use the PHP bindings to deserialize untrusted Thrift input; other language bindings are unaffected. No public exploit code has been identified at the time of analysis, and the CVSS 4.0 AT:P metric indicates a specific attack precondition must be met, so exploitation is not guaranteed against every deployment.
Denial of service in the Dart language bindings of Apache Thrift before 0.25.0 allows unauthenticated remote attackers to exhaust server memory and CPU by sending crafted Thrift messages to a network-reachable Dart-based service that deserializes untrusted input (CWE-770, allocation of resources without limits or throttling). Impact is limited to availability (service slowdown or crash); there is no confidentiality or integrity consequence, and deployments using other Thrift language bindings such as C++, Java, Python or Go are not affected. No public exploit code was identified at time of analysis and the vendor-released fix that resolves the issue is Apache Thrift 0.25.0.
Denial of service in the Apache Thrift Node.js bindings (all versions before 0.25.0) lets remote, unauthenticated attackers crash the hosting Node.js process by delivering a crafted Thrift message that triggers an uncaught exception during deserialization. The vendor-supplied CVSS 4.0 score of 8.7 is driven entirely by availability impact (VA:H) with no confidentiality or integrity impact (VC:N/VI:N), and our independent assessment maps this to CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - no authentication, user interaction, or non-default configuration is required, so any deployment that parses untrusted Thrift input over the network is exposed. The practical risk is bounded by reachability: services that only accept trusted internal Thrift traffic are far less exposed. No public exploit code or confirmed active exploitation was identified at time of analysis. The description also cites improper validation of input quantities and prototype pollution, but the assessed impact per the vendor metrics remains availability-only.
Denial of service in Apache Thrift's Go bindings (versions before 0.25.0) lets unauthenticated remote attackers exhaust memory or CPU by sending highly compressed payloads over a compressed transport, so a tiny request expands into a disproportionately large in-memory buffer (CWE-409 data amplification / decompression bomb). Exploitation is conditional: per the vendor's CVSS 4.0 score the AT:P metric applies, meaning the affected service must actually accept attacker-supplied compressed data (for example a zlib-backed transport carrying untrusted input) - deployments of the Go bindings that do not parse compressed payloads from external sources are not exposed. Impact is availability-only (service crash, hang, or memory exhaustion) with no code execution or data disclosure; no public exploit code and no confirmed active exploitation were identified at time of analysis, and our independent assessment uses a 3.1 vector of AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflecting that precondition.
Denial of service in Apache Thrift's Python bindings before 0.25.0 arises from improper handling of highly compressed data (CWE-409), letting a remote, unauthenticated attacker send a small compressed Thrift payload that expands dramatically during parsing and exhausts server memory or CPU. Exploitation requires a service that accepts externally supplied Thrift data and decompresses or size-expands it, and the impact is confined to availability with no data disclosure or code execution. No public exploit code has been identified at time of analysis, and upgrading to 0.25.0 eliminates the vulnerability.
Denial of service in the D-language binding of Apache Thrift (thrift.server.nonblocking.TNonblockingServer) allows unauthenticated remote attackers to crash the server by sending a crafted or malformed message that provokes an uncaught exception and improper resource shutdown. Only deployments built with the D binding at versions before 0.25.0 and specifically using TNonblockingServer are affected, and the impact is limited to availability with no data exposure or modification. No public exploit code has been identified at time of analysis, and the vendor has released version 0.25.0 to fix the issue.
Unauthenticated remote attackers can crash applications that use the Apache Thrift PHP bindings prior to version 0.25.0 by supplying crafted Thrift protocol messages that trigger a NULL pointer dereference (CWE-476). The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) indicates the flaw is remotely reachable with low complexity and requires no authentication or user interaction, but the impact profile is availability-only (VC:N/VI:N/VA:H) - there is no confidentiality or integrity exposure, so the 8.7 score reflects a pure denial-of-service outcome rather than code execution. Exploitation is conditional on the target PHP service actually accepting and deserializing attacker-controlled Thrift input, and no public exploit code has been identified at time of analysis. A vendor patch is available in Apache Thrift 0.25.0, which per the advisory fixes the issue.
Denial of service in Apache Thrift deployments that use the D language bindings before version 0.25.0, where malformed input reaching the service endpoint triggers an uncaught exception, an infinite loop with an unreachable exit condition, and an integer underflow that can crash or hang the service. The assessed impact is availability-only (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor CVSS 4.0 base 8.7), meaning unauthenticated remote attackers who can reach a D-bindings Thrift service need no credentials, user interaction, or non-default configuration to cause disruption. Exposure is narrow because only services compiled against the D bindings are affected - Java, Python, C++, Go and other language binding deployments are not - and no public exploit code has been identified at time of analysis.