CVE-2026-34990

What it actually does

CVE-2026-34990 is a local privilege escalation flaw in OpenPrinting CUPS 2.4.16 and earlier. A low-privileged local user can cause cupsd to authenticate to an attacker-controlled IPP service on localhost and leak or reuse a local CUPS authorization token. That token can then be used to issue privileged localhost /admin/ requests. By abusing CUPS local-printer creation behavior with a shared printer configuration, the attacker can persist a file:// printer queue despite normal FileDevice restrictions. When data is printed to that queue, cupsd writes attacker-controlled content as root, creating an arbitrary root-owned file overwrite primitive that can be turned into full root command execution.

Why it matters to the business

An attacker who already has a standard local account or code execution as an unprivileged user on an affected Linux or Unix-like host can become root. This can lead to full host takeover, disabling security controls, credential theft, persistence, lateral movement, and tampering with business applications or data on the affected system. The issue is not listed in CISA KEV, is not known to be ransomware-used, and has a low, stable EPSS score, but it remains operationally important because CUPS is widely deployed on Linux systems and no public fixed versions were available at publication time.

How an attack unfolds

Exploitation starts with local access as an unprivileged user on a host running a vulnerable CUPS version. The attacker starts or controls a localhost IPP service and manipulates CUPS behavior so that cupsd authenticates to that service using a reusable local authorization token. The attacker then reuses that token to send administrative requests to cupsd over localhost. With administrative access to the CUPS interface, the attacker creates or modifies a local printer queue using CUPS local-printer creation behavior and marks it as shared, causing a file:// destination to persist even though direct file-device use is normally restricted. Finally, the attacker submits a print job to that queue, causing cupsd, running with elevated privileges, to write attacker-controlled content to a root-owned file path. The resulting file overwrite can be used to alter privileged configuration, establish persistence, or execute commands as root.

How to fix it

No public fixed versions were provided in the input. Monitor OpenPrinting and operating system vendor advisories and apply the first vendor-supported CUPS update or backport that addresses this issue as soon as it becomes available. Until patches are available, reduce exposure by disabling and masking CUPS services on systems that do not require printing, including cupsd service/socket activation where applicable. Remove or restrict CUPS administrative access for nonessential local users. Audit and remove printer queues using file:// DeviceURI values unless explicitly required and safe. Disable printer sharing where it is not needed. Use SELinux, AppArmor, systemd sandboxing, or equivalent mandatory access controls to limit cupsd write access to sensitive system paths. Restrict interactive shell access on systems where CUPS must remain installed. Treat any vulnerable multi-user host as higher risk because the flaw requires only local unprivileged access.

How to confirm the fix worked

Identify affected systems by checking installed CUPS versions with package manager inventory, cups-config --version, or cupsd -v, and treat OpenPrinting CUPS 2.4.16 and earlier as vulnerable unless the operating system vendor has shipped a confirmed backported fix. Confirm whether CUPS is running or socket-activated by checking cups.service, cups.socket, and active cupsd processes. Review /etc/cups/printers.conf and related CUPS configuration for unexpected file:// DeviceURI entries, unexpected shared printers, or recently created queues. After remediation, verify that the installed package version or vendor advisory explicitly includes the fix, that unnecessary CUPS services are disabled, and that a non-privileged local user cannot create or persist a file-backed shared printer queue through CUPS administrative interfaces.

Typical attack path

1. Gain local unprivileged access to a Linux or Unix-like system running OpenPrinting CUPS 2.4.16 or earlier.
2. Run or control an attacker-controlled IPP service bound to localhost.
3. Coerce cupsd into authenticating to the attacker-controlled localhost IPP service.
4. Capture or reuse the local CUPS authorization token.
5. Use the token to send administrative /admin/ requests to the local cupsd service.
6. Create or modify a shared local printer queue that persists a file:// destination.
7. Submit a print job to the malicious queue.
8. Use the resulting root-context file overwrite to gain root privileges or establish persistence.

How to detect it

Review CUPS logs and host telemetry for signs that a local user abused cupsd administrative functionality. Primary log sources include /var/log/cups/access_log, /var/log/cups/error_log, /var/log/cups/page_log, systemd journal entries for cups.service or cupsd, authentication logs, sudo logs, auditd logs, EDR process/file telemetry, and file integrity monitoring. Look for localhost administrative CUPS requests, unexpected IPP traffic to loopback addresses, creation of new local printers, changes to printer sharing settings, and printer queues with file:// DeviceURI values. Inspect /etc/cups/printers.conf for recent or unexpected file-backed queues and compare timestamps against CUPS logs. Hunt for privileged file modifications occurring immediately after CUPS print jobs, especially under /etc, /etc/sudoers.d, systemd unit directories, cron directories, SSH authorized key locations, shell profile paths, or PAM configuration. Because the vulnerability yields an arbitrary root file overwrite, indicators may vary; absence of a known filename does not rule out exploitation. Correlate any suspicious CUPS admin activity with local process execution by unprivileged users and subsequent root-level command execution.

• /var/log/cups/access_log
• /var/log/cups/error_log
• /var/log/cups/page_log
• /etc/cups/printers.conf
• cupsd
• cups.service
• cups.socket
• CUPS-Create-Local-Printer
• Authorization: Local
• /admin/
• printer-is-shared=true
• DeviceURI file://
• DeviceURI file:///
• file:///
• ipp://127.0.0.1
• ipp://localhost
• localhost IPP
• <Printer
• </Printer>
• /etc/sudoers.d/
• /etc/cron.d/
• /etc/systemd/system/
• /root/.ssh/authorized_keys

What your security team should do

• Inventory Linux and Unix-like systems for OpenPrinting CUPS 2.4.16 and earlier, prioritizing multi-user servers, developer workstations, bastion hosts, and systems with local shell access by many users.
• If printing is not required, stop, disable, and mask CUPS services and socket activation until a vendor fix is available.
• Monitor vendor advisories and apply fixed CUPS packages or vendor backports immediately when released.
• Audit CUPS printer configuration for unexpected file:// DeviceURI entries, shared local printers, and recent administrative changes.
• Hunt for evidence of local privilege escalation, especially suspicious writes to privileged configuration paths after CUPS administrative activity.
• Enforce SELinux, AppArmor, or comparable controls for cupsd to reduce the impact of arbitrary file-write behavior.
• Restrict local user access and remove unnecessary accounts on systems where CUPS must remain enabled.
• Create SIEM detections for suspicious CUPS administrative requests, local IPP interactions, and printer queue changes involving file:// destinations.