Skip to content

GHSA-r8jp-q6fh-g5r2

CVE Information

Summary

Reviewed product: OpenPrinting CUPS
Reviewed branch: master
Reviewed commit: 764e4ae243c19a8f6d15e303adc2a0d1476ff087 (2026-08-24)
Original issue: CVE-2026-27447
Original fix: 88516bf6d9e34cef7a64a704b856b837f70cd220 (2026-03-31)

Current source still contains two case-insensitive comparisons on request-derived usernames outside the main authorization path hardened by CVE-2026-27447:

  • scheduler/ipp.c:check_quotas() compares explicit printer ACL usernames with _cups_strcasecmp(...) in the non-HAVE_MBR_UID_TO_UUID branch.
  • scheduler/policy.c:cupsdGetPrivateAttrs() compares @OWNER and explicit usernames with _cups_strcasecmp(...) when deciding whether job or subscription private attributes are filtered.

These branches preserve the same case-folding pattern removed from cupsdIsAuthorized() and cupsdCheckGroup(). They are reachable from normal IPP request handling. Current source confirms remaining case-folded identity handling in authorization-adjacent logic. Current source does not, by itself, establish a distinct security boundary bypass, because default policy, documentation, and follow-up history also preserve unauthenticated request-supplied owner/name semantics.

Relation to CVE-2026-27447

88516bf6d9e34cef7a64a704b856b837f70cd220 changed the primary local-account authorization path in scheduler/auth.c from case-insensitive string matching to exact matching for:

  • local user/group checks in cupsdCheckGroup()
  • @OWNER and explicit-user checks in cupsdIsAuthorized()

The two paths below were not changed by that fix and still use case-insensitive string comparison.

Affected code paths

1. Printer ACL path

  • get_username() accepts IPP requesting-user-name when the connection has no stronger identity: scheduler/ipp.c
  • set_printer_attrs() stores requesting-user-name-allowed / requesting-user-name-denied entries in printer->users: scheduler/ipp.c
  • add_job() calls check_quotas() before accepting the job: scheduler/ipp.c
  • add_job() persists request requesting-user-name into job->username when no stronger identity is present: scheduler/ipp.c
  • check_quotas() compares explicit usernames with _cups_strcasecmp(username, name) in the non-HAVE_MBR_UID_TO_UUID branch: scheduler/ipp.c

2. Private-attribute path

Reproduction

Path A: printer ACL username case-folding

Preconditions:

  • a printer or class has requesting-user-name-allowed set to an explicit username such as Alice
  • the build uses the non-HAVE_MBR_UID_TO_UUID branch

Request pattern:

OPERATION Print-Job
RESOURCE /printers/Test1
GROUP operation
ATTR charset attributes-charset utf-8
ATTR language attributes-natural-language en
ATTR uri printer-uri ipp://HOST/printers/Test1
ATTR name requesting-user-name alice
FILE testfile.ps

Effect from current source:

  • check_quotas() resolves the effective username through get_username(con)
  • the explicit ACL entry is matched with _cups_strcasecmp(username, name)

Path B: owner / private-attribute case-folding

Preconditions:

  • JobPrivateAccess or SubscriptionPrivateAccess includes @OWNER or an explicit username
  • the request reaches a read path that relies on cupsdGetPrivateAttrs() to decide what is filtered

Request pattern:

OPERATION Get-Job-Attributes
RESOURCE /jobs
GROUP operation
ATTR charset attributes-charset utf-8
ATTR language attributes-natural-language en
ATTR integer job-id 123
ATTR name requesting-user-name alice

Effect from current source:

  • cupsdGetPrivateAttrs() derives the effective username from the request
  • @OWNER and explicit usernames are matched with _cups_strcasecmp(...)
  • a NULL return leaves later copy helpers with no private-attribute exclusion list

Security relevance and limits

  • default policy leaves Create-Job, Print-Job, Print-URI, and Validate-Job without AuthType: conf/cupsd.conf.in
  • default policy also uses Require user @OWNER @SYSTEM for owner-style operations without AuthType: conf/cupsd.conf.in
  • documentation states that when no AuthType is configured, user information can come from the IPP request: doc/help/policies.html
  • follow-up commit 3f2d8f6d59ea6594aa77c36a98e4f6bdc249595f (2026-04-24) restored unauthenticated owner/name fallback in cupsdIsAuthorized(): scheduler/auth.c, scheduler/auth.c, scheduler/auth.c

These points matter for triage. If a deployment already accepts unauthenticated requesting-user-name for owner-style decisions, an attacker can already assert the exact target username in those flows. On current source review, the additional harm introduced by case-folding alone is not established.

Assessment

Confirmed from current source:

  • remaining case-insensitive username matching exists in two scheduler paths
  • both paths are reachable from documented request flows
  • one path affects explicit printer ACL username handling
  • one path affects private-attribute filtering decisions

Not established from current source:

  • a distinct exploit path with concrete new impact that depends on case-variant matching, rather than the already-documented request-username trust model

Review points

  • whether case-insensitive explicit username matching in check_quotas() is intentional
  • whether case-insensitive @OWNER / explicit-user matching in cupsdGetPrivateAttrs() is intentional
  • whether those semantics are expected to remain different from the exact-match behavior introduced in the main CVE-2026-27447 authorization fix

CVSS score commentary

WRT "requesting-user-name", those values are unauthenticated and case-insensitive.

The authenticated user is case sensitive only when matched against a local user account. Kerberos and OAuth identifiers are email addresses which are case-insensitive.

Fixes

[2.4.x 88e67c00c130a45f3a1edf36686f7a0b2982fef8] Consistently compare usernames for policies and quotas. [master f56844dbe4a54a9f8e1aeb3b913fbee614156bdb] Consistently compare usernames for policies and quotas.