Debian DSA-6604-1: Incus Authorization Bypass and Privilege Escalation — Patching and Detection Guide

Debian has released security advisory DSA-6604-1 for Incus, the system container and virtual machine manager that serves as the community fork of LXD. According to the advisory, multiple security issues were discovered that could allow an attacker to:

• Bypass security and authorization restrictions enforced by the Incus daemon
• Gain unauthorized privileges on the host or within managed instances
• Cause denial of service against the container/VM management plane
• Disclose sensitive information that should be protected by Incus access controls

For the stable distribution (Debian 13 "trixie"), the issues are fixed in the updated Incus packages referenced in DSA-6604-1. Administrators running Incus on trixie — or tracking it as the virtualization layer for multi-tenant workloads, CI runners, or developer environments — should treat this as a priority patch.

Why Defenders Should Care

Incus sits at a privileged layer of the stack. The incusd daemon runs as root and brokers access to containers and VMs through a REST API exposed over a local Unix socket (/var/lib/incus/unix.socket) and, when configured, over TLS on TCP 8443. Membership in the local incus-admin group is effectively equivalent to root on the host, because a user who can talk to the daemon can launch a privileged container, mount the host filesystem into it, and read or write anything.

That architecture is precisely why an authorization bypass in Incus is so dangerous: it collapses the boundary between "user who can manage some containers" and "root on the host." In shared environments — build farms, hosting providers, labs, developer workstations with multiple local users — a flaw in the daemon's authorization checks is a direct privilege-escalation path. The advisory also flags denial of service and information disclosure, which matter for anyone exposing the Incus API remotely or running multi-tenant instances.

Key risk factors:

• Local attack surface: any local user able to reach the Incus socket or API could exploit weak authorization checks.
• Remote attack surface: servers with core.https_address set expose the API on the network; auth bypass here is far more severe.
• Multi-tenant environments: projects and restricted TLS certificates are used to delegate limited access; a bypass defeats that delegation model entirely.

Technical Analysis

Affected Products

Debian's advisory notes the problem has been fixed for the stable distribution (trixie). Pull the exact fixed version from the advisory page and the Debian security tracker, and confirm your installed package matches or exceeds it. Installations from source, the upstream Zabbly repository, or snaps are not covered by the Debian package fix and must be updated separately against upstream Incus releases.

How the Vulnerability Class Works (Defender's View)

While the advisory enumerates multiple issues rather than a single flaw, they cluster around the Incus daemon's security enforcement:

1. Authorization bypass: the daemon fails to correctly enforce access controls on API operations. A user with limited privileges (e.g., a restricted TLS client certificate scoped to one project, or a local user with partial access) could perform operations outside their authorized scope — such as manipulating instances, profiles, or storage they should not touch.
2. Unauthorized privilege gain: the natural escalation of an auth bypass in Incus. Because incusd executes operations as root, tricking it into performing actions on your behalf — launching a privileged instance, attaching host devices, editing security-sensitive config keys like security.privileged, raw.lxc, or disk device mounts of / — yields host-level compromise.
3. Denial of service: malformed or abusive API requests can crash or hang the daemon, taking down every container and VM it manages.
4. Information disclosure: responses or endpoints leak data (instance configs, secrets, certificates, host details) to users who should not see them.

Exploitation requirements: for the local vector, the attacker needs an account on the host with connectivity to the Incus socket (any member of the incus or incus-admin group, or a process that can reach the socket). For the remote vector, the attacker needs network reachability to the daemon's HTTPS listener. No user interaction is required in either case.

Exploitation Status

At the time of writing there is no confirmed in-the-wild exploitation reported in the advisory, and the flaws are not listed in CISA's Known Exploited Vulnerabilities catalog. That should not drive complacency: LXD/Incus authorization flaws have historically attracted rapid researcher attention, and the local-privilege-escalation path is straightforward once details are public. Patch before public write-ups or PoCs appear.

Detection & Response

The most reliable way to detect abuse of an Incus authorization flaw is to watch what the daemon does on behalf of users: new instances with privileged security flags, host path mounts, unexpected socket connections, and daemon restarts or crashes. The detections below focus on those high-signal behaviors rather than speculative indicators.

Sigma Rules

---
title: Incus Privileged Container or Host Mount Creation
id: 4c8e2f71-9b3a-4d5c-a1f6-7e2d9c4b8a01
status: experimental
description: Detects Incus CLI operations that launch instances with privileged security settings, host device mounts, or raw LXC configuration — a common end result of abusing authorization weaknesses in the Incus daemon to gain host-level privileges.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6604-1-incus
  - https://attack.mitre.org/techniques/T1610/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.privilege_escalation
  - attack.t1610
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_tool:
    Image|endswith:
      - '/incus'
      - '/lxc'
  selection_privileged:
    CommandLine|contains:
      - 'security.privileged=true'
      - 'security.privileged true'
      - 'raw.lxc'
      - 'source=/ '
      - 'source=/proc'
      - 'source=/sys'
      - 'source=/dev'
  condition: selection_tool and selection_privileged
falsepositives:
  - Legitimate administrative container launches by platform teams
level: high
---
title: Suspicious Process Executed by Incus Daemon
id: 8f2a6d14-3c7b-4e9a-b5d2-1f8c6a3e9042
status: experimental
description: Detects the Incus daemon (incusd) spawning shell interpreters or system modification utilities on the host. incusd normally manages instance lifecycle and should rarely execute interactive shells or package tools directly on the host context.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6604-1-incus
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.execution
  - attack.t1059.004
  - attack.privilege_escalation
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/incusd'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Rare: custom automation wrapping incusd; investigate any hit
level: high
---
title: Incus Administrative Group Membership Change
id: 2b7d3e58-6a1c-4f8d-9c4e-5b2a8d1f7063
status: experimental
description: Detects users being added to the incus or incus-admin groups. Membership in these groups grants effective root on the host via the Incus socket and is a direct privilege-escalation persistence mechanism after abusing daemon authorization flaws.
references:
  - https://linuxsecurity.com/advisories/debian/debian-dsa-6604-1-incus
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1078
logsource:
  category: process_creation
  product: linux
detection:
  selection_cmd:
    Image|endswith:
      - '/usermod'
      - '/gpasswd'
      - '/adduser'
      - '/useradd'
  selection_group:
    CommandLine|contains:
      - 'incus-admin'
      - ' incus'
      - '-G incus'
      - '-a incus'
  condition: selection_cmd and selection_group
falsepositives:
  - Onboarding of legitimate Incus administrators
level: medium

KQL — Microsoft Sentinel / Defender

If you ship Linux audit logs (Syslog, auditd, or a process-creation forwarder) into Sentinel, hunt for Incus abuse patterns centrally. The first query looks for privileged container creation and host mounts; the second correlates socket/API activity with group changes.

// Hunt: privileged Incus instance creation or host filesystem mounts
union Syslog, CommonSecurityLog
| where TimeGenerated > ago(7d)
| extend Msg = coalesce(SyslogMessage, Message)
| where Msg has_any ("incus launch", "incus init", "incus config", "lxc launch", "incus profile")
| where Msg has_any ("security.privileged", "raw.lxc", "source=/", "/dev/sd", "unix-char", "disk device")
| project TimeGenerated, Computer, HostName, ProcessName, Msg
| order by TimeGenerated desc;

// Hunt: local authentication/group changes touching incus groups (auth.log via Syslog)
Syslog
| where TimeGenerated > ago(7d)
| where Facility =~ "authpriv" or SyslogMessage has "group"
| where SyslogMessage has_any ("incus-admin", "incus")
| where SyslogMessage has_any ("usermod", "gpasswd", "adduser", "useradd")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL

Use this artifact across your Linux fleet to enumerate Incus presence, patch level, privileged instances, and who holds daemon access — everything you need to scope exposure in one sweep.

-- Scope Incus exposure: package version, daemon process, group members, socket listeners
SELECT * FROM foreach(
  row={
    SELECT Pid, Name, CommandLine, Username
    FROM pslist()
    WHERE Name =~ 'incusd' OR CommandLine =~ 'incusd'
  },
  query={
    SELECT Pid, Name, CommandLine, Username FROM scope()
})
UNION ALL
SELECT NULL AS Pid, 'group_member' AS Name,
       line AS CommandLine, NULL AS Username
FROM parse_lines(filename='/etc/group')
WHERE line =~ 'incus'
UNION ALL
SELECT LocalPort AS Pid, 'listener' AS Name,
       ProcessName AS CommandLine, NULL AS Username
FROM netstat()
WHERE LocalPort in (8443, 8444) OR ProcessName =~ 'incus'

Remediation / Verification Script (Bash)

Run this on Debian trixie hosts to confirm the vulnerable package, apply the DSA-6604-1 fix, and audit for the most common post-exploitation artifacts.

#!/bin/bash
# Incus DSA-6604-1 patch & audit script — run as root on Debian trixie

# 1. Show current Incus package versions
echo "=== Installed Incus packages ==="
dpkg -l | grep -E 'incus' || echo "Incus not installed via dpkg"

# 2. Apply security updates (DSA-6604-1)
echo "=== Applying updates ==="
apt-get update
apt-get install --only-upgrade -y incus incus-client incus-agent incus-base 2>/dev/null \
  || apt-get install --only-upgrade -y incus incus-client

# 3. Verify the daemon restarted with the new build
echo "=== Daemon status ==="
systemctl status incus --no-pager | head -n 5

# 4. Audit: who has daemon access?
echo "=== Members of incus / incus-admin groups ==="
getent group incus incus-admin

# 5. Audit: is the API exposed on the network?
echo "=== Remote API listener check ==="
ss -tlnp | grep -E '8443|8444' || echo "No remote Incus listener"

# 6. Audit: privileged instances (host root-equivalent)
echo "=== Privileged / host-mount instances ==="
for inst in $(incus list --format csv -c n 2>/dev/null); do
  priv=$(incus config get "$inst" security.privileged 2>/dev/null)
  [ "$priv" = "true" ] && echo "WARNING: $inst is privileged"
  incus config device show "$inst" 2>/dev/null | grep -B2 'source: /$' \
    && echo "WARNING: $inst mounts host root"
done

Remediation

1. Patch immediately. On Debian trixie, run apt-get update && apt-get upgrade (or the targeted --only-upgrade for the Incus packages) to pull the fixed version published under DSA-6604-1. Confirm the running daemon was restarted post-upgrade — a patched binary on disk does nothing while the old incusd process stays resident.
2. Cover non-Debian installs. If Incus was deployed from the Zabbly repository, from source, or via snap, update against upstream Incus releases separately. Check incusd --version and compare against the upstream security announcements.
3. Remove remote API exposure where not required. Run incus config unset core.https_address if remote management isn't needed. Where it is, enforce trusted TLS client certificates (incus config trust list) and restrict the listener to a management network.
4. Minimize group membership. Every member of incus-admin — and in most configurations incus — holds host-root-equivalent power. Prune both groups aggressively and treat membership changes as high-severity audit events.
5. Audit for privileged instances. Enumerate instances with security.privileged=true, raw.lxc overrides, or disk devices mounting host paths. Any of these found on an unpatched host warrants an incident review, not just a config fix.
6. Monitor going forward. Deploy the Sigma rules above to your Linux telemetry pipeline and alert on daemon crash loops, which may indicate active DoS attempts against unpatched hosts.

Official references:

• Debian Security Advisory DSA-6604-1: https://linuxsecurity.com/advisories/debian/debian-dsa-6604-1-incus
• Debian Security Tracker (search "incus"): https://security-tracker.debian.org/tracker/source-package/incus

Bottom Line

Container and VM managers are the control plane for everything running on the host, and Incus's design — a root daemon brokering API access — means an authorization bypass is not a container problem, it's a host problem. The DSA-6604-1 fix is available for trixie today. Patch, verify the daemon restarted, audit group membership and privileged instances, and put detection on the behaviors (privileged launches, host mounts, group changes) that follow exploitation rather than waiting for exploit-specific signatures.

Related Resources

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