CVE-2026-94603 Sumo Logic CSE · Sumo

Detect Podman Sandbox Disabled via Malicious Image Annotation (CVE-2026-94603) in Sumo Logic CSE

Detects exploitation of CVE-2026-94603, a critical (CVSS 10.0, CWE-693 Protection Mechanism Failure) vulnerability in Podman where a crafted container image annotation can instruct `podman run` to disable nearly all sandboxing controls. Affected versions: Podman >= 4.4.0 < 5.8.8 and >= 6.0.0 < 6.1.3. A malicious image can embed annotations (e.g. run.oci.* / seccomp / apparmor / selinux keys) that cause Podman to drop seccomp profiles, AppArmor/SELinux confinement, capability bounding sets, and namespace isolation at container launch — yielding an effectively unconfined, near-host-privileged container. Detection focuses on Podman invocations pulling or running externally-sourced images followed by container processes exhibiting unconfined security context (no seccomp, unconfined AppArmor/SELinux, full capability sets, host namespace access).

MITRE ATT&CK

Tactic
Privilege Escalation Defense Evasion Execution

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=*linux* (podman)
| where _raw matches /podman\s+run/
| parse regex "podman\s+run\s+(?<podman_args>.*)" nodrop
| if(podman_args matches /(docker\.io|quay\.io|ghcr\.io|oci-archive|docker-archive|\.tar)/, 1, 0) as ext_image
| if(podman_args matches /(seccomp=unconfined|apparmor=unconfined|label=disable|--privileged|--cap-add=ALL|no-new-privileges=false)/, 1, 0) as unconfined
| where ext_image = 1 or unconfined = 1
| count by _sourceHost, podman_args, unconfined, ext_image
| sort by _count
critical severity medium confidence

Sumo Logic search detecting podman run of external images launched with sandboxing disabled, matching CVE-2026-94603 exploitation behavior.

Data Sources

Linux host logsauditd

Required Tables

_sourceCategory=linux

False Positives & Tuning

  • Privileged CI/CD container builds
  • Developer debugging with unconfined containers
  • Container image scanning tools

Other platforms for CVE-2026-94603

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) 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 1 Podman run external image with seccomp disabled

    Expected signal: ProcessRollup/DeviceProcessEvents record for podman with command line containing 'run', 'docker.io' and 'seccomp=unconfined'; child crun/conmon process launched.

  2. Test 2 Podman run privileged container from archive

    Expected signal: Process event for podman run referencing oci-archive and --privileged; container launched with full capability set.

  3. Test 3 Podman run with AppArmor and SELinux label disabled plus all capabilities

    Expected signal: Process event showing apparmor=unconfined, label=disable and --cap-add=ALL in the podman run command line with an external quay.io image.

Last updated: 2026-10-22 Research depth: standard
References (6)

Response Playbook

Triage

  1. Confirm the Podman version on the host: run `podman version` and compare against affected ranges (>= 4.4.0 < 5.8.8 and >= 6.0.0 < 6.1.3). If affected, treat any flagged run as high-priority until proven benign.
  2. Pull the full `podman run` command line and the source image reference from the alert. Determine whether the image came from an external/untrusted registry or an imported archive (oci-archive/docker-archive/.tar).
  3. Inspect the running or recently-run container's effective security context: `podman inspect <ctr> --format '{{.HostConfig.Privileged}} {{.AppArmorProfile}} {{json .HostConfig.SecurityOpt}} {{json .EffectiveCaps}}'` and confirm whether seccomp/AppArmor/SELinux were actually disabled versus explicitly requested by the operator.
  4. Extract and review the image's annotations: `podman inspect <image> --format '{{json .Annotations}}'` and `skopeo inspect` the manifest — look for annotations that reference seccomp, apparmor, selinux, capabilities, or OCI runtime options that would relax confinement.

Containment

  1. Immediately stop and remove any container launched from the suspect image: `podman stop <ctr> && podman rm -f <ctr>`, and remove the image `podman rmi -f <image>`.
  2. Isolate the host from the network if the unconfined container executed and host compromise is plausible, pending forensic review.
  3. Block the source registry/image reference at the egress proxy and quarantine the pulled image layers to prevent re-execution.

Evidence Collection

  1. Preserve the full image manifest and annotations (`skopeo copy docker://<image> oci:/evidence/<image>`) and the `podman inspect` output for both image and container before deletion.
  2. Collect auditd/journald records for the conmon/crun/runc process tree, the container's root filesystem diff (`podman diff <ctr>`), and any files written to host mounts.
  3. Capture the Podman store state and events log: `podman events --since <time>` and copy `~/.local/share/containers` or `/var/lib/containers` metadata for the affected container.

Escalation Criteria

  • !Escalate to incident response if the unconfined container executed processes that accessed host namespaces, host mounts, or made outbound C2-like connections.
  • !Escalate to platform/engineering owners if the affected Podman version is widespread across the fleet, since the fix requires upgrading to 5.8.8 or 6.1.3 across all hosts.
  • !Escalate if the malicious image was sourced from an internal registry, indicating possible supply-chain compromise of the image build pipeline.

Investigation Guide

Related Techniques

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

Forensic Artifacts

  • >Image annotations in the OCI manifest (JSON) referencing seccomp/apparmor/selinux/capabilities
  • >podman inspect security context (Privileged, SecurityOpt, AppArmorProfile, EffectiveCaps) for the container
  • >conmon/crun/runc process command lines and auditd syscall records showing missing seccomp filter
  • >podman events log and the container store metadata under /var/lib/containers or ~/.local/share/containers

Tuning Guidance

Baseline the hosts and users that legitimately run privileged or unconfined Podman containers (CI/CD runners, image scanners) and exclude those identities/hosts from alerting, or raise confidence only when the image originates from an untrusted external registry. Prioritize alerts where the effective security context was disabled WITHOUT a corresponding explicit operator flag (seccomp/apparmor dropped despite no --security-opt), since that discrepancy is the true signature of CVE-2026-94603 (annotation overriding defaults) rather than intentional operator action. Once hosts are patched to 5.8.8 / 6.1.3, downgrade severity for those hosts.

Hunting Queries

Hunts across 30 days for any Podman run invocation that launched a container with relaxed or disabled confinement, which could indicate annotation-driven sandbox disablement.

Hunting — KQL
kql 
DeviceProcessEvents | where Timestamp > ago(30d) | where FileName in~ ("podman","podman-remote") and ProcessCommandLine has "run" | where ProcessCommandLine has_any ("seccomp=unconfined","apparmor=unconfined","--privileged","label=disable","--cap-add=ALL") | summarize count() by DeviceName, AccountName, ProcessCommandLine
Hunting — SPL
spl 
index=linux (process_name=podman OR process="*podman run*") ("*seccomp=unconfined*" OR "*apparmor=unconfined*" OR "*--privileged*" OR "*label=disable*" OR "*--cap-add=ALL*") | stats count by host, user, process

Atomic Red Team Tests

Test 1 Podman run external image with seccomp disabled
linux

Simulates launching an externally-sourced image with seccomp confinement disabled, mirroring the unconfined outcome of CVE-2026-94603.

Command

bash 
podman run --rm --security-opt seccomp=unconfined docker.io/library/alpine:latest sh -c 'echo CVE-2026-94603-test; grep Seccomp /proc/self/status'

Cleanup

bash 
podman rmi -f docker.io/library/alpine:latest 2>/dev/null || true

Expected Telemetry

ProcessRollup/DeviceProcessEvents record for podman with command line containing 'run', 'docker.io' and 'seccomp=unconfined'; child crun/conmon process launched.

Expected Detection

KQL/SPL/EQL rules match on external image reference plus seccomp=unconfined in the podman run command line.

Test 2 Podman run privileged container from archive
linux

Imports and runs a local OCI archive with --privileged, exercising the full-capability, host-namespace unconfined path.

Command

bash 
podman save -o /tmp/test-img.tar docker.io/library/busybox:latest 2>/dev/null; podman run --rm --privileged oci-archive:/tmp/test-img.tar echo CVE-2026-94603-privileged-test

Cleanup

bash 
rm -f /tmp/test-img.tar; podman rmi -f docker.io/library/busybox:latest 2>/dev/null || true

Expected Telemetry

Process event for podman run referencing oci-archive and --privileged; container launched with full capability set.

Expected Detection

Detection rules fire on --privileged combined with an archive-sourced image.

Test 3 Podman run with AppArmor and SELinux label disabled plus all capabilities
linux

Launches a container with AppArmor set to unconfined, SELinux labeling disabled, and all capabilities added — the maximal sandbox-disabled state produced by the vulnerability.

Command

bash 
podman run --rm --security-opt apparmor=unconfined --security-opt label=disable --cap-add=ALL quay.io/podman/hello:latest /bin/sh -c 'echo CVE-2026-94603-unconfined'

Cleanup

bash 
podman rmi -f quay.io/podman/hello:latest 2>/dev/null || true

Expected Telemetry

Process event showing apparmor=unconfined, label=disable and --cap-add=ALL in the podman run command line with an external quay.io image.

Expected Detection

All seven SIEM rules match on the combination of external image and unconfined security options.

Related Detections

Tactic Hubs

TA0004 Privilege Escalation TA0005 Defense Evasion TA0002 Execution ATT&CK Matrix

Related Techniques

T1611 Escape to Host T1610 Deploy Container T1068 Exploitation for Privilege Escalation

Same Tactic: Privilege Escalation

Popular Detections