CVE-2026-87876

What it actually does

In CUPS's scheduler, two case-insensitive comparisons of request-derived usernames sit outside the main authorization path (printer ACL validation and private-attribute filtering). When username-based access controls are in use, a requester whose name differs only by letter case from an allowed principal can pass those secondary checks even if the primary authz decision would have treated the names as distinct. The result is a limited authorization bypass: unauthorized read of ACL-protected printer state or private IPP attributes. Impact is confidentiality-only (CVSS 3.0: AV:A/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N); integrity and availability of print jobs and the scheduler are not affected.

Why it matters to the business

Operational risk is low. An already-authenticated local or adjacent-network user, with some user interaction, may view print-queue metadata or private printer attributes they should not see. There is no known in-the-wild exploitation (exploit maturity None), the CVE is not in CISA KEV, it is not associated with ransomware, and EPSS remains ~0.33% with no 30-day movement. Organizations that rely on case-sensitive CUPS usernames to isolate printers, jobs, or attributes across teams should treat this as a confidentiality control gap until patched (RHSA-2026:67568). Environments that do not use username ACLs, or that already fold usernames to a single case, are largely unaffected.

How an attack unfolds

An attacker who already holds a low-privilege account on a host or network that can reach the CUPS scheduler crafts IPP or CUPS client requests using a username that matches an authorized ACL entry except for character case. Because printer ACL validation and private-attribute filtering compare those request-derived names case-insensitively and outside the main authorization path, the scheduler may treat the attacker as the allowed principal for those checks. The attacker then reads otherwise-restricted printer ACLs or private attributes. User interaction is required (for example, an authorized user or admin action that surfaces the protected object). No remote unauthenticated access, no job tampering, and no scheduler crash are implied. There are no named threat actors or campaigns tied to this CVE.

How to fix it

Upgrade Red Hat cups-main to the fixed build 2.4.19-4.2.hum1 as shipped in RHSA-2026:67568, then restart the CUPS scheduler (cupsd) so the patched comparison logic is loaded. If an immediate upgrade is not possible, temporarily avoid relying on case-distinct usernames for printer ACLs and private-attribute access (normalize usernames to a single case in directory and CUPS ACL configuration), restrict who can reach the scheduler on the adjacent network, and limit membership of print-related groups. Do not leave mixed-case ACL entries as the sole isolation control. After patching, restore intended ACL policy and verify it still matches operational needs.

How to confirm the fix worked

Confirm the installed cups package is 2.4.19-4.2.hum1 or later (rpm -q cups / yum updateinfo list RHSA-2026:67568) and that cupsd has been restarted after the upgrade. Review printers.conf and related ACL/private-attribute configuration for username-based Allow/Deny or private-attribute rules. From a test account whose name differs only by case from an allowed principal, attempt to list restricted printers and fetch private attributes and confirm denial after the patch. Compare scheduler logs before and after to ensure authorization decisions no longer succeed solely due to case folding on those two paths.

Typical attack path

1. Gain a low-privilege authenticated identity that can speak to the CUPS scheduler on the local or adjacent network.
2. Identify printers or queues that enforce username-based ACLs or private IPP attributes.
3. Submit IPP/CUPS requests whose request-derived username differs only in case from an ACL-allowed name.
4. Hit the scheduler paths that perform case-insensitive ACL validation or private-attribute filtering (outside main authorization).
5. Read restricted printer ACL state or private attributes that should have been denied.
6. No further privilege escalation, job modification, or persistence is provided by this flaw alone.

How to detect it

There is no public exploit, named actor, or KEV activity to hunt for. Focus on whether mixed-case usernames were used against CUPS ACL or private-attribute paths before the patch. Review cupsd/error_log and access_log (and journald unit cups) around IPP Get-Printer-Attributes, Get-Jobs, and ACL-related operations for authenticated users whose logged name differs only by case from an Allow entry. Look for successful reads of printers or attributes that policy says that account should not see. Network captures of IPP to tcp/631 from adjacent hosts with unexpected username case are supporting evidence, not proof. Absence of such logs does not prove non-exploitation because default CUPS logging may not record the comparison. After patching, a sudden stop of those mismatched-case successes is consistent with the fix taking effect.

• cupsd
• /var/log/cups/error_log
• /var/log/cups/access_log
• ipp://
• Get-Printer-Attributes
• tcp/631
• CUPS-Get-Printers

What your security team should do

• Patch cups-main to 2.4.19-4.2.hum1 (RHSA-2026:67568) and restart cupsd on all affected Red Hat systems; this is the primary fix.
• Inventory hosts running CUPS with username-based printer ACLs or private-attribute filtering; prioritize multi-user print servers.
• Until patched, do not use case-distinct usernames as the only ACL isolation; fold names to one case or tighten network access to the scheduler.
• Treat as low urgency given CVSS 3.0, EPSS ~0.33% (flat), no KEV listing, no ransomware use, and no known exploits 31 days after publication—but do not skip the RHSA on shared print infrastructure.
• Add a configuration review of CUPS ACLs to the next print-server hygiene pass so mixed-case Allow/Deny entries are not reintroduced as a control.