CVE-2022-4318: CRI-O Newline Injection Enables /etc/passwd Bypass in Kubernetes

A quietly serious flaw in the CRI‑O container runtime — tracked as CVE‑2022‑4318 — lets a crafted environment variable inject arbitrary lines into a container’s /etc/passwd, enabling admission‑validation bypasses and, in specific cluster configurations, a path to privilege escalation; the bug was fixed in CRI‑O v1.26.0 and patched in downstream OpenShift errata, but the vulnerability highlights persistent, structural risks in container user‑mapping, admission control assumptions, and platform hardening that every Kubernetes operator should address now.

Background / Overview​

CRI‑O is a lightweight, OCI‑compatible container runtime used widely in Kubernetes distributions and as the default runtime in many OpenShift deployments. It is responsible for preparing the container process environment and — among other chores — ensuring a running container can resolve and map the effective UID/GID it uses to an entry in /etc/passwd when processes expect name→UID resolution. CVE‑2022‑4318 stems from how CRI‑O handled that mapping: a maliciously crafted environment variable containing newline characters allowed CRI‑O to add attacker‑controlled lines into the container’s /etc/passwd file, thereby introducing user records the container runtime and other components might trust.
CRI‑O’s project and security teams tracked the issue publicly (GitHub Advisory GHSA‑cm9x‑c3rh‑7rc4 / GO‑2022‑1206) and landed a fix in the v1.26.0 release; Red Hat also published errata for affected OpenShift builds and pushed fixes into supported platforms.

---

What the vulnerability actually does — technical anatomy​

Root cause, in plain terms​

At its core, CVE‑2022‑4318 is an insertion problem. CRI‑O accepted environment variable values that contained newline characters and — in the process of creating or supplementing a container’s /etc/passwd mapping — used those values to append lines into /etc/passwd without adequate sanitization. The newline injection transforms a single environment variable into the ability to place one or more newline‑terminated records into a file that governs local user name resolution.
Because Unix/Linux name resolution uses /etc/passwd (or NSS) to map user names and numeric UIDs, an attacker who can place a line containing a synthetic user with a chosen UID can make processes inside the container resolve that UID to a username and home directory — potentially bypassing admission checks that validate submitted usernames/UIDs. That behavior becomes a problem when higher‑privilege mappings or admission rules assume that /etc/passwd is strictly controlled by the image author or by the cluster operator.

Required attacker capabilities and how exploitation works​

This is not a remote, unauthenticated kernel exploit; it is an environment injection vulnerability with a local attack vector. Practical exploitation scenarios include:

• A malicious pod author or attacker who can create a pod spec that sets environment variables for the container. If that env var includes newline characters, CRI‑O’s earlier behavior could cause arbitrary lines to be added to the container /etc/passwd at runtime.
• An attacker who has prepared an image or init container that can influence the environment seen by CRI‑O during container start (for example, via ENTRYPOINT/command and process substitution), and the runtime then injecting entries based on that environment.

Key constraints: the attacker must be able to start a container whose environment CRI‑O will process — in most clusters that means they need permission to create pods in a namespace (i.e., be a pod author). That condition makes the vulnerability low‑complexity when an attacker has pod creation rights, but higher complexity where strong admission control or RBAC prevents untrusted users from scheduling pods.

Why this matters: admission bypass → privilege escalation chain​

On its own, adding lines to a container’s /etc/passwd may appear limited: after all, the pod author normally controls the image and the container’s content. However, several cluster behaviors make this insertion impactful:

• Some admission controllers or cluster policies validate that a pod will run as a non‑privileged UID by checking that the requested UID corresponds to a recognized username. If an attacker can inject a passwd record that maps the requested UID to a legitimate username, those checks can be bypassed. The advisory explicitly notes the ability to circumvent admission validation of username/UID by adding such an entry.
• In environments where Security Context Constraints (OpenShift) or Pod Security Policies (deprecated) allow broad UID choices (for example, permitting the anyuid SCC), an attacker who manufactures a UID mapping could make a container start with a UID that maps to a privileged username, or otherwise trick host tooling that relies on username strings into treating the process differently. That can escalate a container compromise into host impact in misconfigured clusters.
• Worse, if additional misconfigurations exist (for example, writable host mounts, overly permissive SCCs, or insecure runtime helpers), the newly mapped UID could be used together with other flaws to break out or perform actions the cluster operator would otherwise block. This is the classic vulnerability chaining problem: individually minor laxities combine into a major impact.

---

What vendors and maintainers said and did​

• The CRI‑O team published a security advisory (GHSA‑cm9x‑c3rh‑7rc4 / GO‑2022‑1206), acknowledged the issue, and designated v1.26.0 as the release that includes the fix. The advisory also noted that because a pod author already controls the container’s /etc/passwd in many practical cases, the defect is a transparency matter but still required a fix to prevent admission bypasses and surprise behaviors.
• Red Hat released errata for affected OpenShift versions (RHSA advisories) and linked the fix into OpenShift release updates for their supported streams; operators on Red Hat platforms should apply the corresponding security updates. Red Hat’s advisories and bugzilla entries were used to track packages and CVE assignment.
• Upstream advisories and vulnerability databases (NVD, OSV, StackWatch, Tenable, Rapid7, etc.) cataloged the CVE and flagged its severity in the high range under CVSSv3 (7.8 in many trackers), reflecting the high integrity/confidentiality impacts in scenarios where the attack is feasible.

---

Exploitation scenarios — realistic vs. theoretical​

Realistic (common) scenarios​

• A multi‑tenant cluster allowing untrusted users to deploy workloads: an attacker who can create pods with attacker‑controlled env vars can inject /etc/passwd lines and evade UID checks enforced by naive admission controllers. This scenario is especially relevant in clusters where namespace isolation is used for tenancy but pod creation is permitted for many identities.
• CI/CD runners or automated builders that accept user‑supplied environment variables for builds and then spin up pods using those variables; a malicious pipeline step could feed dangerous env values and cause unintended injection during container startup.

Less realistic / higher bar scenarios​

• Direct host compromise via this bug alone is unlikely in a properly configured cluster. For host takeover the attacker would typically need additional misconfigurations (privileged host mounts, insufficient SELinux/AppArmor confinement, or permissive SCCs such as anyuid combined with writable hostPaths). In other words, CVE‑2022‑4318 is a dangerous enabler, not always a full container escape or immediate root on host bug by itself.

---

Detection, hunting, and indicators​

Detecting attempts to exploit this class of bug requires focusing on the pod creation pipeline and container startup artifacts:

• Audit the Kubernetes API server and admission logs for pod create requests that include environment variables with suspicious characters (newline, carriage return) or unusual encodings. Admission controller logs and API‑server audit logs will show the pod spec and the env payloads. Look for env entries with embedded newline sequences.
• Inspect container filesystem changes at startup time. If your runtime or host monitors container images and overlays, anomalous writes to /etc/passwd during runtime (rather than being baked into the image) are a red flag. In OpenShift/RHCOS environments, errata and advisory guidance recommends verifying package/cni/container runtime versions as part of detection.
• Use runtime integrity checks or in‑pod file monitors for sensitive files in the container overlay (where feasible). A non‑image /etc/passwd file being created/modified at runtime should trigger an alert.
• Correlate with RBAC and workload provenance: if a pod spec with unusual env values was created by a service account used in CI or by a low‑privilege user who shouldn’t run arbitrary workloads, treat this as suspicious and pivot to an audit of that service account’s use.

---

Mitigations and immediate actions​

If you operate CRI‑O or OpenShift clusters, take the following steps immediately and prioritize them as shown.

• Patch first (highest priority)
• Upgrade CRI‑O to v1.26.0 or later where the fix is present, or apply your vendor’s patched packages. For OpenShift customers, install the security errata (for example, the RHSA updates) for your cluster stream. These updates close the window of automatic injection via the vulnerable code path.
• Harden admission and pod creation controls
• Deny newline characters in environment variable values via validating admission controllers (OPA Gatekeeper, Kyverno, or custom mutating/validating webhooks). Implement a policy that rejects env vars containing control characters, and treat any env value with embedded newlines as a policy violation.
• Reduce privileges and tighten SCCs/PSPs
• Avoid permissive SCCs like anyuid where possible. Lock down Pod Security admission to enforce ranges for runAsUser and reject pods that request UIDs outside an allowed range. If an image absolutely requires special UID handling, treat it as a higher‑trust image and run it in a tightly controlled project.
• Strengthen host confinement
• Ensure LSMs such as SELinux or AppArmor are enabled and properly configured on worker nodes. These LSMs limit what a container process can do even if it obtains root inside the container overlay. The CRI‑O advisory points to SELinux as an important additional barrier.
• Sanitize environment sources in CI/CD
• Sanitize and validate any environment variables coming from user inputs or external artifact sources in your pipeline. Make sure build and deployment tooling does not pass unsanitized, user‑supplied env values to pod specs.
• Monitor /etc/passwd writes and container filesystem mutation
• Add file‑integrity monitoring for sensitive runtime changes (either on the host overlay or via container runtime hooks) and alert on unexpected /etc/passwd modifications that occur after image launch.

---

Critical analysis — strengths, limitations, and residual risk​

Strengths of the response​

• The CRI‑O project fixed the issue in a timed release (v1.26.0) and documented the advisory through GHSA/OSV channels, which made patches and vendor errata possible. Upstream transparency and a clear fixed release mean operators have an immediate remediation path.
• Red Hat integrated the fix into OpenShift errata, allowing platform users to receive the update via normal channeling and lifecycle streams. That reduces the window for confusion among enterprise customers who rely on vendor packages.

Limitations and unanswered questions​

• The advisory notes a key nuance: a pod author already controls much of the container user namespace by virtue of image content and env settings, so the injected‑passwd variant is not an entirely new threat model but an escalation of existing risk. That subtlety can lull operators into complacency: because pod authors can already arrange UIDs via images, some teams might deprioritize the patch. This is dangerous: the vulnerability circumvents admission validation in ways operators may not expect, making policy enforcement brittle.
• Detection is imperfect. Because an attacker with pod‑creation rights can reach the same effect by baking /etc/passwd entries into a malicious image, runtime detection must combine API auditing with filesystem integrity measures — and many clusters do not have that layered monitoring in place.
• Residual risk remains in clusters that cannot be patched quickly — for example, heavily‑regulated platforms with slow change windows. In those environments, administrators must rely on hardening and admission policies to prevent the attack surface from being exploited. That’s workable, but operationally brittle and error‑prone.

---

Actionable checklist for operators (prioritized)​

• Patch:
• Upgrade CRI‑O to v1.26.0+ or apply vendor packages for your distribution. For OpenShift clusters, install the RHSA updates corresponding to your version stream.
• Policy:
• Implement admission rules to reject environment variables containing newline or other non‑printable control characters.
• Enforce strict Pod Security Admission (or equivalent policies) that limit runAsUser ranges and reject privileged/anyuid SCCs unless absolutely necessary.
• Hardening:
• Ensure SELinux/AppArmor are enabled and enforce confinement for container processes.
• Restrict hostPath and privileged access; eliminate writable host mounts unless required and reviewed.
• Detection:
• Enable and review API server audit logs for pod creation with suspicious env payloads.
• Add filesystem monitoring or runtime detection for unexpected /etc/passwd writes in container overlays.
• Triage & incident response:
• If a suspicious pod with newline env entries was created, treat the namespace and related service accounts as potentially compromised. Rotate credentials and scan for lateral activity.
• Review CI/CD pipelines for places where untrusted inputs can reach pod specs.

---

Final assessment — who should worry and why​

• High‑priority: cluster operators who permit self‑service pod creation (multi‑tenant clusters, developer sandboxes, CI runners) must prioritize the patch and admission policies. The attack vector is straightforward when an attacker can create pods.
• Medium‑priority: single‑tenant, strictly curated clusters where only trusted images and pod specs are allowed still benefit from the patch; the fix removes a class of surprising behavior and reduces the operational burden on admission logic.
• Lower‑priority: fully air‑gapped clusters with strict RBAC and no untrusted pod authors are at less immediate risk, but should still plan updates — vulnerability fixes are defensive hygiene and reduce future attack surface.

---

Conclusion​

CVE‑2022‑4318 is a reminder that small input‑validation failures in the container runtime can break assumptions made far up the stack — in admission controllers, platform policies, and operational hardening. Although the exploit requires some local ability to create pods or influence the environment seen by CRI‑O, the path from environment‑variable newline to /etc/passwd record to admission bypass is short and low‑cost for a capable attacker in permissive clusters. The fix exists (CRI‑O v1.26.0 and vendor errata), and operators should treat this as a standard‑priority security update: patch, tighten admission policies, enable runtime confinement, and monitor for suspicious pod creation. Doing so removes an elegant but dangerous trick from an attacker’s toolbox and restores a clearer boundary between what image authors control and what the platform enforces.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center