GHSA-39g5-644c-qwcg: container Pf Rule Injection Vulnerability
LOWGHSA-39g5-644c-qwcg is a LOW pf rule injection vulnerability (CWE-20: Improper Input Validation) affecting container libraries in the SwiftURL ecosystem. The issue involves pf rule injection via domain name argument in `container system dns create --localhost` command. Remediation is available by upgrading affected packages to version 0.12.3.
GHSA-39g5-644c-qwcg at a Glance
How to Fix GHSA-39g5-644c-qwcg
To remediate this vulnerability, upgrade all affected container dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade github.com/apple/container to 0.12.3
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for github.com/apple/container
How to Check if You Are Affected
To determine whether your application is affected by GHSA-39g5-644c-qwcg, inspect your project dependencies for container:
inspect dependencies for github.com/apple/container
Analyze the terminal output to locate any version of container in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.12.3), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-20: Improper Input Validation, where the product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. In container, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
GHSA-39g5-644c-qwcg Affected container Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
github.com/apple/container
|
SwiftURL |
< 0.12.3
|
0.12.3
|
References
Frequently Asked Questions
What is GHSA-39g5-644c-qwcg?
Which container versions are affected?
What version fixes GHSA-39g5-644c-qwcg?
Is github.com/apple/container affected?
What CWE is associated with GHSA-39g5-644c-qwcg?
How can I check SwiftURL dependencies for GHSA-39g5-644c-qwcg?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-39g5-644c-qwcg",
"modified" : "2026-05-07T01:43:31Z",
"published" : "2026-05-07T01:43:31Z",
"aliases" : [ ],
"summary" : "container: pf Rule Injection via Domain Name Argument in `container system dns create --localhost` Command",
"details" : "#### Product\n\nName: container\n\nGithub Link: https://github.com/apple/container\n\nVersion: <= 0.12.2\n\n\n\n#### Summary\n\nThe `container system dns create --localhost` command accepts a `domainName` argument and passes it unsanitized into the pf anchor file (`/etc/pf.anchors/com.apple.container`) as a comment in a rule line. A domain name containing a newline character breaks out of the comment context and injects an arbitrary pf rule into the anchor file. When `pfctl -f` subsequently loads the configuration, the attacker-controlled rule is loaded into the macOS kernel packet filter.\n\nA `isValidDomainName()` function exists in `Parser.swift:892` but is **never called** from `DNSCreate`.\n\n**The core harm caused by this vulnerability is the bypassing of sudo privileges. An administrator may have only granted a user or an automation tool such as CI/CD the ability to execute `container system dns create` with root privileges, expecting that the user or automation tool could only add redirects from other IPs to localhost in the firewall rules file via `--localhost`. However, an attacker can exploit this vulnerability to write arbitrary rules into the firewall rules file: the target address is no longer restricted to localhost, and the rules are no longer limited to redirects.**\n\n#### Impact\n\n**What a legitimate invocation can write**\n\n`--localhost` is an optional parameter. Its presence or absence determines whether any pf rule is written at all:\n\n- **Without `--localhost`**: only a resolver config file is written; no pf rule is produced.\n- **With `--localhost <IP>`**: exactly one rule is written to the pf anchor file:\n\n```\nrdr inet from any to <IP> -> 127.0.0.1 # <domain>\n```\n\nThe redirect destination is hard-coded to `127.0.0.1`. The rule type is always `rdr inet`. There is no legitimate way to produce a rule that redirects traffic to any IP other than `127.0.0.1`, nor to produce `pass`, `block`, or `nat` rules, through normal command usage.\n\n**What injection additionally enables**\n\nThe injection lives in the domain name argument. `--localhost` must be supplied to trigger the `createRedirectRule()` code path — without it, no pf rule is written at all and the domain name never reaches the pf anchor file. However, the value passed to `--localhost` is unconstrained (only IP format is validated), so any valid IP suffices to open the injection path.\n\n```bash\nsudo container system dns create --localhost 127.0.0.1 \\\n $'foo.local\\nrdr inet from any to 1.2.3.4 -> 5.6.7.8'\n```\n\nThe `--localhost` value becomes the `from` IP in the legitimate rule. The injected content after the newline is an entirely independent pf directive with fully attacker-controlled `from` and `to` values.\n\nThe capability gap between normal use and injection is therefore:\n\n| | Normal use (no `--localhost`) | Normal use (with `--localhost`) | Injection (with `--localhost`, domain contains `\\n`) |\n|---|---|---|---|\n| Writes pf rule | No | Yes | Yes |\n| `from` IP | — | User-specified | Arbitrary |\n| `to` IP | — | Hard-coded `127.0.0.1` | **Arbitrary** |\n| Rule type | — | `rdr inet` only | Any (`pass`, `block`, `nat`, …) |\n\nThe single capability that injection uniquely adds is: **writing a pf rule with an arbitrary `to` IP** — redirecting traffic to any external host rather than being confined to `127.0.0.1`.\n\n**Primary scenario: sudo delegation bypass**\n\nThe most direct attack path requires only that an administrator grants a restricted user sudo access to this specific command:\n\n```\n# /etc/sudoers\nuser ALL=(root) NOPASSWD: /usr/bin/container system dns create *\n```\n\nThe administrator's intent is to allow `user` to manage DNS domains for container networking. Under normal usage this is bounded: even with `--localhost`, the command can only produce `rdr ... -> 127.0.0.1` rules. Without `--localhost`, it produces no pf rules at all.\n\nWith the injection, the user provides any valid IP to `--localhost` to open the pf write path, then embeds the actual malicious rule in the domain name:\n\n```bash\nsudo container system dns create --localhost 127.0.0.1 \\\n $'evil.local\\nrdr inet proto tcp from any to 10.0.0.1 -> 203.0.113.1 port 4444'\n```\n\nThis is a classic sudo delegation bypass: the administrator delegated a scoped capability; the injection expands it to writing arbitrary kernel firewall rules.\n\n**Additional scenarios:**\n\n- An automated script or CI/CD pipeline that runs `sudo container system dns create $DOMAIN_FROM_ENV` where the environment variable originates from a container label, image metadata, or external API response — any newline in the upstream value triggers injection without any user action\n- A developer following documentation or a README that includes a crafted domain name example (social engineering)\n\n**Consequences of successful injection:**\n\n- pf redirect rules with arbitrary `from` and `to` IPs — enabling redirection of any host-level traffic to an attacker-controlled external address (not achievable through normal command use)\n- Additional rule types (`pass`, `block`, `nat`) with arbitrary port and protocol filters loaded into the kernel\n- Legitimate traffic selectively blocked (denial of service against specific endpoints)\n- Injected rules persist across DNS domain deletions — the `removeRedirectRule()` cleanup path cannot match and remove standalone injected lines\n\n\n#### Credit\n\nThis vulnerability was independently discovered and reported by multiple sources:\n\n- XlabAI Team of Tencent Xuanwu Lab\n- Atuin Automated Vulnerability Discovery Engine\n- Mohamed Abdelaal (@0xmrma)",
"severity" : [ {
"type" : "CVSS_V4",
"score" : "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "SwiftURL",
"name" : "github.com/apple/container"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "0.12.3"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 0.12.2"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/apple/container/security/advisories/GHSA-39g5-644c-qwcg"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/apple/container"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-20" ],
"severity" : "LOW",
"github_reviewed" : true,
"github_reviewed_at" : "2026-05-07T01:43:31Z",
"nvd_published_at" : null
}
}