# GHSA-39g5-644c-qwcg: container: pf Rule Injection via Domain Name Argument in `container system dns create --localhost` Command

> Attackers with limited sudo access can inject arbitrary firewall rules via unsanitized domain names, bypassing intended localhost-only restrictions.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 7 May 2026

## What is GHSA-39g5-644c-qwcg?

GHSA-39g5-644c-qwcg is a command injection vulnerability in github.com/apple/container, published on 7 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

#### 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)

## Which versions are affected by GHSA-39g5-644c-qwcg?

2 open source packages ship an affected version, including github.com/apple/container.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/apple/container` | SwiftURL | All versions | 0.12.3 |
| `github.com/apple/container` | SwiftURL | All versions | 0.12.3 |

## How do I fix GHSA-39g5-644c-qwcg?

Upgrade github.com/apple/container to 0.12.3 or later.

## Is GHSA-39g5-644c-qwcg being exploited?

There is no known exploitation of GHSA-39g5-644c-qwcg in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-39g5-644c-qwcg and fix it if it is affected.

What it is: GHSA-39g5-644c-qwcg is a command injection vulnerability in github.com/apple/container, published on 7 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-39g5-644c-qwcg in the wild and no public exploit code.

Affected packages and fixed versions:
- github.com/apple/container (SwiftURL): affected all versions; fixed in 0.12.3
- github.com/apple/container (SwiftURL): affected all versions; fixed in 0.12.3

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-39g5-644c-qwcg/ (Markdown: https://insights.sbomify.com/GHSA-39g5-644c-qwcg/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-39g5-644c-qwcg

---
From sbomify Insights: https://insights.sbomify.com/GHSA-39g5-644c-qwcg/
Summaries are generated and may contain mistakes; the official description above is the record.