Zed99_Blog

I checked the installed CUPS version and found that the target was running CUPS 2.4.16.

I then searched for vulnerabilities affecting this version, specifically CVE-2026-34990. According to the vulnerability information, CUPS 2.4.16 and earlier are affected. The vulnerability allows a local unprivileged user to abuse CUPS authentication and, under the vulnerable configuration, achieve an arbitrary root file overwrite, which can ultimately be leveraged for local privilege escalation.

At a high level, the vulnerability occurs because CUPS places too much trust in data controlled by a local unprivileged user. In simple terms: a low-privileged user on the machine can trick cupsd into exposing an admin authentication token, then use that token to create a printer pointing to file:///.... Since CUPS runs as root, it can overwrite arbitrary files, which can ultimately be leveraged to gain root access.

The attack flow can be summarized as follows:

• First, the attacker needs an IPP server under their control on localhost. CUPS has a legitimate feature for creating a local printer and performing background validation of its device-uri. The issue lies in the processing order in the vulnerable version: create_local_printer() can store the device-uri before the background validation has completed.
• Once the printer is created, CUPS’s background validation will connect to the specified device-uri. Since the device-uri is controlled by the attacker, the connection is directed to the fake IPP server running locally. The attacker then sends an authentication challenge, causing CUPS to perform Local authentication itself. CUPS has a Local authentication mechanism designed to allow local components to authenticate with each other. In the vulnerable flow, a privileged @SYSTEM authentication challenge over localhost causes CUPS/libcups to use the corresponding local/system credential associated with certs/0. The attacker controls the endpoint’s response, but CUPS ends up supplying its own credential.
• Once the token has been captured, the attacker can use it to make authenticated CUPS requests over localhost. However, this still does not provide a root session. CUPS also has a mechanism for protecting file:// device URIs through FileDevice. Under the normal printer administration path, a device-uri such as file:///target would typically be rejected because FileDevice does not allow plain-file destinations.
• The attacker instead abuses the behavior of create_local_printer(), which allows the supplied device-uri to be stored before validation has completed. This makes it possible to create a temporary printer pointing to a file destination, even though the normal administrative path would reject such a destination.
• The printer is initially temporary, but CUPS has a property called printer-is-shared. In the vulnerable logic, when the printer is marked as shared (True), its temporary state can be cleared. The important point is that the dangerous device-uri is already present in the printer state from the previous step and is not sufficiently revalidated before the printer is transitioned into a persistent state.
• Once the attacker has a persistent printer, they can submit a Print-Job. At this point, the attacker does not directly open /target (which, in the PoC, is the newly created sudoers file). Instead, the CUPS scheduler processes the destination and opens the file with flags equivalent to: O_WRONLY | O_CREAT | O_TRUNC. If the file does not already exist, O_CREAT is what causes it to be created before the content is written. And since cupsd is running with root privileges, creating and writing a file at the sudoers path is not a problem. This results in an arbitrary file overwrite primitive.

One important thing to note is that the authentication token does not directly give the attacker root privileges. The token only allows the attacker to perform administrative operations on CUPS. The reason the file can be written with root privileges is that cupsd runs under UID 0, as we observed earlier when checking the process.

Okay, I’ll use the PoC from the GitHub link above to perform the exploit. However, if you simply copy and paste the code from the original link and run it, it won’t work because the author added a few extra checks that require the user running the exploit to have root privileges or sudo permissions. In our case, the aporter user is neither root nor a member of the root group, and does not have permission to execute any sudo commands. Therefore, we need to make a few small modifications to the PoC code. You can download the modified version here.

Alongside the exploit file, I’ve also included another file called cups-create-local-printer. Simply put, it is a request template/specification for ipptool. It describes how ipptool should construct and send an IPP request to invoke CUPS-Create-Local-Printer. You don’t necessarily need to use this file. I only included it as a template so that ipptool can generate the corresponding request without having to manually construct the IPP request in the code.

After downloading the PoC exploit script, I’ll upload it to the apporter user’s SSH session and run it. As shown in the screenshot below, the apporter user does not have permission to use sudo at all.