Cloudanix VulnDB

CVE-2026-87875

Medium · 4.3

CVSS

4.3

EPSS

0.4%

Published

Sep 9, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in print-server software can let someone on the same local network peek at a small amount of leftover memory, and applying the vendor update closes that gap.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
Network Service
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

A heap out-of-bounds read in CUPS's cupsUTF32ToUTF8() (cups/transcode.c) occurs because the converter does not bound the source length. Attacker-controlled UTF-32-like content delivered through SNMP printer supply-description parsing (backend/snmp-supplies.c) can cause CUPS to read past the allocated source buffer and disclose adjacent heap memory. Impact is limited to confidentiality (low); integrity and availability are not indicated by the scoring. Adjacent-network reachability, no privileges, and no user interaction are required.

Why it matters to the business

Print services using the affected Red Hat CUPS package may leak a small amount of process memory to an attacker on the same local/adjacent network, which could expose leftover heap data (for example fragments of job metadata or credentials if present in memory). Operational disruption is not expected. Exploit maturity is none, EPSS is very low (~0.0039 and flat over 30 days), and the issue is not in CISA KEV and is not associated with ransomware, so urgency is modest except where untrusted devices share the print/SNMP segment. Patch within normal cycle unless adjacent-network exposure to untrusted printers or SNMP is high.

How an attack unfolds

An unauthenticated attacker on an adjacent network influences SNMP content that CUPS's snmp-supplies backend treats as a printer supply description. When that description is transcoded, cupsUTF32ToUTF8() reads past the source buffer and returns or otherwise exposes nearby heap bytes. There are no public exploits, named threat actors, or KEV/ransomware associations. Practical abuse is local-segment information disclosure rather than remote code execution.

How to fix it

Upgrade the Red Hat cups-main package to the fixed build 2.4.19-4.1.hum1 (RHSA-2026:66600) or a later advisory build. Until patched, restrict which hosts can speak SNMP to printers and to CUPS (segment print VLANs, block untrusted SNMP 161/162, disable unused CUPS SNMP supply polling). Do not expose CUPS backends to untrusted adjacent devices.

How to confirm the fix worked

Confirm the installed cups-main RPM is 2.4.19-4.1.hum1 or newer (rpm -q cups / yum/dnf updateinfo for RHSA-2026:66600). Verify snmp-supplies/transcode packages match the patched build. After upgrade, restart CUPS and confirm the scheduler and SNMP backend start cleanly. Review that SNMP to printers is limited to trusted management networks. Do not use crafted SNMP payloads to re-trigger the OOB read.

Typical attack path

  1. Position on an adjacent network segment where CUPS performs SNMP supply queries (malicious/compromised printer, spoofed SNMP responder, or local MITM).
  2. Cause CUPS backend/snmp-supplies to ingest an attacker-controlled supply-description string.
  3. Trigger cupsUTF32ToUTF8() without a source-length bound so the process reads past the heap buffer.
  4. Observe or collect any leaked adjacent heap contents for reconnaissance.
  5. Use disclosed fragments only if they happen to contain sensitive residual data; no integrity or availability impact is implied.

How to detect it

This is a heap over-read with no public exploit, so confirmed historical compromise is unlikely and artifacts will be sparse. Review CUPS error logs and systemd journal around cupsd and the SNMP backend for unexpected faults, abort/segfault messages, or core dumps of the snmp backend after SNMP supply queries. Capture or retrospectively inspect local SNMP (UDP 161) toward printers, especially Printer-MIB supply-description responses that are oversized, truncated, or not valid text. Look for new devices answering as printers on the print VLAN. Absence of crashes does not prove the read was not triggered. Correlate any dump/crash time with SNMP from unknown sources.

  • /usr/lib/cups/backend/snmp
  • /usr/lib64/cups/backend/snmp
  • snmp-supplies
  • cupsUTF32ToUTF8
  • cupsd.*segfault
  • backend/snmp
  • /var/log/cups/error_log
  • udp/161
  • 1.3.6.1.2.1.43.11.1.1.6
  • prtMarkerSuppliesDescription

What your security team should do

  • Patch cups-main to 2.4.19-4.1.hum1 (RHSA-2026:66600) on all affected Red Hat systems as a standard, not emergency, change unless print/SNMP segments are untrusted.
  • Inventory hosts running CUPS with SNMP supply polling and isolate them from untrusted adjacent devices.
  • Restrict SNMP (UDP/TCP 161/162) to known printers and management stations; disable CUPS SNMP backends where unused.
  • Watch CUPS/journal crash and core-dump telemetry for the snmp backend, but treat active exploitation as unlikely given no known exploits and very low EPSS.
  • Reassess only if exploit code appears or EPSS/KEV status changes.

The record

The cupsUTF32ToUTF8() function in CUPS's cups/transcode.c lacks a source-length bound and can read past the end of the source buffer, resulting in a heap out-of-bounds read. This is reachable via SNMP supply-description parsing in backend/snmp-supplies.c with attacker-controlled content.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities