ZDI-26-655: PAPPL IPP Stack-Based Buffer Overflow — Local Privilege Escalation Detection and Remediation Guide

The Zero Day Initiative has published ZDI-26-655, a stack-based buffer overflow vulnerability in PAPPL — the open-source printer application framework originally authored by Michael Sweet (of CUPS fame) and now used as the foundation for modern IPP-based printer applications on Linux and other POSIX systems. The flaw carries a CVSS base score of 7.8 (High) and allows a local attacker who already has the ability to execute low-privileged code to escalate privileges on the affected host.

This is exactly the class of vulnerability that turns a low-value foothold into full system compromise. Print services are an attractive target for post-exploitation escalation for three reasons: they frequently run with elevated privileges or as a dedicated service account with broad file-system access, they are ubiquitously deployed and rarely inventoried, and — critically — many administrators don't even know PAPPL is present because it ships embedded inside printer applications (e.g., ipp-usb-adjacent stacks, vendor printer applications, and containerized print services) rather than as a standalone package they deliberately installed.

If you operate Linux print infrastructure, container images that bundle printer applications, or developer workstations with PAPPL-based tooling, this advisory belongs in this week's patch cycle — not next quarter's.

Technical Analysis

Affected Component

The vulnerability resides in PAPPL's IPP (Internet Printing Protocol) request processing code. PAPPL implements a full IPP server — it parses incoming IPP messages, which are binary-encoded attribute collections, and dispatches them to printer application callbacks. The flaw is a classic stack-based buffer overflow: insufficient bounds checking when processing attacker-influenced data during IPP message handling, allowing a crafted request to overwrite the stack, including saved return addresses.

Attack Chain (Defender's View)

1. Precondition: The attacker has already achieved low-privileged code execution on the target — via a phished user, a compromised web-facing service, a malicious package, or a shell obtained through a separate vulnerability. This is a local privilege escalation; it is not the initial access vector.
2. Trigger: The attacker sends a malformed IPP request to the locally reachable PAPPL service (typically listening on TCP port 631 or a Unix domain socket), or otherwise feeds crafted IPP data to the vulnerable parsing path.
3. Overflow: The vulnerable IPP processing routine copies attacker-controlled data into a fixed-size stack buffer without adequate length validation, corrupting the stack.
4. Escalation: Depending on mitigations in place (ASLR, stack canaries, NX), successful exploitation yields code execution in the context of the PAPPL process — frequently a privileged or dedicated service account — giving the attacker elevated rights on the host.

The ZDI advisory notes the attacker "must first obtain the ability to execute low-privileged code on the target system" — do not let that precondition lull you. Local privilege escalation is a mandatory stage of nearly every intrusion chain we respond to. Ransomware operators and APT actors alike chain exactly this type of bug after initial access to move from a user-context beacon to root/SYSTEM, disable EDR, and deploy payloads.

Severity

• Advisory: ZDI-26-655 (Zero Day Initiative coordinated disclosure)
• CVSS: 7.8 (High) — consistent with a local privilege escalation requiring no user interaction and no special conditions beyond local code execution
• Type: CWE-121 (Stack-based Buffer Overflow)
• Affected software: Installations of PAPPL (versions prior to the vendor fix referenced in the ZDI advisory). Because PAPPL is embedded in downstream printer applications, affectedness must be assessed per-application, not just per-package.

Exploitation Status

As of publication, there is no public proof-of-concept exploit and no confirmed in-the-wild exploitation, and the issue is not currently listed in the CISA Known Exploited Vulnerabilities catalog. The vulnerability was handled through ZDI's coordinated disclosure process. That said, stack-based overflows in well-documented parsing code are highly reverse-engineerable once a patch diff is available — the window between patch release and functional exploit for bugs like this is routinely measured in days. Treat the lack of observed exploitation as a head start, not reassurance.

Detection & Response

Exploitation of a stack-based overflow in a service daemon produces a recognizable set of observable behaviors: the service process crashing or restarting abnormally, the service spawning child processes it never legitimately spawns (shells, interpreters, downloaders), and anomalous local connections to the IPP listener from unexpected user contexts. Focus detection engineering on those behaviors rather than on payload signatures, which will vary per exploit.

SIGMA Rules

---
title: PAPPL or Printer Application Spawning Suspicious Child Processes
id: 8c2e4b71-5f3a-4d9e-b6c1-2a7f9e0d4b83
status: experimental
description: Detects PAPPL-based printer applications or related print services spawning shells, interpreters, or download utilities, consistent with post-exploitation activity following local privilege escalation via an IPP processing overflow such as ZDI-26-655.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-655/
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/pappl'
      - '/cupsd'
      - '/ipp-usb'
      - 'printer-app'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
  condition: selection_parent and selection_child
falsepositives:
  - Printer applications with legacy filter pipelines invoking shell wrappers
  - Vendor printer applications that shell out for driver helper scripts
level: high
---
title: Anomalous Crash of IPP Print Service Processes
id: 3f9a1c62-7b4d-4e8a-92f5-6d1c8a3e5b07
status: experimental
description: Detects repeated crashes or abnormal termination of PAPPL-based printer applications and CUPS-related processes, which may indicate exploitation attempts against the IPP processing stack-based buffer overflow described in ZDI-26-655.
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-655/
author: Security Arsenal
date: 2026/02/12
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/systemd-coredump'
      - '/apport'
      - '/abrt-hook-ccpp'
  selection_target:
    CommandLine|contains:
      - 'pappl'
      - 'cupsd'
      - 'printer-app'
  condition: selection and selection_target
falsepositives:
  - Legitimate service instability during upgrades or misconfiguration
level: medium

KQL — Microsoft Sentinel / Defender

For organizations ingesting Linux Syslog/CEF into Sentinel, hunt for print-service anomalies. The first query surfaces printer services spawning shells or interpreters; the second looks for service crash signals.

// Hunt 1: Print services spawning suspicious child processes (Linux Syslog via Sentinel)
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName has_any ("pappl", "cupsd", "printer-app")
    or SyslogMessage has_any ("pappl", "printer-app")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "python", "curl", "wget", "nc ", "socat")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc;

// Hunt 2: Segfaults / crashes in IPP print service processes (kernel messages via Syslog)
Syslog
| where TimeGenerated > ago(7d)
| where Facility == "kern" or ProcessName == "kernel"
| where SyslogMessage has_any ("segfault", "general protection fault")
| where SyslogMessage has_any ("pappl", "cupsd", "printer-app", "ipp")
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: For Defender for Endpoint onboarded Linux devices
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("pappl", "cupsd") or InitiatingProcessCommandLine has "printer-app"
| where FileName in~ ("sh", "bash", "dash", "python", "python3", "perl", "curl", "wget", "nc", "ncat", "socat")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc

Velociraptor VQL

Use this hunt artifact across Linux fleets to identify PAPPL-based processes, their privilege context, and any suspicious children — useful both for triage and for inventorying affected hosts ahead of patching.

-- Inventory PAPPL/IPP print service processes and flag suspicious children
LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()

SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
  IF(condition=Name =~ '(?i)(pappl|cupsd|printer-app)',
     then='PRINT_SERVICE', else='OTHER') AS ProcessClass
FROM procs
WHERE Name =~ '(?i)(pappl|cupsd|printer-app|ipp-usb)'
   OR Ppid IN (SELECT Pid FROM procs WHERE Name =~ '(?i)(pappl|cupsd|printer-app)')
ORDER BY CreateTime DESC

For network exposure assessment, pair it with a listener check to confirm which hosts expose IPP beyond localhost:

-- Identify IPP listeners (TCP 631) exposed beyond loopback
SELECT Pid, Name, Family, Type, Status,
  Laddr.IP AS LocalIP, Laddr.Port AS LocalPort
FROM netstat()
WHERE LocalPort = 631
  AND NOT LocalIP =~ '^(127\.|::1)'

Remediation & Verification Script

The following Bash script inventories PAPPL presence on a Linux host, identifies the owning package, checks whether the print service is listening beyond loopback, and applies package updates. Run it via your configuration management or EDR live-response channel across the fleet.

#!/usr/bin/env bash
# ZDI-26-655 triage & remediation helper — PAPPL IPP stack overflow
set -euo pipefail

echo "=== [1] Locate PAPPL libraries and printer applications ==="
ldconfig -p 2>/dev/null | grep -i pappl || echo "No libpappl in linker cache"
find /usr /opt /snap -iname '*pappl*' -o -iname '*printer-app*' 2>/dev/null | head -50

echo "=== [2] Identify owning package (Debian/RPM) ==="
if command -v dpkg >/dev/null 2>&1; then
  dpkg -l | grep -iE 'pappl|cups|printer-application' || true
fi
if command -v rpm >/dev/null 2>&1; then
  rpm -qa | grep -iE 'pappl|cups|printer' || true
fi

echo "=== [3] Check for IPP listeners exposed beyond localhost (port 631) ==="
ss -tlnp 2>/dev/null | grep ':631' || echo "No TCP 631 listener found"

echo "=== [4] Check for PAPPL-related core dumps (possible exploitation attempts) ==="
if command -v coredumpctl >/dev/null 2>&1; then
  coredumpctl list --no-pager 2>/dev/null | grep -iE 'pappl|cupsd|printer-app' || echo "No related core dumps"
fi

echo "=== [5] Apply updates ==="
if command -v apt-get >/dev/null 2>&1; then
  apt-get update -qq && apt-get upgrade -y
elif command -v dnf >/dev/null 2>&1; then
  dnf update -y
elif command -v zypper >/dev/null 2>&1; then
  zypper --non-interactive update
fi

echo "=== [6] Hardening: bind print services to loopback if network printing is not required ==="
echo "Manually review service config (e.g., /etc/cups/cupsd.conf 'Listen localhost:631')"
echo "and container image ENTRYPOINT arguments for PAPPL-based printer applications."

echo "=== Done. Reboot or restart affected printer applications to load patched libraries. ==="

Remediation

1. Patch immediately. Apply the PAPPL update referenced in the ZDI-26-655 advisory and track fixes in the upstream PAPPL project repository (github.com/OpenPrinting/pappl). Because PAPPL is frequently vendored into downstream printer applications and container images, confirm that each dependent application has shipped an updated build — updating the OS package alone is not sufficient if a container image embeds a static copy.

2. Inventory first — you cannot patch what you haven't found. Scan your Linux estate and container registries for libpappl and PAPPL-derived printer applications. Pay particular attention to print servers, developer workstations, and IoT/embedded print gateways, which are chronically under-inventoried.

3. Reduce the attack surface. If network printing is not required, restrict IPP listeners to loopback (Listen localhost:631) or the Unix domain socket only. Where network printing is required, restrict access to port 631 via host firewall rules to known print-client subnets and enforce IPP authentication policies.

4. Run print services with least privilege. Ensure printer applications run under dedicated, unprivileged service accounts with systemd hardening directives (ProtectSystem=strict, ProtectHome=true, NoNewPrivileges=true, PrivateTmp=true). A successful overflow in a confined, unprivileged service context dramatically limits post-exploitation value. Verify that kernel and compiler mitigations (ASLR, stack canaries, NX) are enabled on affected builds.

5. Hunt for prior exploitation attempts. Because exploitation requires a pre-existing foothold, any crash artifacts in PAPPL-related processes are a signal worth investigating — review core dumps and segfault logs on print infrastructure for the past 90 days, and treat repeated service crashes on internet-adjacent hosts as a potential indicator of active probing.

6. Update your vulnerability management backlog. Local privilege escalations are frequently deprioritized against remote code execution flaws. Resist that instinct here: an LPE in a ubiquitously deployed parsing library is a force multiplier for every other vulnerability in your environment. SLA this within your standard High-severity patch window (typically 14 days or less per most CIS/NIST-aligned programs).

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub