<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T13:01:02.972839+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-55621</id>
    <title>CVE-2026-55621 — Incus has a project restriction bypass for custom volume copy across projects</title>
    <updated>2026-09-30T13:01:03.977214+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> lxc incus</p>
<p>Incus is a system container and virtual machine manager. Prior to version 7.2.0, missing authorization checks exist for custom volume copying where an attacker knowing the name of a project that they don't have access to and the name of a custom volume in that project can copy the custom volume to a new project. This issue could allow an attacker to access secrets in custom volumes they are not authorized to access. Version 7.2.0 patches the issue.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-55621"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-64f3-v33m-w89f</id>
    <title>GHSA-64f3-v33m-w89f — Incus has a project restriction bypass for custom volume copy across projects</title>
    <updated>2026-09-30T13:01:03.977358+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/lxc/incus/v7, Go: github.com/lxc/incus/v6, Go: github.com/lxc/incus</p>
<p>### Summary</p>
<p>Missing authorization checks exist for custom volume copying where an attacker who knows the name of a project that they don't have access to and the name of a custom volume in that project can copy the custom volume to a new project. This issue could allow an attacker to access secrets in custom volumes they are not authorized to access.</p>
<p>### Details</p>
<p>The storage volume creation handler authorizes creation in the target project, then passes `req.Source.Project` into the custom-volume copy path without checking that the caller can view the source volume. `req.Source.Project` is the attacker-controlled field. It is resolved to a storage volume project name and passed directly to `CreateCustomVolumeFromCopy`. No `allowPermission` or entitlement check (e.g. `CanView` on the source volume) is performed.</p>
<p>The copy must occur on the same server. However, once the copy has been done, nothing prevents a malicious actor from moving the volume to another server.</p>
<p>### PoC
#### Setup</p>
<p>Assume the target server is remotely accessible and a user/certificate has been added.</p>
<p>```
# create a new project and instance
incus project create secrets
incus profile show default | incus --project secrets edit default
incus --project secrets storage volume create default secret-vol</p>
<p># restrict an existing certificate to prevent access to the project
incus config trust edit cert-fp
#&gt; set, for example
restricted: true
projects:
  - default</p>
<p># verification, with the restricted certificate
i…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-64f3-v33m-w89f"/>
  </entry>
</feed>
