CVE-2024-6284

What it actually does

IP addresses supplied to the nftables library are encoded using incorrect byte order, producing nftables rulesets that apply the opposite allow/deny semantics than intended.

Why it matters to the business

Network filtering intended to protect assets may silently fail, permitting unwanted traffic or blocking legitimate traffic and creating operational or compliance exposure.

How an attack unfolds

An attacker sends traffic that the operator believed would be blocked by rules generated through the affected library version; because byte-order reversal inverts the match, the traffic is permitted instead.

How to fix it

Upgrade all Go modules that import github.com/google/nftables to version v0.2.0 or later and regenerate any previously generated nftables configuration.

How to confirm the fix worked

Confirm the Go module version is at least v0.2.0; regenerate a known test ruleset containing explicit IPv4/IPv6 matches and verify the resulting nftables dump contains the correct byte order.

Typical attack path

1. Operator uses github.com/google/nftables v0.1.0 to build and apply nftables rules containing IP address matches
2. Library emits rules with reversed byte order for the supplied addresses
3. nftables kernel engine therefore matches the inverted address set
4. Attacker traffic that should have been dropped is allowed (or vice versa)

How to detect it

Review build and deployment logs for references to github.com/google/nftables v0.1.0; inspect generated nftables output for IPv4/IPv6 address octets that appear byte-reversed relative to the intended values.

What your security team should do

• Immediately inventory all builds that depend on github.com/google/nftables and schedule upgrade to v0.2.0
• Re-apply nftables rules from the corrected library before the next change window
• Add a dependency-version check to CI pipelines that gate on nftables >= v0.2.0