CVE-2026-95511: Cups: cups-filters: cups-filters: lpadmin can escalate to root via privileged serial backend (cups2root)

Published Sep 22, 2026
·
Updated

A local privilege escalation exists in the CUPS printing stack used on Red Hat products. The cupsd scheduler decides that a backend runs as root based only on file permission bits (mode 0744 or 0700). Device URI validation in scheduler/ipp.c applies FileDevice path restrictions only to file: URIs. For other schemes, cupsd only checks that the backend binary exists and is executable. It does not validate the path component of the URI.

The serial backend, historically part of Apple CUPS, is not present in OpenPrinting CUPS HEAD (v2.5b1, commit 7cf4b97). Red Hat and Fedora ship it from the cups-filters package as /usr/lib/cups/backend/serial (or /usr/libexec/cups/backend/serial), installed root:root mode 0700 (RHEL 10 uses 0744). That mode still causes cupsd to run the backend as root. An lpadmin (SystemGroup) user can therefore configure a serial: device URI that causes a root-privileged backend to write job data to an attacker-chosen path, including cups-files.conf. cups-files.conf is otherwise protected from lpadmin HTTP PUT (restricted to cupsd.conf).

Impact: local privilege escalation from CUPS administrator (lpadmin) to OS root when the serial backend is installed.

Affected packaging: cups-filters serial backend on Fedora 43/44/45 and RHEL 8/9/10 (c8s/c9s/c10s specs). OpenPrinting CUPS core on HEAD does not build serial.

Fix: not yet available from upstream for this chain.

Reporter: Akiyoshi Kurita (Red Hat), forwarding the public cups2root report by v12-security. PSIRT Ticket: PSIRTSUPT-24165

Other sources

A privilege escalation vulnerability was found in CUPS when used with the cups-filters serial backend. A local user who is a member of the lpadmin group can configure a printer that uses a privileged serial backend. The CUPS scheduler does not restrict the path component of non-file device URIs, so the root-privileged backend can write attacker-controlled print data to an arbitrary file. This can be used to change security-sensitive CUPS configuration and ultimately achieve root code execution. Exploitation requires local lpadmin group membership and a serial backend binary installed with root-only permissions.

MITRE

Affected Software

2 affected components
fedora/cups-filters
redhat/cups-filters

Event History

Sep 22, 2026
Data Sourced
via Red Hat·07:48 AM
DescriptionSeverityAffected Software
CVE Published
via MITRE·08:35 AM
Data Sourced
via MITRE·08:35 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·09:17 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who can exploit this issue?

A local user who is a CUPS administrator through the SystemGroup, such as an lpadmin user, can exploit it. The issue escalates that existing CUPS administrative privilege to operating-system root.

2

Which installations are exposed?

Red Hat and Fedora systems are exposed when the cups-filters serial backend is installed at /usr/lib/cups/backend/serial or /usr/libexec/cups/backend/serial. The backend is shipped root-owned with mode 0700 on affected distributions, or 0744 on RHEL 10; both modes cause cupsd to run it as root.

3

What does an attacker need to do to reach root?

The attacker must be able to configure a serial: device URI through CUPS administration. They can use an attacker-chosen path in that URI so the root-privileged serial backend writes print job data to that path, including cups-files.conf.

4

How can I check whether a host is affected?

Check whether the serial backend exists and is executable at /usr/lib/cups/backend/serial or /usr/libexec/cups/backend/serial. Also identify accounts in the CUPS SystemGroup or otherwise able to use lpadmin, since those accounts are the relevant local attackers.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203