CVE-2026-64669 · Package
NO FIX YET · SEE WHAT TO DO
pam_usb's deny_remote setting is meant to block hardware-key login when the user has a remote tmux session, but its IPv6 parser only recognizes fully written addresses. A remote tmux client connecting from a compressed IPv6 address such as ::1 or 2001:db8::1 goes undetected, so the check reports no remote clients.
first public Jul 2, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Only systems running pam_usb from 0.8.0 up to but not including 0.9.3 with deny_remote enabled are exposed. The flaw matters where users reach tmux over IPv6 and the deny_remote rule is relied on to block hardware-key logins from remote sessions. Systems without deny_remote, or without IPv6 remote tmux clients, are not affected.
Not affected if default-config, pam-usb-0.9.3-or-later, pam-usb-below-0.8.0
Who cares ipv6, linux, pam, pam-usb, tmux
0.8.0 and 0.9.3.deny_remote enabled in the pam_usb configuration (/etc/security/pam_usb.conf).0.9.3 or later.pam_usb provides hardware authentication for Linux using removable media. From version 0.8.0 to before version 0.9.3, the deny_remote feature in pam_usb uses /usr/bin/w -i to detect whether the authenticating user has an active remote tmux session. In pusb_tmux_has_remote_clients() (src/tmux.c), the IPv6 detection regex required exactly four explicit colon-separated groups of 1-4 hex digits (e.g. 2001:0db8:85a3:0000). Any IPv6 address in compressed notation — including loopback (::1), link-local (fe80::1), and global unicast addresses (2001:db8::1) — did not match this pattern. As a result the remote-client check silently returned "no remote clients" even when a remote tmux client was connected from such an address. This issue has been patched in version 0.9.3.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.