Threat database

Apache NiFi 2.11.0 contains a missing authorization vulnerability in its REST API methods for migrating version-controlled Process Groups into Connectors. The vulnerability allows authenticated users with read or write access to a Connector to access or migrate Process Groups without proper authorization checks on those Process Groups. This can lead to unauthorized enumeration of Process Group details or migration of Process Groups without write access. The vulnerability is mitigated in Apache NiFi 2.12.0 by enforcing authorization checks on the source Process Groups during migration requests.

Apache NiFi Registry versions 0.4.0 through 2.11.0 have a path traversal vulnerability (CWE-22) in the handling of extension bundle content. Authenticated users authorized to write and delete bundles can upload crafted manifests that cause file operations outside the intended storage directory. This is due to insufficient validation of path components derived from group, artifact, and version coordinates. The vulnerability is fixed in version 2.12.0 by rejecting parent-directory coordinates and enforcing normalized paths within the storage root.

CVE-2026-76646 is a high-severity vulnerability in Apache MyFaces that allows a remote attacker to cause uncontrolled resource consumption by sending specially crafted request parameters. This can lead to a denial of service (DoS) condition. The issue affects multiple versions of Apache MyFaces, and fixed versions have been released. Users are advised to upgrade to the specified fixed versions to mitigate the risk.

CVE-2026-68536 is a critical Server-Side Request Forgery (SSRF) and Local File Inclusion vulnerability in Apache MyFaces Core. It affects multiple versions of Apache MyFaces, allowing an attacker to potentially cause confidentiality, integrity, and availability impacts. The vulnerability is fixed in versions 2.3.12, 2.3-next-M9, 3.0.4, 4.0.4, and 4.1.4. Users are strongly advised to upgrade to these versions to mitigate the risk.

CVE-2026-84439 is a log injection vulnerability in Apache ZooKeeper affecting versions 3.8.0 through 3.8.6 and 3.9.0 through 3.9.5. When audit logging is enabled, an unauthenticated attacker can inject arbitrary fields into the audit log by sending digest authentication requests with tab characters in the username. This allows the attacker to forge audit log entries, potentially misleading forensic analysis and incident response. The issue is fixed in versions 3.8.7 and 3.9.6.

Apache ZooKeeper versions 3.8.0 through 3.8.6 and 3.9.0 through 3.9.5 contain an authorization bypass vulnerability in the handling of the internal-only deleteContainer opcode. This flaw allows any client able to open a TCP connection to the ZooKeeper client port to delete empty persistent znodes without proper ACL checks or authentication. The issue is fixed in versions 3.8.7 and 3.9.6.

Apache ZooKeeper versions 3.8.0 through 3.8.6 and 3.9.0 through 3.9.5 have a vulnerability in quorum TLS where peer hostname verification is improperly enforced in FIPS-mode deployments. This allows a CA-trusted peer certificate with a Subject Alternative Name (SAN) that does not match the connected host to join quorum traffic, participate in leader election, and enter replication flows. The issue is fixed in versions 3.8.7 and 3.9.6.

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.

CVE-2026-59739 is a missing authorization vulnerability in Apache ZooKeeper that allows information disclosure of ACL-restricted paths. An attacker can register exists-watches on non-existent paths and then reconnect after those paths are created with restricted ACLs, thereby discovering the paths. The vulnerability arises from an incomplete fix for a previous issue, where ACL checks were not applied during the SetWatches reconnect replay handler. Although the data of the znode is not exposed, the path itself may contain sensitive information such as usernames or login IDs. The issue affects Apache ZooKeeper versions 3.8.0 through 3.8.6 and 3.9.0 through 3.9.5. Upgrading to versions 3.8.7 or 3.9.6 resolves the vulnerability.

CVE-2026-86466 is a high-severity vulnerability in the Apache Airflow FAB provider affecting versions prior to 3.9.0. The issue arises because the Authentik OAuth path in the FAB auth manager does not validate the issuer or audience claims of the id_token it accepts. This allows an attacker with a valid token for another application from the same Authentik identity provider to authenticate as any user in Airflow without proper authorization. The vulnerability is fixed in version 3.9.0.

CVE-2026-76187 is a critical improper authentication vulnerability in the Apache Airflow Keycloak provider. The unauthenticated token endpoint accepts client-credentials grants from any confidential client registered in the shared Keycloak realm, not just the client configured for Airflow. This allows an attacker with valid credentials for any client in the realm to authenticate as that client in Airflow and obtain a signed session token. The vulnerability affects deployments using the Keycloak auth manager with a shared realm among multiple confidential clients. Upgrading to apache-airflow-providers-keycloak version 0.10.0 or later mitigates this issue by restricting authentication to the configured client only.

Apache Airflow Keycloak provider versions before 0.10.0 have a security flaw where Keycloak access and refresh tokens are stored in separate unauthenticated cookies without validation against the signed Airflow session token. This allows an attacker with a valid Airflow login and a foreign Keycloak token to gain unauthorized privileges while maintaining their own session identity. The issue affects Airflow 3.3 or later deployments using the vulnerable Keycloak provider versions. Upgrading to apache-airflow-providers-keycloak 0.10.0 or later mitigates this vulnerability by binding tokens to the session identity.

CVE-2026-82310 is a vulnerability in the Apache Airflow FAB provider where deactivating a user account does not invalidate previously issued tokens. Although password authentication blocks disabled accounts, the Core API continues to accept existing unexpired tokens and allows them to mint replacements, enabling continued access with the original roles. This affects deployments using Airflow 3 with FAB auth manager and Core API token authentication. Upgrading to version 3.9.0 or later mitigates the issue by rejecting tokens for deactivated accounts.

Apache Airflow Apache Kafka provider versions 1.15.0 up to but not including 2.0.0 contain a vulnerability where externally controlled input in a Kafka connection's extra field is unsafely reflected and executed. This allows users with permission to edit Airflow connections to achieve arbitrary code execution in the scheduler process if Kafka event producers are enabled. The vulnerability is mitigated in version 2.0.0 and later by introducing an allowlist for connection-string callbacks. Deployments using Google Managed Kafka are not affected.

Apache Airflow FAB provider versions 3.2.0 through 3.8.x have a vulnerability where changing a user's password via the Admin user-edit PATCH endpoint does not invalidate existing database-backed sessions. This allows an attacker with a stolen session cookie to maintain access even after the password is changed. The issue affects deployments using the FAB auth manager with database-backed sessions and requires no attacker interaction with the password change endpoint. The vulnerability is fixed in version 3.9.0 and later.

CVE-2026-82311 is a critical vulnerability in the Apache Airflow FAB provider affecting deployments using the FAB auth manager with database-backed session storage. When a user's password is reset, existing sessions are not properly deleted due to a mismatch in identifier comparison, allowing an attacker with a stolen session cookie to maintain access even after the password change. This issue is fixed in version 3.9.0, which corrects the identifier comparison logic. The vulnerability has a CVSS score of 9.8, indicating high severity.

CVE-2026-86465 is an authorization bypass vulnerability in the Apache Airflow Akeyless provider affecting multi-team deployments using the Akeyless secrets backend. A Dag author scoped to one team can supply a specially crafted Variable key containing a path separator, causing the backend to resolve secrets belonging to a different team. Single-team deployments are not affected. The issue is fixed in version 0.3.1 of apache-airflow-providers-akeyless.

Description 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.

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.

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.