CVE-2026-19910 / CVE-2026-19911: PAX Q80 Signature Verification Bypass — Zero-Day Detection and Mitigation Guide

On the 2026 disclosure calendar, few advisories deserve faster attention from retail and hospitality security teams than ZDI-26-526. The Zero Day Initiative has published details of a signature verification bypass in the PAX Technology Q80 — a widely deployed Android-based SmartPOS payment terminal — that allows a network-adjacent attacker to execute arbitrary code with no authentication. Two CVEs have been assigned: CVE-2026-19910 and CVE-2026-19911, carrying a combined ZDI CVSS rating of 7.5.

There is no patch. This is an unpatched vulnerability published through ZDI's coordinated disclosure process, which means the technical details are now public while the vendor fix is not. That gap is your exposure window, and for any organization processing card-present transactions on Q80 hardware, that window sits directly adjacent to your cardholder data environment (CDE).

I've led incident response engagements where compromised payment terminals became the persistence layer for card-skimming operations that ran undetected for months. The pattern is always the same: weak or absent network segmentation, no egress monitoring on POS VLANs, and devices treated as appliances rather than the general-purpose Android computers they actually are. This advisory is your trigger to fix all three before someone else's exploit does it for you.

Technical Analysis

Affected Products and Components

• Product: PAX Technology Q80 SmartPOS terminal (Android-based countertop payment device)
• Affected component: The Application Installer subsystem — the component responsible for validating and installing application packages (APKs) on the device
• Advisory: ZDI-26-526
• CVEs: CVE-2026-19910, CVE-2026-19911
• CVSS: 7.5 (ZDI assessment)

How the Vulnerability Works

The flaw is a signature verification bypass in the Q80's application installation path. PAX terminals enforce a trust model in which only applications signed by PAX or an authorized party should be installable on the device. This signature check is the primary control standing between a payment terminal and arbitrary third-party code.

Per the advisory, the installer fails to properly validate package signatures under specific conditions, allowing an attacker positioned on the same network segment as the terminal to deliver a malicious application package that the device accepts and executes. Key characteristics from a defender's perspective:

1. No authentication required. The attacker does not need credentials, a valid session, or physical access to the device.
2. Network adjacency is the only prerequisite. "Adjacent" in CVSS terms means the attacker must share a broadcast domain or logically adjacent network with the target — which is exactly the situation on flat retail LANs, poorly segmented store networks, compromised store Wi-Fi, or any environment where a POS VLAN is reachable from guest networks, corporate workstations, or an attacker's rogue device plugged into an open port.
3. Code execution on a trusted payment device. Once arbitrary code runs on the terminal, the attacker inherits whatever the installer/service context permits — on Android-based POS hardware this typically means the ability to deploy a persistent malicious application capable of intercepting payment flows, scraping track data or PIN pad interactions at the application layer, beaconing out to attacker infrastructure, or pivoting further into the CDE.

The exploitation chain a defender should model is: attacker gains adjacent network position → delivers malicious package to the installer's listening interface → signature check is bypassed → malicious APK installs and executes → persistence and data theft or lateral movement.

Exploitation Status

• Patch status: Unpatched as of publication. No vendor firmware fix is currently available.
• Public PoC / in-the-wild exploitation: No confirmed active exploitation has been reported at the time of writing. However, ZDI publication means technical details are now in the hands of every researcher and offensive operator who reads advisories — historically, the window between public advisory and weaponization for network-adjacent flaws on embedded devices is measured in weeks, not months.
• CISA KEV: Not listed as of this writing. Do not wait for a KEV listing to act; KEV inclusion typically follows observed exploitation, which is precisely the outcome you're trying to preclude.
• PCI DSS context: For QSA-scoped environments, an unpatched, network-exploitable code execution flaw on in-scope payment hardware is a direct problem for Requirements 6.2/6.3 (vulnerability remediation) and 11.3 (penetration testing). Compensating controls need to be documented now, not at your next assessment.

Detection & Response

The Q80 is an embedded Android device — your detection surface is primarily the network around the terminal and the Windows management hosts (store servers, estate management workstations) that legitimately interact with it. The detections below target the behaviors that exploitation requires: unexpected processes pushing packages to devices, unauthorized hosts communicating with terminals on management/debug interfaces, and package-install activity originating from non-management infrastructure.

Sigma Rules

---
title: Suspicious Package Deployment to Android POS Devices via ADB
description: Detects use of Android Debug Bridge to install or push application packages, which may indicate malicious APK delivery to Android-based payment terminals such as PAX Q80. Legitimate only from authorized terminal management workstations.
logsource:
  category: process_creation
  product: windows
detection:
  selection_tool:
    Image|endswith:
      - '\adb.exe'
      - '\fastboot.exe'
  selection_action:
    CommandLine|contains:
      - ' install '
      - ' push '
      - ' shell pm install'
      - ' sideload '
  condition: selection_tool and selection_action
falsepositives:
  - Authorized PAX terminal management and staging tools on dedicated estate management hosts
  - MDM/terminal estate tooling wrapping ADB for legitimate app updates
level: high
---
title: Package Installer Activity With Signature Bypass Flags
description: Detects Android package manager invocations that bypass or downgrade signature verification, consistent with exploitation of installer signature validation flaws such as CVE-2026-19910 and CVE-2026-19911.
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine|contains:
      - 'pm install'
  selection_bypass:
    CommandLine|contains:
      - '--dont-kill'
      - '-d '
      - '--bypass-low-target-sdk-block'
      - 'INSTALL_REPLACE_EXISTING'
      - '--force-queryable'
  condition: all of selection_*
falsepositives:
  - Rare; legitimate app staging on POS hardware should use signed packages through vendor tooling, not raw pm install with downgrade flags
level: high
---
title: Network Connection From Non-Management Host to POS Debug Interface
description: Detects connections to TCP 5555 (ADB) or common terminal management ports originating from hosts or processes that should never interact with payment terminal debug interfaces.
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 5555
      - 5037
  filter_known_tools:
    Image|endswith:
      - '\adb.exe'
  condition: selection and not filter_known_tools
falsepositives:
  - Custom terminal management agents from the POS vendor — baseline your estate and whitelist the exact management binary paths
level: medium

Tune the third rule by replacing the port list with your actual PAX estate management ports (confirm with your PAX integrator documentation), and whitelist only the exact, full paths of authorized management binaries. A medium-severity rule that fires once a month is worth more than a critical rule disabled after a week.

KQL — Microsoft Sentinel / Defender

This query hunts for any device communicating with your POS estate on ADB or terminal management ports where that source is not an authorized management host. It assumes you have POS VLANs or terminal IP ranges defined — if you can't enumerate your terminal IP range in under five minutes, that is itself a finding.

// Hunt: Unauthorized hosts communicating with PAX POS terminals on management/debug ports
// Update the POS subnet and authorized management host list for your environment
let PosSubnet = "10.40.0.0/16";                       // <-- your POS/terminal VLAN range
let AuthorizedMgmtHosts = dynamic(["POS-MGMT-01", "POS-MGMT-02"]);  // <-- approved estate management hosts
let TermPorts = dynamic([5555, 5037]);                // ADB; add your PAX TMS/estate ports
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteIP startswith "10.40."                   // matches PosSubnet; refine as needed
| where RemotePort in (TermPorts)
| where DeviceName !in~ (AuthorizedMgmtHosts)
| where InitiatingProcessFileName !in~ ("adb.exe")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            ConnectionCount = count(),
            Ports = make_set(RemotePort),
            TargetDevices = make_set(RemoteIP, 50)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, LocalIP
| order by ConnectionCount desc

For environments ingesting firewall/syslog telemetry rather than Defender data, pivot the same logic onto CommonSecurityLog using DestinationIP/DestinationPort and your store firewall as the reporting device — the detection concept (non-management source → terminal management port) is identical.

Velociraptor VQL

Use this artifact across store servers and back-office workstations to find any live or historical process execution and network state consistent with package delivery to terminals:

-- Hunt: Processes and network connections consistent with unauthorized
-- package deployment to Android POS terminals (PAX Q80 / ZDI-26-526)
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(adb\s+(install|push|sideload)|pm\s+install|fastboot)'
   OR Exe =~ '(?i)\\(adb|fastboot)\.exe$'

-- Complementary: live connections to ADB/terminal management ports
SELECT Pid, Name, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE RemotePort IN (5555, 5037)
   AND Status =~ 'ESTABLISHED'

Hardening / Verification Script

Until PAX ships a fixed firmware, segmentation is your compensating control. This Bash script audits that only authorized management hosts can reach your terminal estate on management ports, and flags anything unexpected. Run it from a Linux jump host with firewall visibility, or adapt the rule-audit portion for your firewall management API.

#!/bin/bash
# ZDI-26-526 compensating-control audit for PAX Q80 estates
# Verifies: (1) terminal VLAN is isolated, (2) only authorized mgmt hosts can
# reach terminal management ports, (3) terminals have no outbound internet path.
set -euo pipefail

POS_SUBNET="10.40.0.0/16"          # <-- your POS terminal range
MGMT_HOSTS="10.10.5.11 10.10.5.12" # <-- authorized estate management hosts
WATCH_PORTS="5555 5037"            # ADB; add PAX TMS ports per integrator docs

echo "[+] Enumerating live terminals on ${POS_SUBNET}"
nmap -sn "${POS_SUBNET}" -oG - | awk '/Up$/{print $2}' > /tmp/pos_live.txt
wc -l /tmp/pos_live.txt

echo "[+] Scanning for exposed management/debug interfaces on terminals"
nmap -sS -p "$(echo ${WATCH_PORTS} | tr ' ' ',')" --open -iL /tmp/pos_live.txt -oG - \
  | awk '/open/{print $2, $0}' > /tmp/pos_exposed.txt
cat /tmp/pos_exposed.txt

echo "[+] Checking iptables OUTPUT path from POS segment (run on POS gateway/firewall)"
# On the gateway: terminals must NOT reach the internet or corporate LAN directly
iptables -L FORWARD -n -v | grep -E "${POS_SUBNET%%/*}" || \
  echo "[!] WARNING: no FORWARD rules reference the POS subnet — segmentation may be absent"

echo "[+] Verifying only authorized management sources are permitted"
for h in ${MGMT_HOSTS}; do
  iptables -C FORWARD -s "${h}" -d "${POS_SUBNET}" -p tcp -m multiport --dports "$(echo ${WATCH_PORTS} | tr ' ' ',')" -j ACCEPT 2>/dev/null \
    && echo "  OK: ${h} permitted to POS mgmt ports" \
    || echo "  MISSING: ${h} has no explicit allow rule"
done
iptables -C FORWARD -d "${POS_SUBNET}" -p tcp -m multiport --dports "$(echo ${WATCH_PORTS} | tr ' ' ',')" -j DROP 2>/dev/null \
  && echo "  OK: default DROP for all other sources to POS mgmt ports" \
  || echo "[!] MISSING: add default DROP — e.g.: iptables -A FORWARD -d ${POS_SUBNET} -p tcp -m multiport --dports 5555,5037 -j DROP"

echo "[+] Done. Review /tmp/pos_exposed.txt — every open 5555/5037 listener is attack surface."

Remediation

Primary remediation — vendor patch: As of this writing, PAX Technology has not released fixed firmware. Engage your PAX account team, acquirer, or terminal management provider immediately and demand: (1) confirmation of which Q80 firmware builds are affected, (2) the patch ETA, and (3) any vendor-endorsed mitigation or configuration that closes the exposed installer interface. Track against CVE-2026-19910 and CVE-2026-19911 in your vulnerability management platform with an exception/compensating-control record, not a silent deferral.

Official references:

• ZDI advisory: http://www.zerodayinitiative.com/advisories/ZDI-26-526/
• Monitor PAX Technology's support and partner portals for the firmware release addressing these CVEs.

Compensating controls (do these this week):

1. Hard-segment the POS estate. Terminals should live on a dedicated VLAN with no route to guest Wi-Fi, corporate user subnets, or the internet. Since exploitation requires network adjacency, eliminating adjacency eliminates the attack vector. This is the single highest-value action available until a patch exists.
2. Enforce management-port ACLs. Only named estate management hosts should be able to reach terminals on ADB (5555/5037) and any PAX terminal management ports. Default-deny everything else, and log the denies — a denied connection to a terminal on port 5555 is a high-fidelity alert.
3. Egress filtering on the POS VLAN. Terminals should only reach required acquirer/processor endpoints and the vendor's terminal management infrastructure. Block everything else and alert on it. Post-exploitation, an attacker needs a C2 channel; don't give them one.
4. Physical and port security in stores. Lock down open ethernet ports and cabling in customer-accessible areas; enable 802.1X or at minimum MAC-based port control on store switches. "Network adjacent" often starts with an open wall jack behind a checkout counter.
5. Detect now, patch when available. Deploy the detections above, baseline which hosts legitimately touch your terminals, and treat any deviation as an incident until triaged.
6. PCI DSS documentation. Record this vulnerability and your compensating controls formally. Your QSA will ask; more importantly, if a card data compromise later traces to this flaw, your documented response timeline matters.

When the patch ships: treat deployment as an emergency change. Validate the firmware signature through PAX's official distribution channel (an installer signature bug makes supply-chain integrity of the fix itself worth verifying), stage against a test terminal, and roll out estate-wide with completion tracking. Verify post-patch that the exposed installer interface is no longer reachable or no longer accepts unsigned packages.

Related Resources

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