GHSA-39g5-644c-qwcg: container Pf Rule Injection Vulnerability

LOW
CWE-20
Published
Advisory Summary

GHSA-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

CVE Identifier N/A
GHSA Identifier GHSA-39g5-644c-qwcg
Severity LOW
CVSS v3.1 Base Score N/A
CWE Classification CWE-20: Improper Input Validation
Affected Product container
Package Ecosystem SwiftURL
Published Date
Last Updated

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.

github.com/apple/container fixed: 0.12.3
Upgrade github.com/apple/container to 0.12.3
Verify Direct and Transitive Dependencies

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

#### Product Name: container Github Link: https://github.com/apple/container Version: <= 0.12.2 #### Summary The `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. A `isValidDomainName()` function exists in `Parser.swift:892` but is **never called** from `DNSCreate`. **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.** #### Impact **What a legitimate invocation can write** `--localhost` is an optional parameter. Its presence or absence determines whether any pf rule is written at all: - **Without `--localhost`**: only a resolver config file is written; no pf rule is produced. - **With `--localhost <IP>`**: exactly one rule is written to the pf anchor file: ``` rdr inet from any to <IP> -> 127.0.0.1 # <domain> ``` The 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. **What injection additionally enables** The 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. ```bash 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 `--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. The capability gap between normal use and injection is therefore: | | Normal use (no `--localhost`) | Normal use (with `--localhost`) | Injection (with `--localhost`, domain contains `\n`) | |---|---|---|---| | Writes pf rule | No | Yes | Yes | | `from` IP | — | User-specified | Arbitrary | | `to` IP | — | Hard-coded `127.0.0.1` | **Arbitrary** | | Rule type | — | `rdr inet` only | Any (`pass`, `block`, `nat`, …) | The 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`. **Primary scenario: sudo delegation bypass** The most direct attack path requires only that an administrator grants a restricted user sudo access to this specific command: ``` # /etc/sudoers user ALL=(root) NOPASSWD: /usr/bin/container system dns create * ``` The 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. With 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: ```bash sudo container system dns create --localhost 127.0.0.1 \ $'evil.local\nrdr inet proto tcp from any to 10.0.0.1 -> 203.0.113.1 port 4444' ``` This is a classic sudo delegation bypass: the administrator delegated a scoped capability; the injection expands it to writing arbitrary kernel firewall rules. **Additional scenarios:** - 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 - A developer following documentation or a README that includes a crafted domain name example (social engineering) **Consequences of successful injection:** - 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) - Additional rule types (`pass`, `block`, `nat`) with arbitrary port and protocol filters loaded into the kernel - Legitimate traffic selectively blocked (denial of service against specific endpoints) - Injected rules persist across DNS domain deletions — the `removeRedirectRule()` cleanup path cannot match and remove standalone injected lines #### Credit This vulnerability was independently discovered and reported by multiple sources: - XlabAI Team of Tencent Xuanwu Lab - Atuin Automated Vulnerability Discovery Engine - Mohamed Abdelaal (@0xmrma)

GHSA-39g5-644c-qwcg Affected container Versions

1 component(s)
Fixed Versions:
0.12.3
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?
GHSA-39g5-644c-qwcg is a security vulnerability in container involving pf Rule Injection via Domain Name Argument in `container system dns create --localhost` Command under CWE-20: Improper Input Validation.
Which container versions are affected?
Affected versions include releases prior to 0.12.3 across affected packages: github.com/apple/container.
What version fixes GHSA-39g5-644c-qwcg?
Upgrading to 0.12.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/apple/container affected?
Yes, github.com/apple/container is affected in releases prior to 0.12.3. Upgrade your dependency to 0.12.3 or later.
What CWE is associated with GHSA-39g5-644c-qwcg?
GHSA-39g5-644c-qwcg is classified under CWE-20: Improper Input Validation (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.).
How can I check SwiftURL dependencies for GHSA-39g5-644c-qwcg?
Run the dependency tree command: 'inspect dependencies for github.com/apple/container'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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
  }
}