Remote code execution inside the Apache Airflow scheduler is possible through the Apache Kafka provider (apache-airflow-providers-apache-kafka) 1.15.0 to before 2.0.0, which resolves dotted-path strings from a Kafka connection's extra field into Python callables via import_string with no allowlist and hands them to the confluent-kafka client. An authenticated user whose only privilege is editing Airflow connections can thereby execute arbitrary code in the control plane when the non-default Kafka event producer (dag_run_events_enabled or task_instance_events_enabled) is switched on, exceeding the Airflow security model that limits connection-configuration users to code execution on workers. No public exploit code or CISA KEV listing was identified at time of analysis; deployments using Google Managed Kafka are not affected because that code path overwrites any user-supplied oauth_cb, while plain brokers and Amazon MSK are exposed.
The Apache Airflow FAB provider (apache-airflow-providers-fab) before 3.9.0 fails to validate the issuer and audience claims of id_tokens presented to its Authentik OAuth login path, so any token that the same Authentik deployment minted for a different client application is accepted by Airflow and authenticates the attacker as the user named in that token. Only deployments running the FAB auth manager with Authentik OAuth against an Authentik instance that also serves other applications are affected — the attacker needs a valid token for one of those other apps, not for Airflow itself. This is a follow-up to CVE-2026-75156, which fixed the identical missing-validation flaw on the Azure AD path in the same file while leaving the Authentik path untouched; upgrade to 3.9.0 or later to remediate. No public exploit code or active-exploitation telemetry was provided in the source data.
Deactivated user accounts in the Apache Airflow FAB auth provider (apache-airflow-providers-fab 2.0.0 before 3.9.0) keep working through the Airflow 3 Core API: the password login path correctly rejects a disabled account, but any JWT access token issued before deactivation is still accepted and can be exchanged for a fresh token indefinitely. The result is that an administrative deactivation — typically performed as a containment action against a departing employee or compromised account — silently fails, leaving the account with its original role-scoped access to the Airflow control plane. No signature forgery or privilege escalation is involved; the holder simply replays their own still-valid credential. The issue is rated moderate by the project, with no CVSS vector, CWE, EPSS score, KEV entry, or public exploit code supplied in the available intelligence, and remediation is available in version 3.9.0.
Authentication bypass in the Apache Airflow Keycloak provider (apache-airflow-providers-keycloak) before 0.10.0 lets an attacker who holds valid client credentials for any unrelated confidential client in a shared Keycloak realm obtain a signed Airflow session JWT. Because the provider's token endpoint does not allowlist client ids, credentials that were never issued for Airflow are silently accepted as Airflow login credentials, and Airflow mints a session token for that third-party application's service account. Access is then limited only by what that service account can reach plus any endpoint gated solely on being authenticated, and the endpoint additionally permits unauthenticated credential guessing against Keycloak under Airflow's identity. No public exploit code or CISA KEV entry was identified at time of analysis; severity is rated moderate by the vendor, with the impact bounded by subject-level resource authorization.
Log forgery in Apache ZooKeeper 3.8.0–3.8.6 and 3.9.0–3.9.5 allows a remote client to inject arbitrary fake entries into the server's operational log by sending an add_auth("ensemble", ...) request whose ensemble name contains embedded newline characters. EnsembleAuthenticationProvider.handleAuthentication() writes the raw, unsanitized name through LOG.warn(), and because SLF4J's {} placeholder does not escape newlines, the attacker controls timestamp, level, class name and message text of the resulting lines. Apache rates the issue moderate and directs users to 3.8.7 or 3.9.6.
Let me synthesize the analysis for CVE-2026-79993. Key facts: - Apache ZooKeeper deleteContainer opcode (0x14/20) processed without ACL check. - Affected: 3.9.0-3.9.5, 3.8.0-3.8.6. - Fixed in 3.9.6 and 3.8.7. - Any client with plain TCP session on client port 2181, no auth, no ACL permissions, can delete any empty persistent znode (regular persistent, container, TTL nodes). - Skips session check and DELETE ACL check. - Authorization bypass / ACL enforcement bug (CWE-862 Missing Authorization presumably, or CWE-863 Incorrect Authorization). - No CVSS provided, no EPSS, no KEV, no POC. - Credit given. Let me construct fields. Product name: "Apache ZooKeeper" Summary: original synthesis. Start with impact verb + product. "Unauthorized deletion of znodes in Apache ZooKeeper 3.8.x and 3.9.x..." Technical context: ZooKeeper coordination kernel, znodes, ACLs, opcodes, container nodes, TTL nodes. CWE-862/CWE-863. The deleteContainer opcode is internal-only, used by servers to remove container nodes when they become empty. The regular DELETE path (opcode 2) enforces session check and ACL. deleteContainer path skips both. Note: description says "allowing any authenticated client" but then says "with NO authentication and NO ACL permissions". Conflicting. Actually the description contradicts itself: "allowing any authenticated client" vs "with NO authentication". Hmm. The plain TCP session means anyone with network access to port 2181 — no authentication needed. So PR:N effectively. But wait—can they delete any znode? The check is on empty persistent znodes. Actually the description says deleteContainer can delete "any empty persistent znode (including regular persistent nodes, container nodes, and TTL nodes)". So condition: znode must be empty (no children). Actually deleteContainer opcode normally deletes container nodes; here it can delete any empty persistent znode. So prerequisite: target znode must have zero children. CVSS assessment: AV:N, AC:L, PR:N (no auth n
Apache ZooKeeper quorum TLS peers running in FIPS mode can skip hostname verification, so a certificate whose SAN does not match the connected host is still accepted, letting a rogue peer join quorum traffic, participate in leader election, and enter replication flows. The flaw affects org.apache.zookeeper:zookeeper 3.8.0 through 3.8.6 and 3.9.0 through 3.9.5, but only in deployments where sslQuorum=true, zookeeper.fips-mode=true, and both ssl.quorum.hostnameVerification and ssl.quorum.clientHostnameVerification are enabled. Exploitation additionally requires the attacker to hold a certificate issued by a CA the cluster already trusts, making this a misissuance or CA-compromise scenario rather than a generic remote attack; no public exploit code or CISA KEV entry was identified at time of analysis, and fixes are released in 3.8.7 and 3.9.6.