In the latest chapter on leaky CUPS, a security researcher and his band of bug-hunting agents have found two flaws that can be chained to allow an unauthenticated attacker to remotely execute code and achieve root file overwrite on the network.
CUPS – or the Common Unix Printing System, as it is less commonly known – is the standard way to submit files for printing over Linux and other Unix-like systems. It’s also a favorite target for security researchers because a) making printers do bad things is fun, and b) as the default printing system for Apple device operating systems and most Linux distributions, any CUPS security flaw has a wide blast radius.
Asim Viladi Oglu Manizada and his team of vulnerability hunting agents recently discovered two issues in CUPS, CVE-2026-34980 and CVE-2026-34990, and the SpaceX security engineer said he was inspired by software developer Simone Margaritelli’s 2024 research chaining several CUPS vulnerabilities to achieve unauthorized remote code execution (RCE).
The two new vulnerabilities affect CUPS 2.4.16, and while there’s not yet a patched version of the open source printing system, there are public commits with fixes to both issues.
CVE-2026-34980 requires the CUPS server to be reachable over the network and expose a shared PostScript queue. This configuration allows other computers on the network to share access to a printer, so it’s more likely to be used in business environments.
As Manizada said in a Sunday analysis: “This would be a deliberate config choice – realistic for, say, networked printing servers in your corporate environment, but not for your desktop (unless you for some reason set it up to be a remote printing server).”
But assuming those prerequisites are met, CVE-2026-34980 can be used by an unauthenticated attacker to submit a print job to the shared PostScript queue and achieve remote code execution as lp.
It can then be chained with CVE-2026-34990, an authorization flaw that works on the default CUPS configuration, to allow a low-privileged account printing to that queue to achieve root file overwrite.
Manizada told The Register that he doesn’t have any hard numbers as to how many printers are vulnerable to these CVEs, and he hasn’t personally seen any signs of exploitation to date. “But given that the maintainer-released advisories contain the PoCs and that LLMs can now quickly convert writeups to PoCs, I’d expect this to be trivially exploitable on affected deployments,” he added.
How it works
The first vulnerability, CVE-2026-34980, stems from CUPS’ default policy that accepts anonymous print-job requests, and only blocks remote printing when the queue is not shared. “This gives us the ability to target all the rich escaping/parsing logic on a shared queue without any auth layer by default,” Manizada wrote.
CUPS also prefixes newlines with a backslash, and then later strips out the backslash when it parses that option string, which means an attacker can embed code into the newline that will survive option escaping and reparsing.
Plus, CUPS treats “PPD:” as a trusted control record, and this can be abused to modify the queue configuration, inject a malicious entry into the PPD, then send a second print job tricking CUPS into executing an attacker-chosen existing binary – for example, the Vim text editor running as lp.
As CUPS creator and project maintainer Michael Sweet explains, using the Vim text editor as the binary:
The second flaw, CVE-2026-34990, can be abused by a local, unprivileged user to trick the CUPS scheduler daemon (cupsd) into authenticating to an attacker-controlled localhost IPP service with a reusable Authorization: Local … token.
“So, the attacker can stand up a fake printer on [a local host] and trigger CUPS to set it up,” Manizada said.
Printing to that queue allows arbitrary root file overwrite, and, when chained to the earlier bug, gives an unauthenticated, unprivileged remote attacker root file overwrite over the network.
The bigger picture in all of this, according to Manizada, and as several other security researchers and execs have pointed out, is that AI is getting very good at finding vulnerabilities in code. Meanwhile, human maintainers struggle to keep up with patching.
“You may not vibe-discover the whole chain with a single ‘find me a remote RCE to root, make no mistakes’ prompt,” Manizada wrote. “But tasking them with a) a search for a remote code exec as anything and b) anything -> a useful root primitive allows the agents to greatly narrow the search space and not burn as many tokens.” ®
Click Here For The Original Source.
