Apache The Apache Software Foundation
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Apache product.
RSS Feeds for Apache security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Apache products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Apache Sorted by Most Security Vulnerabilities since 2018
Recent Apache Security Advisories
| Advisory | Title | Published |
|---|---|---|
| 2.4.68 | 13 Vulnerabilities Fixed in Apache HTTP Server 2.4.68 | June 8, 2026 |
| 2.4.67 | 11 Vulnerabilities Fixed in Apache HTTP Server 2.4.67 | May 4, 2026 |
| 2.4.66 | 5 Vulnerabilities Fixed in Apache HTTP Server 2.4.66 | December 4, 2025 |
| 2.4.65 | Vulnerability Fixed in Apache HTTP Server 2.4.65 | July 23, 2025 |
| 2.4.64 | 8 Vulnerabilities Fixed in Apache HTTP Server 2.4.64 | July 10, 2025 |
| 2.4.62 | 2 Vulnerabilities Fixed in Apache HTTP Server 2.4.62 | July 17, 2024 |
| 2.4.61 | Vulnerability Fixed in Apache HTTP Server 2.4.61 | July 16, 2024 |
| 2.4.60 | 8 Vulnerabilities Fixed in Apache HTTP Server 2.4.60 | July 15, 2024 |
| 2.4.59 | 3 Vulnerabilities Fixed in Apache HTTP Server 2.4.59 | April 4, 2024 |
| 2.4.58 | 4 Vulnerabilities Fixed in Apache HTTP Server 2.4.58 | October 19, 2023 |
Known Exploited Apache Vulnerabilities
The following Apache vulnerabilities have recently been marked by CISA as Known to be Exploited by threat actors.
| Title | Description | Added |
|---|---|---|
| Apache Tomcat Missing Encryption of Sensitive Data Vulnerability |
Apache Tomcat contains a missing encryption of sensitive data vulnerability that allows the bypass of the EncryptInterceptor. CVE-2026-34486 Exploit Probability: 42.6% |
August 4, 2026 |
| Apache ActiveMQ Improper Input Validation Vulnerability |
Apache ActiveMQ contains an improper input validation vulnerability that allows for code injection. CVE-2026-34197 Exploit Probability: 97.2% |
April 16, 2026 |
| Apache HTTP Server Improper Escaping of Output Vulnerability |
Apache HTTP Server contains an improper escaping of output vulnerability in mod_rewrite that allows an attacker to map URLs to filesystem locations that are permitted to be served by the server but are not intentionally/directly reachable by any URL, resulting in code execution or source code disclosure. CVE-2024-38475 Exploit Probability: 100.0% |
May 1, 2025 |
| Apache Tomcat Path Equivalence Vulnerability |
Apache Tomcat contains a path equivalence vulnerability that allows a remote attacker to execute code, disclose information, or inject malicious content via a partial PUT request. CVE-2025-24813 Exploit Probability: 99.9% |
April 1, 2025 |
| Apache OFBiz Forced Browsing Vulnerability |
Apache OFBiz contains a forced browsing vulnerability that allows a remote attacker to obtain unauthorized access. CVE-2024-45195 Exploit Probability: 100.0% |
February 4, 2025 |
| Apache HugeGraph-Server Improper Access Control Vulnerability |
Apache HugeGraph-Server contains an improper access control vulnerability that could allow a remote attacker to execute arbitrary code. CVE-2024-27348 Exploit Probability: 99.2% |
September 18, 2024 |
| Apache OFBiz Incorrect Authorization Vulnerability |
Apache OFBiz contains an incorrect authorization vulnerability that could allow remote code execution via a Groovy payload in the context of the OFBiz user process by an unauthenticated attacker. CVE-2024-38856 Exploit Probability: 99.4% |
August 27, 2024 |
| Apache OFBiz Path Traversal Vulnerability |
Apache OFBiz contains a path traversal vulnerability that could allow for remote code execution. CVE-2024-32113 Exploit Probability: 99.4% |
August 7, 2024 |
| Apache Flink Improper Access Control Vulnerability |
Apache Flink contains an improper access control vulnerability that allows an attacker to read any file on the local filesystem of the JobManager through its REST interface. CVE-2020-17519 Exploit Probability: 97.8% |
May 23, 2024 |
| Apache Superset Insecure Default Initialization of Resource Vulnerability |
Apache Superset contains an insecure default initialization of a resource vulnerability that allows an attacker to authenticate and access unauthorized resources on installations that have not altered the default configured SECRET_KEY according to installation instructions. CVE-2023-27524 Exploit Probability: 97.4% |
January 8, 2024 |
| Apache ActiveMQ Deserialization of Untrusted Data Vulnerability |
Apache ActiveMQ contains a deserialization of untrusted data vulnerability that may allow a remote attacker with network access to a broker to run shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class on the classpath. CVE-2023-46604 Exploit Probability: 99.7% |
November 2, 2023 |
| Apache RocketMQ Command Execution Vulnerability |
Several components of Apache RocketMQ, including NameServer, Broker, and Controller, are exposed to the extranet and lack permission verification. An attacker can exploit this vulnerability by using the update configuration function to execute commands as the system users that RocketMQ is running as or achieve the same effect by forging the RocketMQ protocol content. CVE-2023-33246 Exploit Probability: 96.6% |
September 6, 2023 |
| Apache Tomcat Remote Code Execution Vulnerability |
Apache Tomcat contains an unspecified vulnerability that allows for remote code execution if JmxRemoteLifecycleListener is used and an attacker can reach Java Management Extension (JMX) ports. This CVE exists because this listener wasn't updated for consistency with the Oracle patched issues for CVE-2016-3427 which affected credential types. CVE-2016-8735 Exploit Probability: 90.3% |
May 12, 2023 |
| Apache Log4j2 Deserialization of Untrusted Data Vulnerability |
Apache Log4j2 contains a deserialization of untrusted data vulnerability due to the incomplete fix of CVE-2021-44228, where the Thread Context Lookup Pattern is vulnerable to remote code execution in certain non-default configurations. CVE-2021-45046 Exploit Probability: 100.0% |
May 1, 2023 |
| Apache Spark Command Injection Vulnerability |
Apache Spark contains a command injection vulnerability via Spark User Interface (UI) when Access Control Lists (ACLs) are enabled. CVE-2022-33891 Exploit Probability: 93.1% |
March 7, 2023 |
| Apache APISIX Authentication Bypass Vulnerability |
Apache APISIX contains an authentication bypass vulnerability that allows for remote code execution. CVE-2022-24112 Exploit Probability: 96.0% |
August 25, 2022 |
| Apache CouchDB Insecure Default Initialization of Resource Vulnerability |
Apache CouchDB contains an insecure default initialization of resource vulnerability which can allow an attacker to escalate to administrative privileges. CVE-2022-24706 Exploit Probability: 92.5% |
August 25, 2022 |
| Apache Tomcat Remote Code Execution Vulnerability |
When running Apache Tomcat, it is possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. CVE-2017-12617 Exploit Probability: 100.0% |
March 25, 2022 |
| Apache Struts Improper Input Validation Vulnerability |
Apache Struts allows remote attackers to execute arbitrary Object-Graph Navigation Language (OGNL) expressions. CVE-2013-2251 Exploit Probability: 100.0% |
March 25, 2022 |
| Apache Tomcat on Windows Remote Code Execution Vulnerability |
When running Apache Tomcat on Windows with HTTP PUTs enabled, it is possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. CVE-2017-12615 Exploit Probability: 99.6% |
March 25, 2022 |
Of the known exploited vulnerabilities above, 19 are in the top 1%, or the 99th percentile of the EPSS exploit probability rankings. The vulnerability CVE-2026-34486: Apache Tomcat Missing Encryption of Sensitive Data Vulnerability is in the top 5% of the currently known exploitable vulnerabilities.
Top 10 Riskiest Apache Vulnerabilities
Based on the current exploit probability, these Apache vulnerabilities are on CISA's Known Exploited vulnerabilities list (KEV) and are ranked by the current EPSS exploit probability.
| Rank | CVE | EPSS | Vulnerability |
|---|---|---|---|
| 1 | CVE-2021-44228 | 100.0% | Apache Log4j2 Remote Code Execution Vulnerability |
| 2 | CVE-2017-5638 | 100.0% | Apache Struts Jakarta Multipart parser exception handling vulnerability |
| 3 | CVE-2021-40438 | 100.0% | Apache HTTP Server-Side Request Forgery (SSRF) |
| 4 | CVE-2013-2251 | 100.0% | Apache Struts Improper Input Validation Vulnerability |
| 5 | CVE-2021-41773 | 100.0% | Apache HTTP Server Path Traversal Vulnerability |
| 6 | CVE-2018-11776 | 100.0% | Apache Struts 2.3 to 2.3.34 and 2.5 to 2.5.16 Remote Code Execution Vulnerability |
| 7 | CVE-2017-12617 | 100.0% | Apache Tomcat Remote Code Execution Vulnerability |
| 8 | CVE-2024-45195 | 100.0% | Apache OFBiz Forced Browsing Vulnerability |
| 9 | CVE-2021-45046 | 100.0% | Apache Log4j2 Deserialization of Untrusted Data Vulnerability |
| 10 | CVE-2021-42013 | 100.0% | Apache HTTP Server 2.4.49 and 2.4.50 Path Traversal |
By the Year
In 2026 there have been 803 vulnerabilities in Apache with an average score of 7.4 out of ten. Last year, in 2025 Apache had 229 security vulnerabilities published. That is, 574 more vulnerabilities have already been reported in 2026 as compared to last year. However, the average CVE base score of the vulnerabilities in 2026 is greater by 0.15.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 803 | 7.44 |
| 2025 | 229 | 7.29 |
| 2024 | 275 | 7.45 |
| 2023 | 274 | 7.47 |
| 2022 | 228 | 7.63 |
| 2021 | 212 | 7.61 |
| 2020 | 160 | 7.56 |
| 2019 | 163 | 7.37 |
| 2018 | 155 | 7.24 |
It may take a day or so for new Apache vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Apache Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-75157 | Sep 18, 2026 |
Apache Airflow 3.3.1 Delete Endpoint RBAC Flaw (READ/EDIT mischeck)Apache Airflow's asset queued-events DELETE endpoints checked the caller's Dag-axis permission with `READ` instead of `EDIT`. Any authenticated user who could read a Dag could therefore delete that Dag's queued asset events, silently suppressing asset-triggered scheduling for it a state-changing action gated on a read-only permission. Deployments are affected whenever asset-triggered scheduling is in use and Dag read access is granted more widely than Dag edit access, which is the normal RBAC arrangement; no special configuration is required. Upgrade to apache-airflow 3.3.2 or later. |
AirFlow
|
| CVE-2026-92230 | Sep 17, 2026 |
Apache Karaf XML Utils ThreadLocal Metaspace LeakApache Karaf's XmlUtils cached XML parser/transformer factories in static ThreadLocal fields on long-lived container threads. Because a ThreadLocal value outlives the OSGi bundle that created it, repeated bundle or feature install, update, or refresh operations can leave successive bundle ClassLoader's pinned in memory and unreachable for garbage collection, leading to unbounded Metaspace growth and eventual denial of service of the Karaf instance. |
Karaf
|
| CVE-2026-70469 | Sep 16, 2026 |
Apache NiFi 2.11.0 disabled support for gzip-encoded HTTP requests for the application REST API and rejected requestsApache NiFi 2.11.0 disabled support for gzip-encoded HTTP requests for the application REST API and rejected requests that included the standard Content-Encoding header indicating gzip encoding. The framework enforcement filter did not check multiple instances of the Content-Encoding header and did not reject non-standard identifiers for gzip encoding, allowing a malicious client to send crafted requests that could consume excessive amounts of memory. Upgrading to Apache NiFi 2.12.0 is the recommended mitigation, which disables decompression of gzip-encoded HTTP requests regardless of header number or encoding identifiers. |
NiFi
|
| CVE-2026-81866 | Sep 16, 2026 |
Apache NiFi 2.9.0 through 2.11.0 provide Connector configuration update and verification REST API methodsApache NiFi 2.9.0 through 2.11.0 provide Connector configuration update and verification REST API methods that do not enforce authorization checking on Assets and Secrets referenced in proposed configuration. Updating or verifying a Connector configuration step can apply Asset and Secret references, but framework authorization was limited to write privileges on the Connector itself. As a result of the missing authorization, an authenticated user authorized to modify a Connector, but not authorized to read a referenced Parameter Provider, could apply Secret values backed by that Parameter Provider. The same methods also accepted Asset identifiers without verifying that the Asset belonged to the Connector being configured. Apache NiFi installations that do not implement different levels of authorization across Connectors and Parameter Providers are not subject to this vulnerability, because the framework enforces write permissions on the Connector as the security boundary. Upgrading to Apache NiFi 2.12.0 is the recommended mitigation, which authorizes read access to referenced Parameter Providers and verifies Connector ownership of referenced Assets during configuration update and verification. |
NiFi
|
| CVE-2026-82561 | Sep 16, 2026 |
Apache NiFi 1.5.0 through 2.11.0 provide REST API methodsApache NiFi 1.5.0 through 2.11.0 provide REST API methods that replace the entire contents of a Process Group using a client-supplied flow definition, covering Process Group flow replacement together with versioned flow update and rebase operations. Framework authorization for these methods was limited to read and write privileges on the Process Group itself, unlike the corresponding asynchronous update request methods, which also authorize the components encapsulated in the Process Group along with referenced Controller Services, Parameter Contexts, and Parameter Providers. As a result of the missing authorization, an authenticated user with write access to a Process Group could supply a flow definition that modifies or removes components in descendant Process Groups protected by more restrictive access policies, and could bind components to Controller Services and Parameter Contexts without authorization for those referenced components. Existing verification checks limited the impact to stopped components, and the issue applies only to deployments that use component-level authorization policies, because the framework enforces write permissions as the security boundary. Upgrading to Apache NiFi 2.12.0 is the recommended mitigation, which applies consistent reference resolution and component authorization across Process Group replacement and versioned flow update methods |
NiFi
|
| CVE-2026-86089 | Sep 16, 2026 |
Apache NiFi 2.11.0 supports migrating the contents of a version-controlled Process Group into a Connector using REST API methodsApache NiFi 2.11.0 supports migrating the contents of a version-controlled Process Group into a Connector using REST API methods that list eligible migration sources and submit migration requests. The framework authorized both methods against the target Connector alone, without evaluating access to the Process Groups involved. The absence of Process Group authorization allowed an authenticated user with read access to a Connector to enumerate the identifiers, names, and flow registry details of version-controlled Process Groups outside the scope of granted read policies. It also allowed a user with write access to a Connector to migrate a Process Group without write access to that Process Group, copying the flow definition, referenced assets, and component state into the Connector, and leaving the source Process Group disabled and renamed. Migration excludes sensitive property values and requires the source Process Group to be stopped with empty queues, which limits the scope of exposure. Apache NiFi installations that do not implement component-level authorization policies for Process Groups are not subject to this vulnerability, because the framework enforces Connector write permissions as the security boundary. Upgrading to Apache NiFi 2.12.0 is the recommended mitigation, which filters migration sources to Process Groups the requesting user is authorized to read, and requires write access to the source Process Group when submitting a migration request. |
NiFi
|
| CVE-2026-87976 | Sep 16, 2026 |
Apache NiFi Registry 0.4.0 through 2.11.0 are subject to path manipulation when storing extension bundle content using group, artifact, and version coordinatesApache NiFi Registry 0.4.0 through 2.11.0 are subject to path manipulation when storing extension bundle content using group, artifact, and version coordinates from uploaded NAR manifests. The default file persistence provider used coordinates as filesystem path components without rejected parent-directory names, and the path-containment check compared an unnormalized resolved path. An authenticated user authorized to write and delete bundles in a bucket can upload a NAR with a crafted manifest resulting in file system operations outside of the file persistence directory. Upgrading to Apache NiFi Registry 2.12.0 is the recommended mitigation, which rejects parent-directory coordinates and requires a normalized path to remain a strict child of the storage root location. |
NiFi
|
| CVE-2026-76646 | Sep 16, 2026 |
A remote attacker could cause excessive resource consumption by supplying specially crafted request parametersA remote attacker could cause excessive resource consumption by supplying specially crafted request parameters, potentially resulting in a denial of service condition. Older unsupported versions may also be affected. Users are recommended to upgrade to versions 2.3.12, 2.3-next-M9, 3.0.4, 4.0.4, or 4.1.4, which fix this issue. |
Myfaces
|
| CVE-2026-68536 | Sep 16, 2026 |
Server-Side Request Forgery / Local File Inclusion in Apache MyFace CoreServer-Side Request Forgery / Local File Inclusion in Apache MyFace Core. Older unsupported versions may also be affected. Users are recommended to upgrade to versions 2.3.12, 2.3-next-M9, 3.0.4, 4.0.4, or 4.1.4, which fix this issue. |
Myfaces
|
| CVE-2026-84501 | Sep 16, 2026 |
ZooKeeper Log Injection via add_auth (3.8.03.8.6, 3.9.03.9.5)An unauthenticated attacker can inject arbitrary fake log lines into Apache ZooKeeper's operational log by sending a crafted add_auth("ensemble", ...) request containing newline characters (\n). When the ensemble name doesn't match, EnsembleAuthenticationProvider.handleAuthentication() logs the raw, unsanitized name via LOG.warn(). Because SLF4J's {} placeholder preserves embedded newlines, the attacker can forge complete log entries with arbitrary timestamps, log levels, class names, and messages that are visually indistinguishable from genuine ZooKeeper log output. This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6. Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue. |
Zookeeper
|
| CVE-2026-84439 | Sep 16, 2026 |
Audit Log Injection in Apache ZooKeeper 3.8-3.9 via ACL Tab-SepsWhen audit logging is enabled (zookeeper.audit.enable=true), an unauthenticated attacker can inject arbitrary fields into Apache ZooKeeper's audit log by sending a digest authentication request with tab characters (\t) embedded in the username. Because the audit log uses tab-separated key=value format, the injected tabs are parsed as legitimate field separators, allowing the attacker to spoof audit results (e.g., injecting result=success), forge operation types, and corrupt forensic evidence. A log injection vulnerability in Apache ZooKeeper allows a client that can call setACL to inject forged key-value fields into zookeeper_audit.log. When audit logging is enabled, the server serializes attacker-controlled digest ACL ids into the acl= audit field without escaping tab characters. Because audit events are emitted as tab-separated key=value records, a crafted ACL id can make one successful setAcl event appear to contain forged fields such as operation=delete and znode=/forged. This undermines the integrity of downstream audit parsing, alerting, and incident response. This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6. Users are recommended to upgrade to version 3.9.6 or 3.8.7, which fixes the issue. |
Zookeeper
|
| CVE-2026-79993 | Sep 16, 2026 |
ZooKeeper 3.8-3.9.x deleteContainer ACL BypassThe `deleteContainer` opcode (0x14/20) is processed without verifying the caller's ACL permissions, allowing any authenticated client to delete specific znodes in the data tree regardless of the ACL restrictions on the znode or its parent. This opcode is considered internal-only and the official client doesn't have API for it, but a client that can open a plain TCP session on the ZooKeeper client port (2181 by default) - with NO authentication and NO ACL permissions - can delete any empty persistent znode (including regular persistent nodes, container nodes, and TTL nodes) by issuing the raw protocol OpCode deleteContainer (20). The deleteContainer request path completely skips both the session check and the DELETE ACL check that are enforced by the regular delete (OpCode 2) path. This is an authorization bypass / ACL enforcement bug. This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6. Users are recommended to upgrade to version 3.9.6 or 3.8.7, which fixes the issue. |
Zookeeper
|
| CVE-2026-59969 | Sep 16, 2026 |
Apache ZooKeeper TLS Peer Hostname Verification Bypass (before 3.8.7)Apache ZooKeeper quorum TLS fails to enforce peer hostname verification in FIPS-mode deployments. When sslQuorum=true, zookeeper.fips-mode=true, ssl.quorum.hostnameVerification=true, and ssl.quorum.clientHostnameVerification=true are enabled, the Java SSLSocket quorum path accepts a CA-trusted peer certificate whose SAN does not match the connected host. A malicious or misissued peer certificate can therefore join quorum traffic, participate in leader election, and enter replication flows. Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue. |
Zookeeper
|
| CVE-2026-59739 | Sep 16, 2026 |
Apache ZooKeeper <3.9.6/3.8.7 INFO Disclosure via SetWatches Replay (ACL bypass)Information disclosure via SetWatches reconnect replay in Apache ZooKeeper due to missing ACL check. An attacker can discover ACL-restricted paths by registering exists-watches on non-existent paths, then reconnecting after the paths are created with restricted ACLs. Issue is caused by incomplete fix for CVE-2024-23944 (ZOOKEEPER-4799). The fix added ACL checking to WatchManager.triggerWatch(). However, DataTree.setWatches() the SetWatches/SetWatches2 reconnect replay handler still calls watcher.process(event) with null ACL, bypassing the check entirely. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. Users are recommended to upgrade to version 3.9.6, 3.8.7 which fixes the issue. |
Zookeeper
|
| CVE-2026-86466 | Sep 16, 2026 |
Apache Airflow FAB Provider <3.9.0: ID Token Audience LeakApache Airflow FAB provider: the Authentik OAuth path in the FAB auth manager does not validate the issuer or audience claims of the id_token it accepts. An attacker holding a token that the same Authentik identity provider minted for a different client application can present it to Airflow and be authenticated as the user it names, because the audience claim is never checked. Affects deployments using the FAB auth manager with Authentik OAuth where the same Authentik instance also serves other applications; the attacker needs a valid token for any of those other applications, not for Airflow. CVE-2026-75156 corrected the same missing validation on the Azure AD path in this file; the Authentik path was left unchanged and is fixed here. Deployments that applied the CVE-2026-75156 fix and use Authentik must also upgrade for this one. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue. |
AirFlow
|
| CVE-2026-76187 | Sep 16, 2026 |
Apache Airflow Keycloak Provider Unauth Client-Cred Grant (Pre-0.10.0)Apache Airflow Keycloak provider: the unauthenticated token endpoint accepts a client-credentials grant for any confidential client registered in the Keycloak realm, not only the client configured for Airflow. No allowlist restricts which client ids may authenticate, so the credentials of an unrelated application that happens to share the realm are valid Airflow login credentials, and Airflow mints a signed session token for that application's service account. The endpoint also answers unauthenticated credential guesses against Keycloak under Airflow's identity. Affects deployments using the Keycloak auth manager whose realm is shared with other confidential clients. The attacker needs valid credentials for any one of those clients, not for Airflow. Resource authorization is still evaluated per subject, so the access gained is whatever that service account holds, plus any endpoint gated only on being authenticated. Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which accepts only the configured client on that grant. |
AirFlow
|
| CVE-2026-76186 | Sep 16, 2026 |
Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checksApache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checks that the two describe the same subject. A user who holds any valid Airflow login of their own, together with another subject's Keycloak access or refresh token obtained out of band, can pair the two: Airflow then authorizes requests with the foreign token's privileges while the session identity, audit log and cache keys continue to name the attacker's own account. The refresh path re-issues an Airflow session token for the original identity carrying the foreign tokens, so the mismatched pairing survives across sessions. Affects deployments running Airflow 3.3 or later with the Keycloak auth manager. Earlier versions carried the Keycloak tokens inside the signed session token, so the binding existed and was lost when they moved into separate cookies. Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which binds the cookie-supplied tokens to the session identity. |
AirFlow
|
| CVE-2026-82310 | Sep 16, 2026 |
Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivationApache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held. Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account. |
AirFlow
|
| CVE-2026-86792 | Sep 16, 2026 |
Apache Airflow Apache Kafka provider versions 1.15.0 before 2.0.0 resolve dotted-path strings found in a Kafka connection's `extra` field into Python callables via `import_string`, with noApache Airflow Apache Kafka provider versions 1.15.0 before 2.0.0 resolve dotted-path strings found in a Kafka connection's `extra` field into Python callables via `import_string`, with no allowlist, and hand them to the confluent-kafka client which invokes them. Deployments that have enabled the Kafka event producer `dag_run_events_enabled` or `task_instance_events_enabled`, both disabled by default build that client inside the scheduler process, so a user whose only privilege is editing Airflow connections gains arbitrary code execution in the control plane; the Airflow security model limits connection-configuration users to code execution on workers, not the scheduler. Deployments using Google Managed Kafka are not affected, because that code path overwrites any user-supplied `oauth_cb`; plain brokers and Amazon MSK are exposed. Users are recommended to upgrade to apache-airflow-providers-apache-kafka 2.0.0 or later, which adds an allowlist configuration option for connection-string callbacks. |
AirFlow
|
| CVE-2026-86462 | Sep 16, 2026 |
Apache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidateApache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker who already holds a copy of the victim's session cookie keeps full access as that user after the password change, so the password reset does not evict them. Affects deployments using the FAB auth manager with database-backed sessions; an administrator (or the user themselves) performing a routine password change is the trigger, and no attacker interaction with the endpoint is needed. This is a second, independent route to the outcome addressed by CVE-2026-82311, which corrected an identifier comparison in the session-invalidation helper. That fix does not repair this endpoint, because the PATCH path never calls the helper at all. Deployments that applied the CVE-2026-82311 fix must also upgrade for this one. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue. |
AirFlow
|
| CVE-2026-82311 | Sep 16, 2026 |
Apache Airflow FAB provider: resetting a user's password does not deleteApache Airflow FAB provider: resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour that it does. The cleanup compares the string identifier Flask-Login stores in the session against the user's integer database identifier, so the comparison never matches and no session is removed. An attacker who already holds a copy of the victim's session cookie keeps access as that user after the password change, so the reset does not evict them. Affects deployments using the FAB auth manager with `[fab] session_backend=database`. The trigger is an administrator (or the user) running the supported password-reset command as a containment action after a session cookie has been compromised; the secure-cookie backend is out of scope, as it documents that it cannot centrally delete sessions. apache-airflow-providers-fab 3.9.0 also fixes CVE-2026-86462, a second, independent route to the same outcome via the Admin user-edit endpoint; a single upgrade closes both. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which compares the identifiers consistently. |
AirFlow
|
| CVE-2026-86465 | Sep 16, 2026 |
Apache Airflow Akeyless provider: the Akeyless secrets backend's team-scope guard can be bypassed with a user-controlled keyApache Airflow Akeyless provider: the Akeyless secrets backend's team-scope guard can be bypassed with a user-controlled key. In a multi-team deployment, a Dag author scoped to one team can supply a Variable key containing a path separator that causes the backend to resolve a secret belonging to a different team, because the lookup path is concatenated from an unvalidated key after the team-scoped lookup misses. The Execution API Variables route accepts a path-shaped key, so this is reachable from ordinary Dag code. Affects multi-team deployments using the Akeyless secrets backend. Single-team deployments are not affected, as there is no cross-team boundary to cross. This is the same class as CVE-2026-68870, CVE-2026-68871 and CVE-2026-68872 in the Azure Key Vault, Yandex Lockbox and Amazon secrets backends. Users of apache-airflow-providers-akeyless are recommended to upgrade to version 0.3.1 or later, which fixes the issue. |
AirFlow
|
| CVE-2026-82427 | Sep 14, 2026 |
Apache Storm 3.1.0 Path Traversal via topology.blobstore.map SymlinkDescription A topology's `topology.blobstore.map` lets the submitter choose a local name for each blob that the supervisor localises. That name was used to build a path under the topology's working directory without normalisation, in both `AsyncLocalizer` and `Container.createBlobstoreLinks`, and the symlink helper force-deletes whatever already exists at the target before creating the link. A submitter could therefore use `../` segments to direct that delete-and-symlink operation at an arbitrary path, as the supervisor user, on every node the topology is scheduled onto. The consequences include recursive deletion of supervisor-owned content and planting a symlink that causes a subsequent worker launch to execute attacker-chosen code as another tenant's operating-system user, which defeats the isolation that `supervisor.run.worker.as.user` is intended to provide. Mitigation Upgrade to 3.1.0, where the resolved target must lie inside the expected root at both call sites. Users who cannot upgrade immediately should restrict topology submission to trusted principals, and may reject submissions whose `topology.blobstore.map` entries contain path separators or `..` segments before they reach Nimbus. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82428 | Sep 14, 2026 |
Apache Storm 3.1.0 Artifact Key Collision Vulnerability (CVE-2026-82428)Description Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from the Maven coordinate, for example `dep---.jar`. The key was therefore identical for every user of the cluster and predictable in advance. When the blob already existed, the uploader caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob's content or owner matched the artifact the submitter had resolved. A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter of the same coordinate would receive on the worker classpath, resulting in code execution inside another tenant's topology. This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used. Mitigation Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a pre-existing blob is no longer silently reused. Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology jar instead. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82429 | Sep 14, 2026 |
Apache Storm 3.1.0+ Worker-Launcher Setuid Path Traversal (lchown/chmod)Description The setuid-root `worker-launcher` binary adjusts ownership and permissions of worker directories by walking the tree with FTS and calling `lchown` and `chmod` on each entry's full pathname while running with an effective uid of 0. Both syscalls re-resolve the path at the time of the call, after FTS has classified the entry, and the trees being walked are owned and writable by the untrusted topology user. A tenant running code on a supervisor node could therefore replace an intermediate directory component with a symbolic link between classification and the privileged operation, redirecting the root-owned `lchown` or `chmod` at an arbitrary file on the host. The operation is repeatable at will, since crashing a worker forces a relaunch and blob updates re-run the walk, so a failed attempt costs the attacker nothing. This crosses the boundary that `supervisor.run.worker.as.user` and container isolation are intended to enforce. It is the same defect class as the Hadoop container-executor issues from which this code derives. Mitigation Upgrade to 3.1.0, where the privileged walk operates on file descriptors it has already stat'd rather than on pathnames re-resolved at call time. Users who cannot upgrade immediately should not run untrusted topology code on supervisors configured with `supervisor.run.worker.as.user`, since the launcher is the boundary being crossed. Note that the launcher must be rebuilt and reinstalled after upgrading; replacing the Java artifacts alone is not sufficient. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82430 | Sep 14, 2026 |
Apache Storm 3.1.0: Root Escalation via workerlauncher Docker/OCIDescription When launching a Docker or OCI worker, the setuid-root `worker-launcher` first changes ownership of the entire worker directory to the untrusted topology user, and only afterwards reads and acts on the command file that the supervisor wrote into that same directory. The file is opened without `O_NOFOLLOW` and without re-verifying its owner, so between the ownership change and the read the tenant can replace its contents. For the Docker path the parsed command is executed with real uid 0, and the command sanitiser is not a privilege boundary: it admits `-v` with an arbitrary source, `--device`, `--cap-add`, `--security-opt`, `--user` and `--net`, and copies positional arguments through verbatim. A rewritten file therefore yields an attacker-authored, root-equivalent container invocation with the host filesystem available. For the OCI path the same rewrite window applies, and mount validation is structural only, with no source or destination allow-list, so arbitrary host paths can be bind-mounted read-write into the container. The `username` field of the command file is likewise attacker-settable and is checked only against non-root and minimum-uid rules, permitting execution as another tenant's uid. Mitigation Upgrade to 3.1.0, where the command file is validated before the ownership change and re-verified on open, and where mount sources and destinations are constrained by configuration. Users who cannot upgrade immediately should disable Docker and OCI worker isolation, or restrict topology submission on affected supervisors to trusted principals. Note that the launcher must be rebuilt and reinstalled after upgrading. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82431 | Sep 14, 2026 |
Apache Storm <3.1.0 Nimbus ACL bypass via empty nimbus.usersDescription `SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty, before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving `nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`. `docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment following the documentation could believe it was restricted while it was not. The failure is silent; nothing in the logs or the configuration indicates that the group list is being ignored. Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged. Mitigation Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set. Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended principals, since a non-empty user list causes the group list to be evaluated on affected versions. Operators should review Nimbus access logs for operations by principals outside the intended groups. Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the configured groups will begin to be refused. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82433 | Sep 14, 2026 |
Apache Storm 3.1.0: Nimbus Config Disclosure via UI EndpointDescription `getNimbusConf` returned the complete daemon configuration without redaction after only a user-level authorization check. Where the cluster is configured with them, that response includes `storm.zookeeper.auth.payload` and the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is inconsistent rather than intended. The UI endpoint `/api/v1/cluster/configuration` compounded this. It carried no `@AuthNimbusOp` annotation, and the authorization filter treated a missing annotation as "no gate required" and returned immediately, so the endpoint applied no per-user check at all and proxied the request under the UI daemon's own principal. Any user able to pass `ui.filter` therefore received the full configuration, including principals that Nimbus itself would have refused. Mitigation Upgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where every UI API endpoint must declare its authorization explicitly. Users who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that restricts `/api/v1/cluster/configuration`, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through it. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82432 | Sep 14, 2026 |
Apache Storm Nimbus Blobstore Map Auth Bypass <3.1.0Description Nimbus validated `topology.blobstore.map` against the calling subject at submission time only. The rebalance operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the blob's contents into the topology's working directory. The same advisory covers `listBlobs`, which performed no authorization check and passed no subject, unlike the neighbouring `getBlobMeta` and `beginBlobDownload` operations. It therefore returned every key in the blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the above practical. On its own the disclosure is metadata only. Mitigation Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time configuration is, against the rebalancing caller, and where `listBlobs` applies the configured authorization. Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind that membership of a topology's `topology.users` or `topology.groups` confers them. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82434 | Sep 14, 2026 |
Apache Storm 3.0.x ZooKeeper Auth Payload Leak via Read-Only AccessDescription When ZooKeeper authentication is configured, Storm deliberately retains `storm.zookeeper.topology.auth.payload` in the topology configuration, because workers need it. Nimbus then served that configuration verbatim to any caller holding read-only topology permissions, so a user whose only grant was the ability to view a topology received its ZooKeeper credential. That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology concerned. It is not a write credential on assignments. The same advisory covers the submission client, which logged the generated payload at INFO on every submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore also reached any log aggregation or support bundle collected from the cluster. Mitigation Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no longer written to logs. Users who cannot upgrade immediately should rotate `storm.zookeeper.topology.auth.payload` for existing topologies, review retained logs and support bundles for the value, and restrict read-only topology permissions to trusted principals. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82435 | Sep 14, 2026 |
Description The worker's Netty message decoder is installed ahead of the SASL authentication handlers in the pipeline and acts on frames before any authentication has taken placeDescription The worker's Netty message decoder is installed ahead of the SASL authentication handlers in the pipeline and acts on frames before any authentication has taken place. It allocated buffers sized from a length field carried in the frame, so a single frame from an unauthenticated peer able to reach a worker slot port could drive a large allocation. `storm.messaging.netty.authentication` defaults to false, and the decoder runs before the handler that enforces it in any case, so no credentials are required. The attacker needs only TCP reachability to a worker port. The effect of a single frame at the default 768 MB worker heap has not been measured to distinguish sustained worker loss from transient garbage-collection pressure. The severity assigned to this advisory reflects the more conservative reading; consumers who require a precise figure should test against their own worker heap configuration. Mitigation Upgrade to 3.1.0, where frames are decoded only after the handshake completes. Users who cannot upgrade immediately should ensure that worker slot ports are reachable only from within the cluster, as the security model already recommends, and should enable `storm.messaging.netty.authentication` where the deployment permits it. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82437 | Sep 14, 2026 |
Description The Logviewer offers `logs.users` and `logs.groups` so operators can control who may read log contentDescription The Logviewer offers `logs.users` and `logs.groups` so operators can control who may read log content. For daemon logs those settings were not applied: the access decision combined the "this is a daemon log" flag with the authorizer result in a way that discarded the authorizer's answer whenever the flag was set, and the daemon log page and download endpoints reached the handler without consulting an authorizer at all. Any user able to pass the configured servlet filter could therefore read `nimbus.log`, `supervisor.log` and the other daemon logs on every reachable node, which contain other tenants' topology names, owners and configuration fragments. The same advisory covers the log listing endpoints, which accepted a user argument and never applied it, so `/listLogs` and `/searchLogs` returned every tenant's topology and worker log file names regardless of the caller. That part is metadata only. There was no configuration that closed either behaviour. Mitigation Upgrade to 3.1.0, where the daemon log paths evaluate the same configured user and group lists that the worker log paths already used, and the listing endpoints filter by the requesting user. Users who cannot upgrade immediately should place the Logviewer behind a reverse proxy that restricts the daemon log endpoints, and should treat daemon log content as readable by any filter-authenticated user. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82426 | Sep 14, 2026 |
Description Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checkingDescription Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checking that it referred to a file the caller had actually uploaded. The intended flow is that a client first calls `beginFileUpload`, which returns a path inside the Nimbus inbox, and uploads the jar in chunks to that location; nothing bound submission to that flow, and the `uploaders` map populated by `beginFileUpload` was never consulted at submit time. An authenticated user with topology submission rights could therefore submit any path readable by the Nimbus daemon user as their topology jar. Nimbus copied the file into the topology's jar blob, and the blob ACL grants the submitting subject read access, so the contents could then be retrieved with the ordinary blob download RPCs. Candidate targets include the Nimbus Kerberos keytab, Thrift and UI TLS private keys, and `storm.yaml` with the ZooKeeper authentication payload. Possession of the Nimbus keytab turns an ordinary tenant into a cluster administrator. In a deployment configured as the documentation recommends, submission is available to every authenticated principal when `nimbus.users` is unset, so no elevated privilege is required. Mitigation Upgrade to 3.1.0, where the submitted location is canonicalised and must resolve inside the Nimbus inbox. Users who cannot upgrade immediately should restrict topology submission to trusted principals via `nimbus.users` or `nimbus.groups`, and should treat any file readable by the Nimbus daemon user as potentially exposed to submitters: rotate the Nimbus keytab and any TLS private keys or ZooKeeper credentials reachable from that account. Local mode is unaffected. Credit Independently reported to the Apache Storm PMC by n0mi1k, with a proof of concept. Also found by the ASF using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82438 | Sep 14, 2026 |
Description Three separate mechanisms allowed a web page on an unrelated origin to read responsesDescription Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm's HTTP components served to an authenticated user. The Logviewer reflected the request's `Origin` header back in `Access-Control-Allow-Origin` while also sending `Access-Control-Allow-Credentials: true`. The published security model documents a permissive `Access-Control-Allow-Origin: *` posture as accepted, which is safe precisely because browsers refuse to honour `*` together with credentials; reflecting the concrete origin removes that protection. The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name where an initialisation parameter name was expected. The container ignored the setting and applied its own defaults, which allow credentials. Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET request. A script element on any origin can load such a response, which bypasses the same-origin policy entirely rather than negotiating it, and there was no way to turn the behaviour off. In each case the effect is that a page visited by an authenticated operator can read cluster, topology and log data on their behalf. Mitigation Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the CORS filter is configured explicitly, and JSONP wrapping is governed by `ui.enable.jsonp`, which defaults to false. Note that disabling JSONP is a behaviour change for tooling that passes a `callback` query parameter; such tooling should be moved to ordinary JSON requests. Users who cannot upgrade immediately should place the UI, Logviewer and DRPC HTTP endpoints behind a reverse proxy that strips `Access-Control-Allow-Origin` and `Access-Control-Allow-Credentials` from responses and rejects requests carrying a `callback` parameter. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82439 | Sep 14, 2026 |
Apache Storm DRPC Request-Queue Leak Fixed in 3.1.0Description The DRPC server kept a map from function name to request queue and created an entry the first time a function name was seen. No code path ever removed an entry: request cleanup removed the request from its queue, and the shutdown path drained queues, but the queue object and its map entry remained for the life of the process. Function names come from the client and are not constrained to functions any topology has registered, so the number of retained entries is bounded only by the number of distinct names an attacker chooses to send, and each retained entry holds the name itself. `drpc.authorizer` is unset by default, so no credentials are required to reach the endpoint. The retained state is permanent rather than a transient load spike, so the effect accumulates until the DRPC server exhausts its heap. Mitigation Upgrade to 3.1.0, where a function's queue is removed once nothing is waiting in it. Users who cannot upgrade immediately should configure `drpc.authorizer` so that only trusted principals can reach the DRPC endpoints, and should ensure the DRPC ports are not reachable from untrusted networks. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
|
| CVE-2026-82441 | Sep 14, 2026 |
Apache Storm Nimbus 3.1.0: Dependency Blobstore Validation FixDescription A submitted topology carries two lists of blobstore keys, `dependency_jars` and `dependency_artifacts`, which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their contents on the submission path, yet acts on them in two places. During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who listed a key belonging to another topology, such as its `-stormjar.jar`, could therefore cause that blob to be deleted when their own topology was cleaned up. Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions. Mitigation Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key and exists in the blobstore. Note that this validates new submissions only; a topology stored by an affected version with an invalid list is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them. Users who cannot upgrade immediately should restrict topology submission to trusted principals. Credit This issue was discovered by rzo1 while investigating an unrelated blobstore defect. |
|
| CVE-2026-84179 | Sep 14, 2026 |
Description getTopologyPageInfo merged the Nimbus daemon configuration with the topology's own configuration and returned the result without redaction in the topology_conf field of TopologyPageInfoDescription getTopologyPageInfo merged the Nimbus daemon configuration with the topology's own configuration and returned the result without redaction in the topology_conf field of TopologyPageInfo. The Storm UI copied that value verbatim into the configuration field of GET /api/v1/topology/{id} and of the corresponding metrics endpoint. Where the cluster is configured with them, the merged map includes storm.zookeeper.auth.payload, which Storm's own documentation directs operators to keep in storm-cluster-auth.yaml under permissions that deny access from workers, together with the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration, and any plugin key whose name denotes a secret. getTopologyPageInfo is a topology read-only operation. Under SimpleACLAuthorizer a principal listed in topology.readonly.users or topology.readonly.groups could therefore read daemon credentials that the dedicated cluster configuration API, getNimbusConf, redacts and that is gated on nimbus.users instead. The sibling operations that exist to serve configuration were masked; the topology page, which merges in strictly more daemon state, was not. Mitigation Upgrade to 3.1.0, where credential-bearing values are masked before any configuration is served over the Nimbus API. Users who cannot upgrade immediately should remove any principal that is not trusted with cluster credentials from topology.readonly.users, topology.readonly.groups, topology.users and topology.groups, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through the topology page. Credit Wanxin Yin (yaklang.io) reported this issue to the Apache Security Team. |
|
| CVE-2026-73191 | Sep 14, 2026 |
URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache SyncopeURL Redirection to Untrusted Site ('Open Redirect') vulnerability in Apache Syncope. When the Syncope SRA is configured for CAS authentication, the target Apereo CAS instance's URL is calculated by unconditionally looking at client-supplied forwarded HTTP headers. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73195 | Sep 14, 2026 |
Improper Encoding or Escaping of Output vulnerability in Apache SyncopeImproper Encoding or Escaping of Output vulnerability in Apache Syncope. Authenticated users can store a spreadsheet formula payload in one of their own plain attributes. When such users are included in a CSV export and the generated CSV file is opened by a spreadsheet application, the formula may be executed. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73236 | Sep 14, 2026 |
Incorrect Authorization vulnerability in Apache SyncopeIncorrect Authorization vulnerability in Apache Syncope. Delegated administration security checks are based on Realm hierarchy and enforced via prefix matches. Due to incorrect implementation, two sibling Realms whose names begin with the same string cannot be correctly distinguished, resulting in incorrect authorization. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73370 | Sep 14, 2026 |
Incorrect Authorization vulnerability in Apache SyncopeIncorrect Authorization vulnerability in Apache Syncope. Delegated administration security checks performed by Reconciliation service's pull and push, being incomplete, could accept calls by administrator not provided with adequate entitlements. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73178 | Sep 14, 2026 |
Apache Syncope < 4.0.8 / < 4.1.3: Sensitive Data Exposure via RESTExposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Syncope. An administrator with adequate entitlements can get access via REST to the list of existing Access Tokens, including their signed JWT body. These values can be then used to perform further REST requests, impersonating users with higher administration entitlements. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73470 | Sep 14, 2026 |
Apache Syncope PrivEsc via Delegation 3.0.x-4.1.xImproper Privilege Management vulnerability in Apache Syncope. Delegations can be created or updated with Roles not owned by the delegating User, or not for the same Realm subtree under the delegation management was granted for. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73579 | Sep 14, 2026 |
Apache Syncope Auth Bypass via Empty Realms Filter 3.0.0-M0 to 4.1.2Incorrect Authorization vulnerability in Apache Syncope. Any search requests are transformed into SQL, Neo4J or Elasticsearch / Opensearch queries, depending on the actual deployment configuration. An important component of such transformation is the Realms filter, which ensures that the search results are matching the requester's permissions. For non-recursive search requests it is possible that such Realms filter is rendered as empty, thus voiding any restriction on requester privileges. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-75015 | Sep 14, 2026 |
Apache Syncope 3.x,4.x Credential Leakage in Audit Events (CVE-2026-75015)Insufficiently Protected Credentials vulnerability in Apache Syncope. Audit events, when sent to the configured store, are not sufficiently masked for the sensitive values they might carry on their payloads, thus allowing administrators to access such sensitive values. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-75030 | Sep 14, 2026 |
Apache Syncope v4.0.7: Unchecked Authorization Enables Mass (De)ProvisionMissing Authorization vulnerability in Apache Syncope. An administrator with task execution entitlements might be able to mass (de)provision group members, regardless of their group-related administration capabilities. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-77051 | Sep 14, 2026 |
Apache Syncope 3.x/4.x SQLI via Untrusted entityKey/opEvent; fixed 4.0.8Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Syncope. An administrator with adequate entitlements can achieve execution of arbitrary SQL via stacked queries, leveraging unsanitized entityKey and opEvent parameters. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-73668 | Sep 14, 2026 |
Incorrect Auth in Apache Syncope 3.x-4.1 REST (CVE-2026-73668)Incorrect Authorization vulnerability in Apache Syncope. An administrator with adequate entitlements in a given Realm may be able to read via REST the full Connector configuration, confidential properties included, scoped in another Realm and thus be able to effectively duplicate such Connector instance into the Realm they have administration rights for. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-77147 | Sep 14, 2026 |
Apache Syncope 4.1.2 Code Injection via Groovy Security BypassImproper Control of Generation of Code ('Code Injection') vulnerability in Apache Syncope. An administrator with adequate entitlements for Implementations can create a malicious Groovy Command class containing untrusted code in their CommandArgs static implementation, bypassing the Groovy security sandbox. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|
| CVE-2026-77181 | Sep 14, 2026 |
Incorrect Authorization vulnerability in Apache SyncopeIncorrect Authorization vulnerability in Apache Syncope. An administrator with ClientApp's update entitlement is unable to perform the related operation, while ClientApp's create entitlement is checked both for create and update operations on ClientApp. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
Syncope
|