Back to Intelligence

ZDI-26-1007: Linux Kernel BPF Race Condition — Privilege Escalation Detection and Remediation Guide

SA
Security Arsenal Team
November 13, 2026
15 min read

The Zero Day Initiative has published advisory ZDI-26-1007, disclosing a race condition vulnerability in the Linux Kernel's BPF (Berkeley Packet Filter) local storage subsystem. Rated CVSS 7.5 (High), this flaw enables a local attacker — one who already has the ability to execute code on the target — to escalate privileges beyond their authorized level.

This is not a theoretical risk. Race conditions in the kernel's BPF subsystem have been a recurring source of high-impact privilege escalation vulnerabilities over the past several years. The BPF subsystem is increasingly critical to modern observability, networking, and security tooling — which means it's enabled on a massive percentage of production Linux systems. When a race condition exists in BPF local storage, the window between check and use can be manipulated to corrupt kernel memory or escalate privileges to root.

For SOC teams, CISOs, and infrastructure engineers running Linux at scale — whether on-premises, in cloud VMs, or in containerized environments — this advisory demands immediate attention. Patch, hunt, and harden.


Technical Analysis

Vulnerability Overview

AttributeDetail
Advisory IDZDI-26-1007
CVSS Score7.5 (High)
Vulnerability TypeRace Condition (CWE-362) — concurrent execution flaw in BPF local storage
Affected ComponentLinux Kernel — BPF (Berkeley Packet Filter) Local Storage subsystem
Attack VectorLocal
Attack ComplexityHigh (race condition — timing-dependent)
Privileges RequiredLow-to-High (attacker must already execute code on the target)
ImpactUnauthorized privilege escalation — potential root access
SourceZero Day Initiative — ZDI-26-1007

How the Vulnerability Works

BPF local storage provides per-object storage that BPF programs can attach to kernel structures such as sockets, inodes, and task structs. It is widely used by observability agents (e.g., Cilium, Falco, Datadog), security tooling, and networking functions.

A race condition (CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization) occurs when two or more kernel threads or execution contexts access shared BPF local storage data without adequate locking or synchronization primitives. In this specific flaw, the time-of-check to time-of-use (TOCTOU) gap in BPF local storage operations can be exploited by an attacker who carefully orchestrates concurrent BPF program invocations.

The exploitation chain typically follows this pattern:

  1. Initial Access: The attacker already has local code execution on the target system — either through a compromised service account, a web shell on an internet-facing application, a malicious container process, or a legitimate user account.
  2. BPF Program Loading: The attacker crafts or leverages a BPF program (or triggers an existing BPF hook) that interacts with BPF local storage maps.
  3. Race Trigger: By spawning multiple threads or processes that concurrently invoke BPF local storage operations, the attacker creates a timing window where kernel memory is accessed in an inconsistent state.
  4. Privilege Escalation: The corrupted or inconsistent kernel state is leveraged to overwrite credential structures, modify task capabilities, or escalate to root (UID 0).

Why This Matters for Your Environment

  • BPF is everywhere: Modern Linux distributions (Ubuntu 22.04+, RHEL 9+, Amazon Linux 2023, Debian 12+) ship with BPF enabled by default. Container runtimes, service meshes (Istio/Cilium), and observability stacks (Falco, Pixie, Datadog) all rely heavily on eBPF.
  • Local privilege escalation is a force multiplier: Attackers rarely land with root. They gain an initial foothold as a low-privileged user or through a compromised application, then escalate. This vulnerability bridges that gap.
  • Containers are not a boundary: If a container process escapes via a kernel-level BPF race condition, it gains root on the host — potentially compromising the entire node and every workload on it.

Exploitation Status

As of the ZDI publication date, this vulnerability has been assigned a CVSS 7.5 rating and disclosed through the Zero Day Initiative's coordinated disclosure process. There is no confirmed in-the-wild exploitation or public proof-of-concept code at the time of writing. However, given the public advisory and the nature of race condition vulnerabilities in BPF, a PoC is likely to emerge rapidly. Defenders should treat this as an urgent patching priority, not a theoretical exercise.

This advisory has not yet been added to the CISA Known Exploited Vulnerabilities (KEV) catalog, but security teams should monitor the CISA KEV catalog for updates.


Detection & Response

Sigma Rules

The following Sigma rules target the observable behaviors associated with exploitation of this vulnerability. Given the nature of the flaw — BPF program loading and subsequent privilege escalation — the most reliable detection signals are at the process execution and syscall level on Linux endpoints.

YAML
---
title: BPF Program Load by Non-System Process
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects loading of BPF programs by processes not typically associated with BPF operations, which may indicate exploitation of ZDI-26-1007 (BPF local storage race condition for privilege escalation).
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-1007/
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_bpf_syscall:
    CommandLine|contains:
      - 'bpf_prog_load'
      - 'BPF_PROG_LOAD'
      - 'bpf_map_create'
      - 'BPF_MAP_CREATE'
  selection_unexpected_parent:
    ParentImage|endswith:
      - '/python'
      - '/python3'
      - '/perl'
      - '/bash'
      - '/sh'
      - '/php'
      - '/ruby'
      - '/node'
  condition: selection_bpf_syscall and selection_unexpected_parent
falsepositives:
  - Legitimate BPF development or debugging by security engineers
  - eBPF-based monitoring agents (Cilium, Falco, Datadog) during initialization
level: high
---
title: Privilege Escalation via Unexpected UID Transition After BPF Activity
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: Detects processes that transition from non-root to root UID shortly after BPF-related syscalls are observed, consistent with race condition exploitation for privilege escalation (ZDI-26-1007).
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-1007/
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/id'
      - '/whoami'
      - '/cat'
      - '/bash'
      - '/sh'
      - '/python'
      - '/python3'
      - '/nc'
      - '/ncat'
    User: 'root'
  filter_known:
    ParentImage|endswith:
      - '/sshd'
      - '/sudo'
      - '/su'
      - '/systemd'
      - '/cron'
      - '/containerd'
      - '/dockerd'
  condition: selection and not filter_known
falsepositives:
  - System administrators performing legitimate root operations
  - Automated configuration management tools (Ansible, Puppet, Chef) executing as root
level: high
---
title: Suspicious Unprivileged BPF Access Attempt
id: c3d4e5f6-a7b8-9012-cdef-123456789012
status: experimental
description: Detects attempts to interact with BPF subsystem by unprivileged users, which may indicate reconnaissance or exploitation attempts targeting ZDI-26-1007.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-1007/
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.discovery
logsource:
  category: process_creation
  product: linux
detection:
  selection_bpf_tools:
    Image|endswith:
      - '/bpftool'
      - '/bpftrace'
      - '/bpfcc'
  selection_unprivileged:
    CommandLine|contains:
      - 'map dump'
      - 'map lookup'
      - 'prog show'
      - 'prog load'
      - 'map create'
  filter_admin:
    User|contains:
      - 'root'
      - 'admin'
  condition: selection_bpf_tools and selection_unprivileged and not filter_admin
falsepositives:
  - Security engineers performing legitimate BPF debugging
  - eBPF-based observability agents running under service accounts
level: medium

KQL — Microsoft Sentinel / Defender

For organizations ingesting Linux syslog and auditd data into Microsoft Sentinel (via CEF, Syslog, or AMA connectors), the following KQL queries hunt for indicators of BPF race condition exploitation and associated privilege escalation activity.

KQL — Microsoft Sentinel / Defender
// Hunt 1: Detect BPF-related syscalls from unexpected processes (ZDI-26-1007)
// Requires: Syslog or auditd ingestion into Sentinel
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("bpf_prog_load", "BPF_PROG_LOAD", "bpf_map_create", "BPF_MAP_CREATE", "bpf()")
| extend ProcessName = extract(@"([a-zA-Z0-9_\-\.]+)\[", 1, SyslogMessage)
| where ProcessName !in~ ("cilium-agent", "falco", "datadog-agent", "bpftrace", "bpftool", "systemd")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP
| order by TimeGenerated desc

// Hunt 2: Detect unexpected UID transitions to root — potential privilege escalation
// Looks for processes executing as root whose parent is not a known privilege escalation path
Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("uid=0", "euid=0")
| where SyslogMessage !has_any ("sudo", "su[", "sshd", "systemd", "cron", "containerd", "dockerd", "cloud-init")
| extend ProcessName = extract(@"([a-zA-Z0-9_\-\.]+)\[", 1, SyslogMessage)
| summarize EventCount = count(), DistinctMessages = make_set(SyslogMessage, 5) by Computer, ProcessName, bin(TimeGenerated, 1h)
| where EventCount > 0
| order by TimeGenerated desc

// Hunt 3: Detect bpftool/bpftrace execution by non-admin users
// Indicates reconnaissance or exploitation of BPF subsystem
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("bpftool", "bpftrace")
| where SyslogMessage !has "root"
| extend ProcessName = extract(@"([a-zA-Z0-9_\-\.]+)\[", 1, SyslogMessage)
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc

Velociraptor VQL

The following VQL artifact hunts across Linux endpoints for evidence of BPF exploitation — unexpected BPF program loads, suspicious process activity, and privilege escalation artifacts.

VQL — Velociraptor
-- Hunt: ZDI-26-1007 BPF Race Condition Exploitation Indicators
-- Identifies processes interacting with BPF subsystem and unexpected UID transitions

-- Part 1: Check for active BPF programs and their loading processes
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(bpftool|bpftrace|bpf_prog_load|bpf_map_create)'
   OR Exe =~ '(bpftool|bpftrace)'

-- Part 2: Identify processes running as root with suspicious parent processes
-- (potential post-exploitation activity after privilege escalation)
SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime,
       parent.Name AS ParentName,
       parent.CommandLine AS ParentCommandLine
FROM pslist()
WHERE Username =~ 'root'
  AND parent.Name !~ '(sshd|sudo|su|systemd|cron|containerd|dockerd|init|cloud-init|ansible|salt)'
  AND Name =~ '(bash|sh|python|perl|nc|ncat|id|whoami)'

-- Part 3: Check loaded BPF programs via /sys/fs/bpf and /proc
SELECT Name, Size, ModTime
FROM glob(globs='/sys/fs/bpf/*')

-- Part 4: Check for unusual capabilities on processes (CAP_BPF, CAP_SYS_ADMIN)
SELECT Pid, Name, CommandLine, Username,
       read_file(filename='/proc/' + str(string=Pid) + '/status') AS ProcStatus
FROM pslist()
WHERE Username !~ 'root'
  AND read_file(filename='/proc/' + str(string=Pid) + '/status') =~ 'CapEff.*(200|CAP_BPF)'

Remediation Script

The following Bash script performs verification, hardening, and interim mitigation for ZDI-26-1007 across Linux systems. It checks kernel version, verifies BPF configuration, applies interim mitigations, and confirms patch status.

Bash / Shell
#!/bin/bash
# ============================================================
# ZDI-26-1007 — Linux Kernel BPF Local Storage Race Condition
# Detection, Verification & Hardening Script
# Run as root on target systems
# ============================================================

set -euo pipefail

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

echo "============================================"
echo " ZDI-26-1007 BPF Race Condition Assessment"
echo " $(date)"
echo "============================================"

# --- 1. Check current kernel version ---
echo -e "\n[*] Current Kernel Version:"
KERNEL_VERSION=$(uname -r)
echo "    $KERNEL_VERSION"

# --- 2. Check if BPF is enabled ---
echo -e "\n[*] Checking BPF subsystem status..."
if [ -d /sys/fs/bpf ]; then
    echo -e "    ${YELLOW}BPF filesystem is mounted — BPF is active on this system${NC}"
    ls -la /sys/fs/bpf/ 2>/dev/null || echo "    (No pinned BPF objects found)"
else
    echo -e "    ${GREEN}BPF filesystem not mounted${NC}"
fi

# --- 3. Check unprivileged BPF setting ---
echo -e "\n[*] Checking unprivileged BPF access..."
UNPRIV_BPF=$(cat /proc/sys/kernel/unprivileged_bpf_disabled 2>/dev/null || echo "not_found")
if [ "$UNPRIV_BPF" = "0" ]; then
    echo -e "    ${RED}WARNING: Unprivileged BPF is ENABLED (unprivileged_bpf_disabled=0)${NC}"
    echo -e "    ${RED}This significantly increases the attack surface for ZDI-26-1007${NC}"
elif [ "$UNPRIV_BPF" = "1" ]; then
    echo -e "    ${GREEN}Unprivileged BPF is disabled (unprivileged_bpf_disabled=1)${NC}"
elif [ "$UNPRIV_BPF" = "2" ]; then
    echo -e "    ${GREEN}Unprivileged BPF disabled (admin-only, value=2)${NC}"
else
    echo -e "    ${YELLOW}unprivileged_bpf_disabled sysctl not found — check kernel config${NC}"
fi

# --- 4. Apply interim mitigation: Disable unprivileged BPF ---
echo -e "\n[*] Applying interim mitigation: Disabling unprivileged BPF..."
sysctl -w kernel.unprivileged_bpf_disabled=1 2>/dev/null && {
    echo -e "    ${GREEN}Set kernel.unprivileged_bpf_disabled=1 (runtime)${NC}"
} || echo -e "    ${YELLOW}Failed to set sysctl — may require kernel update${NC}"

# Persist across reboots
if [ -f /etc/sysctl.conf ] || [ -d /etc/sysctl.d ]; then
    echo 'kernel.unprivileged_bpf_disabled=1' > /etc/sysctl.d/99-bpf-hardening.conf
    echo -e "    ${GREEN}Persisted to /etc/sysctl.d/99-bpf-hardening.conf${NC}"
fi

# --- 5. Check BPF JIT hardening ---
echo -e "\n[*] Checking BPF JIT compiler hardening..."
BPF_JIT=$(cat /proc/sys/net/core/bpf_jit_enable 2>/dev/null || echo "not_found")
if [ "$BPF_JIT" = "1" ] || [ "$BPF_JIT" = "2" ]; then
    echo -e "    ${YELLOW}BPF JIT is enabled (value=$BPF_JIT) — consider hardening if not required${NC}"
else
    echo -e "    BPF JIT status: $BPF_JIT"
fi

# --- 6. List loaded BPF programs ---
echo -e "\n[*] Currently loaded BPF programs (requires bpftool):"
if command -v bpftool &>/dev/null; then
    bpftool prog show 2>/dev/null || echo "    No BPF programs loaded or insufficient permissions"
    echo ""
    echo "[*] BPF maps:"
    bpftool map show 2>/dev/null || echo "    No BPF maps found or insufficient permissions"
else
    echo "    bpftool not installed — install linux-tools or bpftool package for full BPF inventory"
fi

# --- 7. Check for suspicious processes with BPF capabilities ---
echo -e "\n[*] Checking for non-root processes with CAP_BPF or CAP_SYS_ADMIN..."
for pid in $(ls /proc/ | grep -E '^[0-9]+$'); do
    if [ -f "/proc/$pid/status" ]; then
        CAP_EFF=$(grep CapEff /proc/$pid/status 2>/dev/null | awk '{print $2}')
        UID_VAL=$(grep '^Uid:' /proc/$pid/status 2>/dev/null | awk '{print $2}')
        PROC_NAME=$(cat /proc/$pid/comm 2>/dev/null)
        # Check if non-root process has elevated capabilities
        if [ "$UID_VAL" != "0" ] && [ -n "$CAP_EFF" ] && [ "$CAP_EFF" != "0000000000000000" ]; then
            echo -e "    ${YELLOW}PID $pid ($PROC_NAME) UID=$UID_VAL CapEff=$CAP_EFF${NC}"
        fi
    fi
done
echo "    (Scan complete)"

# --- 8. Check for kernel updates ---
echo -e "\n[*] Checking for available kernel updates..."
if command -v apt-get &>/dev/null; then
    apt list --upgradable 2>/dev/null | grep -i linux-image || echo "    No kernel updates available via apt"
elif command -v yum &>/dev/null; then
    yum check-update kernel 2>/dev/null || echo "    No kernel updates available via yum"
elif command -v dnf &>/dev/null; then
    dnf check-update kernel 2>/dev/null || echo "    No kernel updates available via dnf"
else
    echo "    Package manager not detected — check manually"
fi

# --- 9. Summary ---
echo -e "\n============================================"
echo " ASSESSMENT COMPLETE"
echo "============================================"
echo ""
echo "Next Steps:"
echo "  1. Apply kernel patches from your distribution as soon as available"
echo "  2. Reboot to activate the patched kernel"
echo "  3. Verify unprivileged_bpf_disabled=1 persists after reboot"
echo "  4. Review BPF programs loaded on this host for anomalies"
echo "  5. Monitor ZDI advisory for CVE assignment and patch details:"
echo "     http://www.zerodayinitiative.com/advisories/ZDI-26-1007/"
echo ""

Remediation

Immediate Actions (Within 24 Hours)

  1. Disable unprivileged BPF access — This is the single most impactful interim mitigation. It prevents non-root users from loading BPF programs, which is a prerequisite for exploiting this vulnerability:
Bash / Shell
# Runtime mitigation (immediate)
sysctl -w kernel.unprivileged_bpf_disabled=1

# Persist across reboots
echo 'kernel.unprivileged_bpf_disabled=1' > /etc/sysctl.d/99-bpf-hardening.conf
sysctl --system
  1. Inventory BPF usage across your fleet — Identify which workloads legitimately require BPF (Cilium, Falco, Datadog, etc.) and ensure they run with appropriate privileges. Any workload that doesn't need BPF should not have access to it.

  2. Deploy the detection rules above — Push the Sigma rules to your Linux endpoints (via auditd, osquery, or your EDR), configure the Sentinel KQL queries as scheduled analytics rules, and run the Velociraptor VQL hunt across your fleet.

Patch Management (Within 72 Hours)

  1. Monitor your distribution's security advisory channels for the kernel patch corresponding to ZDI-26-1007. Track the following sources:

  2. Apply the kernel patch and reboot — A kernel patch requires a reboot to take effect. Plan maintenance windows accordingly, prioritizing:

    • Internet-facing Linux servers
    • Multi-tenant systems (shared hosting, container nodes)
    • Systems processing sensitive data (PCI-DSS, HIPAA, etc.)
    • Systems accessible by large numbers of local users
  3. For containerized environments: Patch the host kernel, not the container images. Container images share the host kernel — patching the host is the only effective remediation. Prioritize Kubernetes nodes and Docker hosts.

Longer-Term Hardening (Within 30 Days)

  1. Implement seccomp profiles for containers and applications to restrict the bpf() syscall to only processes that legitimately require it. Use Kubernetes securityContext.seccompProfile or Docker --security-opt seccomp to enforce this.

  2. Audit capabilities — Review all processes and containers running with CAP_BPF, CAP_SYS_ADMIN, or CAP_SYS_MODULE. These capabilities grant BPF access and should be tightly controlled:

Bash / Shell
# Find binaries with BPF-related capabilities
getcap -r / 2>/dev/null | grep -E '(cap_bpf|cap_sys_admin|cap_sys_module)'

# Audit Kubernetes pods with elevated capabilities
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.capabilities.add != null) | {namespace: .metadata.namespace, pod: .metadata.name, caps: .spec.containers[].securityContext.capabilities.add}'
  1. Enable kernel lockdown mode where supported (Secure Boot environments):
Bash / Shell
# Check lockdown status
cat /sys/kernel/security/lockdown

# Enable via kernel parameter (requires Secure Boot)
# Add to GRUB: lockdown=integrity
  1. Monitor CISA KEV — If this vulnerability is added to the CISA Known Exploited Vulnerabilities catalog, federal agencies will face a mandated remediation deadline. All organizations should treat KEV inclusion as a critical escalation trigger.

Key Takeaways

  • ZDI-26-1007 is a CVSS 7.5 race condition in the Linux Kernel's BPF local storage subsystem that enables local privilege escalation — one of the most dangerous vulnerability classes for post-exploitation.
  • The most effective interim mitigation is disabling unprivileged BPF (kernel.unprivileged_bpf_disabled=1), which removes the attack surface for non-root users.
  • Containers do not protect you — this is a kernel-level vulnerability. A container escape via BPF race condition gives the attacker root on the host.
  • Patch management for kernel vulnerabilities requires reboots — plan accordingly and prioritize multi-tenant and internet-facing systems.
  • Detection should focus on BPF syscall monitoring, unexpected UID transitions, and bpftool/bpftrace usage by non-admin accounts.

This vulnerability is a reminder that the Linux kernel's BPF subsystem — while transformative for observability and networking — remains a high-value attack surface. Defense-in-depth, rapid patching, and proactive hunting are your best controls.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.