CVE-2024-6640
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn ICMPv6 Neighbor Discovery (ND), the ID is always 0. When pf is configured to allow ND and block incoming Echo Requests, a crafted Echo Request packet after a Neighbor Solicitation (NS) can trigger an Echo Reply. The packet has to come from the same host as the NS and have a zero as identifier to match the state created by the Neighbor Discovery and allow replies to be generated. ICMPv6 packets with identifier value of zero bypass firewall rules written on the assumption that the incoming packets are going to create a state in the state table.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · moderate confidenceA vulnerability in pf firewall allows ICMPv6 packets with identifier value 0 to bypass stateful firewall rules. When pf is configured to allow Neighbor Discovery but block incoming Echo Requests, a crafted Echo Request packet with identifier 0 sent from the same host as a prior Neighbor Solicitation can match the ND-created state table entry and generate an Echo Reply, effectively bypassing intended firewall rules.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- Low
- Integrity
- Low
- Availability
- Low
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Verify pf firewall is enabled and loadedRun 'pfctl -si' to check pf status, or 'kldstat | grep pf' on FreeBSD to verify the pf kernel module is loaded. On OpenBSD, check 'pfctl -si' output.Affected if pf is not loaded or disabled - not vulnerable. If pf is loaded and running, proceed to next checks.
-
Review pf rules for ICMPv6 configurationExamine the active pf ruleset using 'pfctl -sr' and check for any rules involving 'icmp6' or 'icmp6-type' especially related to Neighbor Discovery (type 135/136) and Echo Request (type 128).Affected if Rules allow ND but block Echo Requests - potentially vulnerable configuration exists.
-
Identify specific vulnerable rule patternLook for rules that explicitly allow ICMPv6 neighbor solicitation/advertisement (types 135,136) while using 'block' or 'drop' on ICMPv6 echo-request (type 128) without specifying identifier filtering.Affected if A rule structure allowing ND states while blocking Echo Requests without identifier constraints is present.
-
Check for active ICMPv6 state entriesRun 'pfctl -ss | grep -i icmp6' to view existing ICMPv6 state table entries. Look for states created by neighbor solicitation that could be inappropriately matched by echo-request packets.Affected if Active ND-created states exist that could be matched by crafted echo-request packets with identifier 0.
-
Verify IPv6 is in use and traffic is being processedCheck for IPv6 interface configuration with 'ifconfig -a' and monitor ICMPv6 traffic with 'tcpdump -i <interface> icmp6' to confirm active IPv6 traffic processing.Affected if IPv6 is enabled and ICMPv6 traffic is being processed through pf - the bypass condition can be triggered.
A system is affected if it runs pf on FreeBSD or OpenBSD with IPv6 enabled, has pf rules that allow ICMPv6 Neighbor Discovery while blocking Echo Requests without explicit identifier filtering, and processes ICMPv6 traffic where crafted echo-request packets with identifier 0 could match ND-created state entries.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedApply vendor patches for pf/OpenBSD or FreeBSD to address improper ICMPv6 state handling, or implement explicit firewall rules to block ICMPv6 Echo Requests regardless of identifier value.
Latest FreeBSD stable release (check security.freebsd.org for the specific advisory FreeBSD-SA-24## containing CVE-2024-6640 fix)
- 1. Identify current FreeBSD version with: uname -r
- 2. Check FreeBSD security advisories (security.freebsd.org) for CVE-2024-6640 to confirm the fixed release version
- 3. Backup pf configuration: cp /etc/pf.conf /etc/pf.conf.backup
- 4. Update FreeBSD to the latest stable release or the specific version containing the fix using: freebsd-update fetch install or pkg upgrade
- 5. Alternatively, rebuild pf from source after applying the vendor patch if available in FreeBSD ports
- 6. After update, verify pf functionality: pfctl -f /etc/pf.conf && pfctl -sr
- 7. Test that ICMPv6 packets with identifier 0 are now properly handled by firewall rules
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation3.0 h
- Implementation12.0 h
- Testing6.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $6,720.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2024-6640 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2024-6640 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data