CVE-2026-48751 Elastic Security · Elastic

Detect CVE-2026-48751: Incus Restricted Project Bypass Leading to Arbitrary Command Execution in Elastic Security

Detects exploitation of CVE-2026-48751, a critical missing authorization vulnerability (CWE-862) in Incus (github.com/lxc/incus/v7/cmd/incusd) versions prior to 7.2.0. An attacker with access to a restricted Incus project can bypass project restrictions to execute arbitrary commands on the host system, achieving container escape with a CVSS score of 9.9. A public proof-of-concept is available.

MITRE ATT&CK

Tactic
Privilege Escalation Lateral Movement Execution

Elastic Detection Query

Elastic Security (Elastic)
eql 
sequence by host.name with maxspan=2m
  [process where event.type == "start"
   and process.parent.name in ("incusd", "incus")
   and process.name in ("sh", "bash", "zsh", "python3", "python", "perl", "ruby")]
  [process where event.type == "start"
   and process.args : ("nsenter", "unshare", "chroot", "pivot_root", "--target", "--mount", "--pid", "--net")
   and process.parent.name in ("sh", "bash", "zsh", "python3", "python", "perl", "ruby")]
critical severity medium confidence

EQL sequence rule detecting shell spawn from incusd followed by namespace manipulation commands within 2 minutes, indicating a container escape attempt via CVE-2026-48751.

Data Sources

Elastic EndpointAuditbeatFilebeat Linux Audit Module

Required Tables

logs-endpoint.events.process*auditbeat-*

False Positives & Tuning

  • Legitimate incus exec workflows that include namespace inspection for debugging
  • Security tooling that uses namespace inspection as part of container auditing
  • Automated build pipelines running inside Incus containers with exec-heavy workloads

Other platforms for CVE-2026-48751

Microsoft Sentinel (KQL) Splunk (SPL) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Incus Restricted Project Shell Escape via Exec API

    Expected signal: Process audit logs showing incusd spawning /bin/sh or nsenter with parent PID of incusd; auditd EXECVE records for nsenter or chroot with ppid matching incusd; /proc/<pid>/ns/pid symlink pointing to host PID namespace

  2. Test 2Verify Incus Vulnerable Version Present

    Expected signal: Process execution events for incusd --version and incus project list; API calls to /1.0/projects and /1.0/instances visible in incusd access logs

  3. Test 3Container Escape via Host Namespace Entry Post-Bypass

    Expected signal: Auditd SYSCALL records for nsenter (execve), unshare, clone syscalls; /proc/<pid>/ns/pid and /proc/<pid>/ns/mnt symlinks showing target namespace 1 (host init); process tree showing sh/bash with host-level PID namespace confirmed by NSpid field in /proc/self/status

Last updated: 2026-07-24 Research depth: standard
References (2)

Response Playbook

Triage

  1. Identify the source account and whether it belongs to an Incus restricted project user — check /etc/incus/auth/ or incus project list to enumerate project memberships and restrictions.
  2. Determine the Incus version on the affected host: run `incusd --version` or check package manager (dpkg -l incus or rpm -q incus). If < 7.2.0, treat as confirmed vulnerable.
  3. Review incusd logs at /var/log/incus/ or via journalctl -u incus for project boundary crossing events, unexpected API calls to /1.0/instances/<name>/exec from restricted project contexts.
  4. Check for indicators of successful host breakout: processes running outside container namespaces with PPID traceable to incusd, unexpected files created in /etc, /root, or /var by incus-descended processes.

Containment

  1. Immediately suspend or disable the affected Incus restricted project user's API token and revoke their certificates: `incus config trust remove <fingerprint>` and `incus project set <project> restricted=true` to re-enforce restrictions post-patch.
  2. If host compromise is confirmed, isolate the affected host from the network, snapshot all running containers for forensic preservation, and fail over workloads to unaffected nodes before upgrading Incus to >= 7.2.0.

Evidence Collection

  1. Collect incusd audit logs: `journalctl -u incus --since '2h ago' -o json > incus_audit.json` and preserve all files under /var/log/incus/ with timestamps.
  2. Capture process ancestry for suspicious processes: `ps auxf > process_tree.txt` and collect /proc/<pid>/status, /proc/<pid>/cmdline, and /proc/<pid>/ns/ symlinks for any incusd-descended processes executing outside expected container namespaces.

Escalation Criteria

  • !Escalate immediately to incident response if any process spawned from incusd is found running in host PID/network/mount namespaces (confirmed container escape), or if unauthorized files were written to sensitive host paths (/etc/passwd, /root/.ssh, cron directories).
  • !Escalate if the affected restricted project user has no legitimate business reason to be executing commands — this may indicate credential compromise or an insider threat leveraging the public PoC for CVE-2026-48751.

Investigation Guide

Related Techniques

[object Object][object Object][object Object]

Forensic Artifacts

  • >/var/log/incus/ — incusd API access logs containing project context and exec endpoint calls
  • >/proc/<pid>/ns/ — namespace symlinks revealing whether suspicious processes reside in host or container namespaces
  • >incusd Unix socket activity at /run/incus/unix.socket — client connections from restricted project contexts invoking exec API
  • >auditd records with SYSCALL type for execve, clone, unshare, pivot_root syscalls with uid/gid matching incusd service account

Tuning Guidance

Reduce false positives by filtering on known-good administrative accounts and scheduled maintenance windows. Create an allowlist of authorized incus exec command patterns used by your orchestration tooling. If incusd is not deployed in your environment, suppress this rule entirely. For environments using Incus >= 7.2.0 exclusively, archive this detection. Consider correlating with user identity — restrict alerting to restricted project members (not full admin users) to improve signal fidelity. Tune the namespace manipulation terms to your specific environment; not all nsenter/unshare usage is malicious if performed by expected automation accounts.

Hunting Queries

Hunt for namespace manipulation syscalls (unshare, pivot_root, clone with CLONE_NEWNS/CLONE_NEWPID) with incusd as the parent process, indicating container escape via CVE-2026-48751 restricted project bypass.

Hunting — KQL
kql 
DeviceProcessEvents
| where InitiatingProcessFileName == "incusd"
| where ProcessCommandLine has_any ("nsenter", "unshare", "pivot_root", "chroot")
| summarize count() by DeviceName, AccountName, ProcessCommandLine, bin(TimeGenerated, 1h)
| where count_ > 0
| order by TimeGenerated desc
Hunting — SPL
spl 
index=linux sourcetype=auditd syscall IN ("unshare", "pivot_root", "clone") ppid_process="incusd"
| stats count BY host, uid, syscall, exe, _time
| sort -_time

Atomic Red Team Tests

Test 1 Incus Restricted Project Shell Escape via Exec API
linux

Simulates CVE-2026-48751 by invoking the Incus exec API from a restricted project context to spawn an interactive shell, demonstrating the missing authorization check that allows command execution outside project restrictions.

Command

bash 
# LAB ONLY — requires Incus < 7.2.0 installed and a restricted project configured
# Step 1: Create restricted project
incus project create test-restricted
incus project set test-restricted restricted=true
incus project set test-restricted restricted.containers.nesting=false

# Step 2: As restricted project user, attempt exec bypass
INCUS_PROJECT=test-restricted incus exec <container-name> -- /bin/sh -c 'id && hostname && cat /proc/1/status | grep NSpid'

# Step 3: Attempt host namespace access
INCUS_PROJECT=test-restricted incus exec <container-name> -- nsenter --target 1 --mount --pid --net /bin/bash -c 'id'

Cleanup

bash 
incus project delete test-restricted --force
# Ensure incus is upgraded to >= 7.2.0 after testing

Expected Telemetry

Process audit logs showing incusd spawning /bin/sh or nsenter with parent PID of incusd; auditd EXECVE records for nsenter or chroot with ppid matching incusd; /proc/<pid>/ns/pid symlink pointing to host PID namespace

Expected Detection

Alert triggered on KQL DeviceProcessEvents or Splunk auditd sourcetype detecting incusd-descendant shell spawn followed by namespace manipulation command execution with risk score >= 80

Test 2 Verify Incus Vulnerable Version Present
linux

Checks whether the host is running a vulnerable version of incusd (< 7.2.0) and attempts to enumerate restricted projects, establishing reconnaissance baseline for CVE-2026-48751 exploitation.

Command

bash 
# Check incusd version
incusd --version || incus version

# Enumerate projects and their restrictions
incus project list --format=json | python3 -c "
import json, sys
projects = json.load(sys.stdin)
for p in projects:
    name = p.get('name', 'unknown')
    restricted = p.get('config', {}).get('restricted', 'false')
    print(f'Project: {name}, Restricted: {restricted}')
"

# List instances accessible from restricted context
incus list --format=json | python3 -c "import json,sys; [print(i['name'], i['status']) for i in json.load(sys.stdin)]"

Cleanup

bash 
No cleanup required — read-only enumeration

Expected Telemetry

Process execution events for incusd --version and incus project list; API calls to /1.0/projects and /1.0/instances visible in incusd access logs

Expected Detection

Low-confidence alert on incus enumeration commands; primary value is correlating version check with subsequent exploitation attempts in timeline analysis

Test 3 Container Escape via Host Namespace Entry Post-Bypass
linux

Simulates the post-bypass phase of CVE-2026-48751 exploitation where an attacker who has gained initial command execution uses nsenter to fully escape to the host PID namespace.

Command

bash 
# LAB ONLY — run inside a container where incusd exec bypass has been achieved
# Confirm container context
cat /proc/1/status | grep NSpid
ls -la /proc/1/ns/

# Attempt namespace escape to host
nsenter --target 1 --mount --pid --net --uts --ipc /bin/bash << 'EOF'
echo "[+] Host namespace achieved"
id
uname -a
hostname
cat /etc/os-release
ls /root/
EOF

# Alternative: attempt via unshare
unshare --user --map-root-user /bin/sh -c 'id'

Cleanup

bash 
Exit the spawned shell; no persistent changes. Ensure lab environment is reset and Incus upgraded to >= 7.2.0

Expected Telemetry

Auditd SYSCALL records for nsenter (execve), unshare, clone syscalls; /proc/<pid>/ns/pid and /proc/<pid>/ns/mnt symlinks showing target namespace 1 (host init); process tree showing sh/bash with host-level PID namespace confirmed by NSpid field in /proc/self/status

Expected Detection

High-confidence alert triggered by namespace manipulation sequence (nsenter targeting PID 1) originating from a process tree rooted at incusd; CrowdStrike and Elastic EQL sequence rules fire on NAMESPACE_ESCAPE category

Related Detections

Tactic Hubs

TA0004Privilege EscalationTA0008Lateral MovementTA0002Execution

Related Techniques

T1611Escape to HostT1548Abuse Elevation Control MechanismT1059Command and Scripting Interpreter

Same Tactic: Privilege Escalation

Popular Detections