If your Linux server runs a shared PostScript print queue, a remote attacker with no credentials whatsoever can — right now — execute arbitrary code on it, then quietly escalate to root. That's the condensed version of two newly disclosed vulnerabilities in CUPS, the printing backbone of virtually every Linux and Unix-like system.
Security researcher Asim Manizada, working with a self-orchestrating team of AI agents that hunt for AI vulnerabilities, discovered and chained the two flaws: CVE-2026-34980 and CVE-2026-34990. The chain moves from unauthenticated network access to writing arbitrary files as root — including overwriting /etc/sudoers.d/ to own the machine outright.
- CVE-2026-34980: Malicious print job on a shared PostScript queue → code execution as
lp(the CUPS service user) over the network. No authentication is required by default. - CVE-2026-34990: Any local unprivileged user can steal the CUPS admin token via a fake printer, then race the scheduler to persist a
file:///queue and write files as root.
The first bug lies in how CUPS serializes and later re-parses print job attributes. When an option value contains a newline, CUPS escapes it with a backslash — and strips that backslash on the way back out. That newline survives the full round trip.
In a PostScript queue, the pstops filter logs invalid page-border values and only prefixes the first line of the log message. Smuggle a newline into that value, and the second line can start with PPD: — the marker CUPS treats as a trusted control record, not user input. From there, an attacker can inject a malicious filter entry into the queue's PPD configuration and get CUPS to execute an attacker-chosen binary.
"You may not vibe-discover the whole chain with a single prompt — but tasking agents with a search for remote code exec and anything-to-root lets them narrow the search space and not burn tokens."
The second bug is subtler and more dangerous in scope: it works on the default CUPS config, no shared queue needed. Any local user who can bind a TCP port and reach the local CUPS listener can create a temporary printer pointed at their own listener. CUPS then authenticates to that fake printer using its Local scheme, presenting an admin token.
The attacker captures that token, creates another temporary queue pointing at file:///etc/sudoers.d/pwn, and immediately uses the stolen token to flip printer-is-shared=true — persisting the queue before CUPS's background validation can clean it up. Win that race (typically single-digit attempts) and every print job to that queue becomes a root-level file write.
CUPS does have a guardrail against file: device URIs unless FileDevice is explicitly enabled — but the temporary printer path stores the URI first and only validates after the shared flag has already cleared the temporary status. The check never runs.
As of April 5, 2026, fixes exist in public commits, but no patched release has shipped. The latest version, 2.4.16, remains vulnerable.
What you can do right now
- Do not expose CUPS over the network, especially with a shared PostScript queue.
- If a shared queue is unavoidable, require authentication for all job submissions.
- Ensure CUPS runs under a hardened AppArmor or SELinux policy — this significantly limits the blast radius of both bugs.
- Monitor the OpenPrinting CUPS repository for a fixed release and patch immediately when available.
The research also marks a notable moment for AI-assisted vulnerability hunting. Manizada's agents didn't find the full chain in one sweep — instead, they were tasked separately with finding remote code execution and a root-write primitive, then left to pursue each with "relentless" focus. The two halves clicked together into a working exploit chain.