CVE-2026-41079

What it actually does

This is a low-severity information disclosure flaw in the CUPS SNMP backend before version 2.4.17. A network-adjacent attacker can send a malformed SNMP response that causes CUPS to read up to 176 bytes beyond a stack buffer. The leaked bytes are converted from UTF-16 to UTF-8 and stored as printer supply description attributes, which can later be viewed by authenticated users through IPP Get-Printer-Attributes responses or the CUPS web interface. The flaw does not provide code execution, privilege escalation, data modification, or service disruption by itself.

Why it matters to the business

Systems using CUPS with SNMP printer discovery or monitoring enabled may unintentionally expose small fragments of process memory to authenticated users. While the disclosed data volume is limited and exploitation currently has low likelihood based on EPSS and no known KEV listing, the affected software is widely deployed on Linux and Unix-like systems, so organizations should treat this as a routine but broad hygiene update. The main operational risk is accidental disclosure of sensitive in-memory data, such as configuration fragments, printer metadata, nearby memory contents, or other transient process data, depending on what is present in the CUPS process at the time of exploitation.

How an attack unfolds

An attacker must be positioned on the same local or adjacent network path as the CUPS host or printer discovery traffic. The attacker waits for or induces CUPS SNMP backend activity, then sends a crafted SNMP response containing malformed data that triggers an out-of-bounds read in the backend parser. CUPS copies the over-read memory into printer supply description fields after character-set conversion. The attacker, or another authenticated user with access to printer attributes, can then retrieve the leaked values through IPP Get-Printer-Attributes or the CUPS web interface. Because the vulnerability requires network adjacency and only leaks a small amount of memory, exploitation is most relevant in shared networks, print VLANs, campus environments, and environments where untrusted devices can respond to SNMP discovery traffic.

How to fix it

Upgrade OpenPrinting CUPS to version 2.4.17 or later wherever CUPS is installed. If vendor-packaged CUPS is used, apply the distribution security update that backports the fix, even if the displayed upstream version remains below 2.4.17. Where immediate patching is not possible, reduce exposure by disabling unused CUPS printer discovery and SNMP backend functionality, restricting access to UDP/161 responses from trusted printer devices only, segmenting print networks, and limiting authenticated access to the CUPS web interface and IPP printer attributes. Avoid allowing untrusted hosts on the same broadcast domain or print VLAN as CUPS servers.

How to confirm the fix worked

Confirm that the installed CUPS package includes the vendor fix for this issue or reports OpenPrinting CUPS 2.4.17 or later. On Linux systems, validate with package-manager queries and, where appropriate, `cupsd -v` or distribution package changelogs. Review whether the SNMP backend is present and used, commonly at `/usr/lib/cups/backend/snmp` or `/usr/libexec/cups/backend/snmp`. Confirm that CUPS web administration and IPP endpoints are restricted to expected users and networks. Validate network controls by confirming that only trusted printer devices can exchange SNMP traffic with CUPS hosts and that untrusted local systems cannot spoof or inject SNMP responses.

Typical attack path

1. Gain access to the same local network segment, print VLAN, or adjacent network path as a CUPS server using the SNMP backend.
2. Observe or trigger CUPS SNMP printer discovery or printer status polling activity.
3. Send a crafted SNMP response to the CUPS SNMP backend.
4. Cause CUPS to read a small amount of memory beyond a stack buffer and store the result as printer supply description data.
5. Authenticate to CUPS or IPP with an account permitted to view printer attributes.
6. Retrieve the leaked data through IPP Get-Printer-Attributes responses or the CUPS web interface.
7. Repeat attempts to collect additional small memory fragments, subject to network position and CUPS polling behavior.

How to detect it

There are no universally reliable exploitation indicators because the vulnerability leaks small memory fragments through normal-looking printer attributes. Detection should focus on correlating suspicious SNMP activity with subsequent printer attribute retrieval. Review CUPS logs such as `/var/log/cups/error_log`, `/var/log/cups/access_log`, and system journal entries for SNMP backend activity, unusual printer discovery events, and repeated IPP Get-Printer-Attributes requests. Inspect CUPS web access logs for repeated access to printer pages after SNMP polling. Network telemetry should be reviewed for unexpected UDP/161 responses to CUPS hosts, SNMP packets from non-printer systems, or traffic from hosts not in the approved printer inventory. Forensic review can include checking printer supply description or marker-related attributes for garbled UTF-8, replacement characters, unexpected binary-looking strings, or values that do not match real printer consumable descriptions. Treat findings as suspicious when abnormal SNMP responses, CUPS backend execution, and attribute reads occur close together in time.

• /var/log/cups/error_log
• /var/log/cups/access_log
• /usr/lib/cups/backend/snmp
• /usr/libexec/cups/backend/snmp
• backend/snmp
• Get-Printer-Attributes
• printer-supply-description
• marker-names
• marker-types
• marker-levels
• GET /printers/
• POST /printers/
• UDP/161
• SNMP

What your security team should do

• Prioritize patching CUPS to 2.4.17 or a vendor-fixed package on systems that use network printers, SNMP discovery, shared print services, or are located on networks with untrusted clients.
• Inventory Linux and Unix-like systems running CUPS, including desktops, print servers, appliances, and embedded administrative hosts.
• Restrict CUPS/IPP and CUPS web interface access to trusted users and management networks only.
• Limit SNMP traffic between CUPS hosts and known printer IP addresses; block or monitor unexpected UDP/161 traffic on print VLANs.
• Disable CUPS SNMP discovery/backend functionality where it is not operationally required.
• Review CUPS access and error logs for unusual printer attribute enumeration, especially repeated IPP Get-Printer-Attributes requests after SNMP activity.
• Because this is not currently listed in KEV, has no reported exploit maturity, and has a low stable EPSS score, handle as routine vulnerability management unless local exposure includes untrusted adjacent networks.