CVE-2026-4748: FreeBSD Packet Filter DOS Vulnerability

CVE-2026-4748 Overview

CVE-2026-4748 is a firewall rule processing vulnerability in FreeBSD's pf (Packet Filter) firewall that causes certain rules to be silently dropped due to incorrect hash calculations. A regression in the hash calculation algorithm causes rules containing the address range syntax (x.x.x.x - y.y.y.y) that only differ in the address ranges involved to be incorrectly identified as duplicates. As a result, only the first of such rules is actually loaded into pf, while subsequent rules are silently discarded.

This vulnerability also affects some keywords representing actions taken on packet-matching rules, such as log, return ttl, or dnpipe. However, it is unlikely that users have configurations where these keywords differ between otherwise identical rules.

Critical Impact

Firewall rules may be silently ignored, leading to unexpected network behavior including over-blocking (legitimate traffic denied) or under-blocking (malicious traffic permitted), potentially exposing systems to unauthorized network access.

Affected Products

• FreeBSD 14.3 (all patch levels through p9)
• FreeBSD 14.4 (including rc1)
• FreeBSD 15.0 (all patch levels through p4)

Discovery Timeline

• 2026-04-01 - CVE CVE-2026-4748 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-4748

Vulnerability Analysis

The vulnerability stems from a regression in FreeBSD's pf firewall rule processing engine. When the system calculates hashes for firewall rules to identify duplicates, the algorithm fails to properly account for address ranges specified using the dash notation (x.x.x.x - y.y.y.y). This causes rules that are functionally different—allowing or blocking different IP ranges—to generate identical hash values.

When pf detects these "duplicate" hashes, it silently drops subsequent rules, loading only the first rule encountered. Network administrators may believe their complete ruleset is active when in reality critical rules have been discarded. This silent failure makes the vulnerability particularly dangerous, as there is no warning or error message to alert administrators.

Rules expressed using the CIDR notation (address/mask-bits) are not affected by this issue, as that syntax path correctly includes the network specification in the hash calculation.

Root Cause

The root cause is CWE-480 (Use of Incorrect Operator), where the hash calculation algorithm improperly processes or omits address range values when computing the rule hash. The regression likely introduced a code path that does not fully incorporate the address range boundaries into the hash computation, causing different ranges to produce colliding hash values.

Attack Vector

An attacker cannot directly exploit this vulnerability remotely to compromise a system. However, the vulnerability creates conditions where network security controls fail silently:

1. A system administrator configures multiple pf rules using address range syntax to control access from different IP ranges
2. Due to the hash collision, only the first rule is loaded
3. Subsequent rules that should block or allow different IP ranges are silently dropped
4. Network traffic that should have been filtered passes through unexamined, or legitimate traffic is incorrectly blocked

The attack vector is network-based as the resulting security gap allows unauthorized network access to systems that believed they were protected by the dropped firewall rules.

Detection Methods for CVE-2026-4748

Indicators of Compromise

• Unexpected network traffic patterns that should have been blocked by firewall rules
• Firewall rule counts not matching expected configuration when inspecting with pfctl -s rules
• Network services accessible from IP ranges that should be blocked according to pf configuration
• Log entries showing connections from IP addresses that should have been filtered

Detection Strategies

• Compare the number of rules in your pf.conf configuration file against the active rules reported by pfctl -s rules -v
• Review firewall logs for traffic from IP ranges that should be blocked by address-range-based rules
• Audit all pf rules using the address range syntax (x.x.x.x - y.y.y.y) for potential hash collisions
• Implement network traffic monitoring to detect unexpected access patterns

Monitoring Recommendations

• Enable comprehensive pf logging and regularly audit logs for anomalous traffic patterns
• Deploy network intrusion detection systems (IDS) to identify traffic that bypasses expected firewall rules
• Create automated scripts to periodically verify that active pf rules match the configured ruleset
• Monitor system logs for any pf-related warnings or errors during rule loading

How to Mitigate CVE-2026-4748

Immediate Actions Required

• Review all pf rules for address range syntax usage and convert to CIDR notation (address/mask-bits) where possible
• Verify active firewall rules match your intended configuration using pfctl -s rules -v
• Apply the security patch from FreeBSD as referenced in the FreeBSD Security Advisory
• Consider implementing additional network segmentation as a defense-in-depth measure

Patch Information

FreeBSD has released a security advisory addressing this vulnerability. Administrators should apply the patch referenced in FreeBSD-SA-26:09.pf.asc. The patch corrects the hash calculation algorithm to properly incorporate address range values, preventing the silent rule dropping behavior.

Workarounds

• Convert address range rules from dash notation (192.168.1.1 - 192.168.1.254) to CIDR notation (192.168.1.0/24) where mathematically equivalent
• Split complex address range rules into multiple rules using CIDR notation to cover the intended IP space
• Implement compensating controls such as additional firewall layers or network ACLs at switch/router level
• Manually verify all rules are loaded correctly after each pf configuration reload

# Configuration example - Converting address range to CIDR notation
# Before (vulnerable):
# pass in on egress from 10.0.0.1 - 10.0.0.254 to any
# pass in on egress from 10.0.1.1 - 10.0.1.254 to any

# After (safe - using CIDR notation):
pass in on egress from 10.0.0.0/24 to any
pass in on egress from 10.0.1.0/24 to any

# Verify rules are loaded correctly:
pfctl -s rules -v | wc -l