CVE-2026-62313

Executive Summary

CVE-2026-62313 is an access-control bypass vulnerability in Incus, a system container and virtual machine manager, affecting all versions prior to 7.3.0. The flaw resides in the project-level enforcement of the restricted.containers.privilege=isolated restriction, where an authenticated user can trivially circumvent tenant-isolation policies by omitting the security.idmap.isolated key when creating a container. Successful exploitation undermines the multi-tenant isolation guarantee, allowing co-tenant containers to share the host uid/gid map instead of receiving unique, non-overlapping ranges; the vulnerability is rated CVSS 4.3 (Medium).

Technical Analysis

The vulnerability is classified as CWE-863, an Incorrect Authorization flaw. At its core, the issue is a logic/validation gap in how Incus enforces the project-level restriction restricted.containers.privilege=isolated.

The infrastructure manager enforces isolation policies at the project level, allowing administrators to mandate that all containers within a specific project must use isolated idmaps. Isolated idmaps guarantee that each container receives a unique, non-overlapping range of host uid/gid mappings, which is a fundamental security boundary between co-tenant containers and the host.

The flaw exists in the validation logic that checks whether a container request complies with the project policy. Specifically, the enforcement mechanism only inspects the container configuration for an explicitly set security.idmap.isolated key with a value of false (or an empty value). When the key is present with either of those values, the restriction rejects the request.

However, the logic completely fails to validate the case where the key is omitted entirely from the container configuration. Because the underlying system defaults an unset security.idmap.isolated to false (meaning non-isolation), a user can simply leave the key out of the container creation request and obtain precisely the container state the restriction is designed to forbid.

The attack surface is the Incus REST API or command-line interface, accessible to any authenticated user with permission to create containers within a project that has this restriction enabled. No elevated privileges beyond standard container creation rights are required. The vulnerability is trivially exploitable, requiring no special techniques beyond omitting a configuration key.

The result is that containers created in a restricted project will share the host uid/gid map, meaning processes inside the container run with the same UID/GID values as host users, weakening the isolation boundary that exists between co-tenant containers and between the container and the host.

Exploitation Scenarios

Reconnaissance / Target Identification: An attacker must already be an authenticated user of the Incus instance with the ability to create containers in a project that has the restricted.containers.privilege=isolated restriction enabled. The attacker would first enumerate available projects (e.g., via incus project list) and inspect project configurations to identify which projects have this restriction applied.

Triggering the Vulnerability: The attack is initiated by submitting a container creation request to the Incus API (or CLI) for a container in the restricted project while deliberately omitting the security.idmap.isolated configuration key. Since the validation only rejects explicitly-set false (or empty) values, the request passes validation.

Payload / Execution Method: No payload is required. The attack is purely a configuration-level manipulation. The attacker issues a standard container creation request (incus init <image> <container> or its API equivalent) without specifying any idmap isolation settings. The server's default handling treats the omitted key as security.idmap.isolated=false.

Post-Exploitation Impact: The container is created with a shared host idmap, meaning it uses the host's native UID/GID namespace rather than a uniquely allocated range. This defeats the tenant-isolation guarantee. In a multi-tenant environment, a malicious tenant could potentially gain elevated access to other co-tenant containers or host resources depending on UID/GID collisions, file permissions, and the host's overall security posture. The shared idmap could permit low-privilege users on the host to interact with container processes and vice versa.

Note: No public PoC is available; this attack chain is inferred from the vulnerability class and NVD description. The exploitation is trivial, requiring no special tooling.

Impact Assessment

The CVSS score of 4.3 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L reflects a vulnerability that is network-exploitable, requires low attack complexity, and requires low privileges (authenticated user), but results in no confidentiality or integrity impact and only low availability impact. The low CVSS score undersells the real-world security severity, however, as the core impact is a broken authorization control that weakens the security boundary in multi-tenant deployments.

Business Impact: For enterprises running Incus as a multi-tenant container platform (e.g., hosting providers, DevSecOps environments, infrastructure teams), exploitation undermines the trust model. The ability to bypass tenant-isolation restrictions could lead to data leakage between tenants, privilege escalation attempts, and regulatory compliance issues (e.g., PCI-DSS multi-tenant isolation requirements). The blast radius is limited to projects configured with the restricted.containers.privilege=isolated policy, but any such project is fully exposed.

Affected Systems: All Incus versions prior to 7.3.0. The vulnerability is present in both CLI-driven and API-driven container creation flows, as both go through the same validation logic.

Detection Guidance

Sigma Rule

title: Incus Container Creation with Missing security.idmap.isolated Key
id: 6a5c8f31-2b4e-4b1a-9b2e-3c4d5e6f7a8b
status: experimental
description: Detects container creation requests in projects with restricted.containers.privilege=isolated that omit the security.idmap.isolated key, indicating possible CVE-2026-62313 exploitation
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-62313
author: Valtersit Threat Intel
date: 2026/06/10
logsource:
    product: incus
    service: api
detection:
    selection_project:
        project.config|contains: 'restricted.containers.privilege=isolated'
    selection_creation:
        event.type: 'container-created'
        container.config|has_key: 'security.idmap.isolated'
    filter_explicit_false:
        container.config.security.idmap.isolated|in:
            - 'false'
            - ''
    condition: selection_project and selection_creation and not filter_explicit_false
level: high
falsepositives:
    - Containers created by administrators with explicit override permissions
    - Legacy automation scripts that never set isolation keys
tags:
    - attack.t1190
    - cve.2026.62313
    - cwe.863

YARA Rule

rule CVE_2026_62313_Incus_Config_Missing_Idmap
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects Incus container configurations that omit security.idmap.isolated key in restricted projects"
        cve = "CVE-2026-62313"
        date = "2026-06-10"
        version = "1.0"
    strings:
        $idmap_key = "security.idmap.isolated"
        $restricted = "restricted.containers.privilege"
        $isolated_val = "isolated"
        $yaml = /^[a-z0-9_.-]+:\s*$/m
    condition:
        // Look for container config files in restricted projects
        ($restricted and $isolated_val) and
        // but the idmap key is not present
        not ($idmap_key)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-62313 - Incus Container Creation Missing security.idmap.isolated"; flow:established,to_server; content:"POST"; http_method; content:"/1.0/containers"; http_uri; content:"create"; http_uri; content:"security.idmap.isolated"; nocase; http_client_body; content:"false"; nocase; http_client_body; reference:cve,2026-62313; classtype:attempted-admin; sid:9000001; rev:1;)

Elastic Detection

// Elastic EQL query for Incus API logs
sequence by host.hostname with maxspan=5m
  [file where event.action == "creation" and
   process.name == "incusd" and
   message like "*restricted.containers.privilege*isolated*"]
  [any where event.action == "container-create" and
   not container.config.security.idmap.isolated == "false" and
   not container.config.security.idmap.isolated == ""]

Splunk SPL Query

index=incus* sourcetype=incus:api
| search "restricted.containers.privilege=isolated"
| search event_type="container_create"
| eval required_key=if(isnull(config_security_idmap_isolated), "missing", "present")
| search required_key="present"
| where config_security_idmap_isolated NOT IN ("false", "")
| table _time, user, project_name, container_name, config_security_idmap_isolated
| sort -_time

Wazuh OSSEC Rule

<group name="incus,">
  <rule id="100623" level="12">
    <decoded_as>incus</decoded_as>
    <field name="event_type">container_create</field>
    <field name="project_config">.*restricted\.containers\.privilege=isolated.*</field>
    <regex>security\.idmap\.isolated</regex>
    <description>Incus: container creation in isolated-restricted project without security.idmap.isolated key - possible CVE-2026-62313exploitation</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve-2026-62313,cwe_863,incus,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY) — 2 independent sources (Debian and project release) confirm the fix.

Immediate Mitigations:

1. Upgrade to Incus version 7.3.0 or later as soon as possible. This is the confirmed patched version.
2. If upgrading is not immediately possible, implement an API-level proxy or Webhook policy that inspects container creation requests and rejects any that omit the security.idmap.isolated key in projects with the restriction enabled.
3. Manually audit existing containers in restricted projects to identify any that were created without the isolation key — these containers may be operating with a shared host idmap.
4. Restrict container creation permissions to trusted administrators only until patching is completed.

Patch/Upgrade Steps:

1. Follow the official Incus upgrade procedures for your operating system (Debian packages are available).
2. Verify the upgrade by checking the version: incus version should return 7.3.0 or later.
3. Test container creation with and without the security.idmap.isolated key in a restricted test project to validate the fix.
4. Re-create or re-migrate any non-isolated containers detected in the audit step.

Long-Term Hardening:

1. Implement configuration management (e.g., Terraform, Ansible) to enforce standard container configuration templates that always include security parameters.
2. Deploy runtime policy enforcement tools (e.g., OPA/Gatekeeper) to validate container configurations at creation time.
3. Conduct periodic security audits of project restrictions and container idmap configurations.
4. Enable detailed audit logging for all container lifecycle events and monitor for unexpected configuration patterns.
5. Subscribe to Incus security announcements to receive timely vulnerability advisories.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-62313
2. Incus GitHub Repository (patch release): https://github.com/lxc/incus/releases/tag/7.3.0
3. Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2026-62313
4. CWE-863 Reference: https://cwe.mitre.org/data/definitions/863.html
5. ATT&CK T1190: https://attack.mitre.org/techniques/T1190/

Threat Actor Activity: No known threat actor campaigns or exploit-in-the-wild evidence at the time of analysis. The CISA KEV catalog does not list this CVE, and no public PoC or exploit code has been identified.