Slack Nebula CVE-2025-62820

Exploitation requires (1) the attacker to be an authenticated participant in the Nebula network holding a certificate signed by the deployment's CA (PR:L - this is not remote-unauthenticated), and (2) a vulnerable CIDR configuration where host certificates carry a subnet prefix (e.g. a /24 network or unsafe_networks entry) rather than a single-host address, causing the firewall to treat the whole subnet as the host's allowed source range. Limiting factors: the AC:H rating reflects that only 'some configurations' are affected (default/narrow host addressing is not), and the attacker must already possess a trusted Nebula certificate, so this is an in-mesh integrity/access-control issue rather than an external attack. Impact is confined to defeating source-IP-based firewall rules; there is no confidentiality exposure.

This is a moderate-severity (CVSS 4.9) firewall-bypass/spoofing flaw in Slack Nebula, not a high-priority emergency. All signals point to low real-world urgency: EPSS is 0.22% (11th percentile), the vulnerability is NOT in CISA KEV, and no public exploit code exists (the only GitHub evidence is the vendor fix PR #1493/#1494, not a POC). The CVSS vector itself tempers the risk - AV:N but AC:H and PR:L mean the attacker must already be a legitimate member of the Nebula overlay (holding a CA-signed certificate) AND the deployment must use a vulnerable CIDR configuration. The core defect (CWE-420): host certificates carrying subnet prefixes (e.g. 192.0.2.2/24) were inserted into the host's allowed-networks set at the full CIDR width, so the firewall accepted any source IP within that subnet rather than only the host's exact assigned address - enabling source-IP spoofing inside the mesh. The scope change (S:C) and I:L/A:L reflect that one compromised/malicious node can impersonate other IPs to defeat source-IP-based firewall rules on peers, but there is no confidentiality impact (C:N). One data conflict to note: the input Tag labels this 'Information Disclosure,' yet the CVSS vector sets C:N and rates only integrity/availability - the true impact is spoofing/access-control bypass, not disclosure. Overall: a real defect worth patching for Nebula operators relying on in-network firewall rules, but low likelihood of mass exploitation given the insider prerequisite and config dependency.

An attacker who already holds a valid Nebula certificate (a malicious insider or a compromised node) crafts packets using a spoofed source IP belonging to another host within the overlay's CIDR range. Because the firewall mistakenly accepts any address in the certificate's subnet, these spoofed packets bypass source-IP-based firewall rules and reach services that should have been restricted to specific peers. No public POC exists - only the vendor's fixing pull request and its spoofing-drop regression test are available.