GHSA-39G5-644C-QWCG

container: pf Rule Injection via Domain Name Argument in container system dns create --localhost Command

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.

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:

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:

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

The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.

Kodem intelligence

Already deployed Kodem?

1. What is GHSA-39G5-644C-QWCG? GHSA-39G5-644C-QWCG is a low-severity improper input validation vulnerability in github.com/apple/container (swift), affecting versions <= 0.12.2. It is fixed in 0.12.3. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
2. Which versions of github.com/apple/container are affected by GHSA-39G5-644C-QWCG? github.com/apple/container (swift) versions <= 0.12.2 is affected.
3. Is there a fix for GHSA-39G5-644C-QWCG? Yes. GHSA-39G5-644C-QWCG is fixed in 0.12.3. Upgrade to this version or later.
4. Is GHSA-39G5-644C-QWCG exploitable, and should I be worried? Whether GHSA-39G5-644C-QWCG is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-39G5-644C-QWCG is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-39G5-644C-QWCG? Upgrade github.com/apple/container to 0.12.3 or later.

Other vulnerabilities in github.com/apple/container