OpenPrinting CUPS CVE-2026-41079

CUPS must have SNMP backend enabled and configured for network printer discovery (default in typical installations). The attacker must have network-adjacent access to the CUPS server or the network segment where CUPS can receive SNMP responses; this is narrower than arbitrary network access but includes local networks, adjacent subnets, or any network where SNMP traffic can reach the CUPS daemon. The SNMP backend must be active and listening for SNMP responses from printers. No special CUPS configuration changes are required to trigger the vulnerability-standard default configurations are vulnerable. The leaked memory is only visible to authenticated IPP users, so attackers cannot directly see the exfiltrated data but can observe it indirectly if they have or can obtain authenticated access to the CUPS interface. Non-default configurations (SNMP backend explicitly disabled, or firewall blocking SNMP) prevent exploitation.

CVSS vector (AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) indicates network-adjacent attack vector with low complexity and no privilege requirements, but scope is unchanged and impact is limited to confidentiality (small - 176 byte leak). EPSS data not provided; however, the real-world risk is constrained by three factors: (1) attacker must be network-adjacent, not just network-reachable, limiting scope to local networks; (2) the information leaked is non-deterministic memory from the stack, likely containing only transient data or CUPS internal structures rather than sensitive credentials; (3) leaked data is only visible to authenticated IPP users, not anonymous attackers. This is a genuine information disclosure but the practical attack surface is narrow. Organizations with CUPS printers on isolated management networks face minimal risk; those with network printers accessible from guest/untrusted networks should prioritize patching. No active exploitation reported, but the low barrier to exploitation (crafted SNMP response) means patch deployment remains necessary.

An attacker on the same network segment as a CUPS server (or within network-adjacent range) crafts a malicious SNMP response packet with oversized or specially formatted fields and sends it to the CUPS SNMP backend port. When CUPS parses the response, the UTF-16 to UTF-8 conversion logic fails to properly validate buffer boundaries, reading 176 bytes past the intended buffer on the stack. An authenticated user subsequently requests printer attributes via IPP (e.g., using 'lpstat' or the CUPS web interface), and the leaked stack memory-now stored as printer supply description strings-is returned in the response, exposing the attacker's exfiltrated data.