What is the CVSS score of CVE-2026-47269?

CVE-2026-47269 has a CVSS 3.1 base score of 7.4 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of pam_usb are affected by CVE-2026-47269?

pam_usb versions before 0.9.0 contain an authentication bypass allowing users with enrolled USB tokens to gain remote SSH access when security controls should restrict access to local connections…. A patch is available.

How to fix or mitigate CVE-2026-47269?

Within 24 hours: Identify all systems using pam_usb and verify versions; review SSH audit logs for remote authentication from USB token users; inventory USB token holders and assess access levels. Within 7 days: Implement firewall rules restricting SSH to trusted network segments only; add secondary authentication (certificates, RADIUS/LDAP) for systems requiring remote SSH access; consider disabling remote SSH entirely if not operationally critical. Within 30 days: Evaluate replacement authentication solutions (centralized identity/access management platforms); establish certificate-based SSH authentication as organizational standard; implement comprehensive SSH connection monitoring and alerting for policy violations.

pam_usb CVE-2026-47269

EUVD-2026-32656 HIGH

Improper Access Control (CWE-284)

2026-05-27 security-advisories@github.com

Debian Authentication Bypass Ubuntu

7.4

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.4 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

May 27, 2026 - 22:04 EUVD

Source Code Evidence Fetched

May 27, 2026 - 21:31 vuln.today

Analysis Generated

May 27, 2026 - 21:31 vuln.today

CVE Published

May 27, 2026 - 21:16 nvd

HIGH 7.4

DescriptionGitHub Advisory

pam_usb provides hardware authentication for Linux using ordinary removable media. Prior to 0.9.0, pam_usb's deny_remote feature checks utmpx ut_addr_v6 to detect whether an authentication request originates from a remote session. The outer guard was if (utent->ut_addr_v6[0] != 0), which only tests the first 32-bit word of the 128-bit address field. IPv4-mapped IPv6 addresses (::ffff:x.x.x.x) store the IPv4 address in ut_addr_v6[3] with ut_addr_v6[0] == 0. On systems where the SSH daemon listens on :: (IPv6 wildcard) with AddressFamily any -- common on Ubuntu and Debian -- incoming IPv4 connections are recorded in utmpx as IPv4-mapped IPv6 addresses. The outer check evaluates to false, the remote-detection block is skipped entirely, and the session is treated as local. deny_remote=true does not block the authentication. An attacker with physical access to a registered USB device can authenticate over SSH on an affected system as if they were sitting at a local terminal, bypassing the deny_remote restriction. This vulnerability is fixed in 0.9.0.

AnalysisAI

Authentication-context bypass in pam_usb before 0.9.0 lets a person holding an enrolled USB device authenticate over SSH while the module's deny_remote protection wrongly classifies the connection as a local terminal session. The root cause is an incomplete check of the utmpx ut_addr_v6 field that misreads IPv4-mapped IPv6 addresses (::ffff:x.x.x.x) as having no remote address, which is the normal way Debian and Ubuntu record incoming IPv4 SSH connections when sshd listens on the IPv6 wildcard. There is no public exploit identified at time of analysis and the CVE is not in CISA KEV, but the operation needed to trigger it is trivial once the operator possesses a registered token.

Technical ContextAI

pam_usb is a PAM module that authenticates Linux users by the presence of a registered removable USB device, with an optional deny_remote setting intended to refuse such hardware-only logins for non-local sessions. To decide whether a session is remote, pusb_is_tty_local() in src/local.c inspects the utmpx record's ut_addr_v6, a 128-bit field holding the peer address as four 32-bit words. The guard was written as if (utent->ut_addr_v6[0] != 0), examining only the first word; this works for native IPv4 (stored in word 0) and most native IPv6, but fails for IPv4-mapped IPv6 addresses where the IPv4 octets land in ut_addr_v6[3] and word 0 is zero. When OpenSSH runs with AddressFamily any and binds to :: (the default on Debian/Ubuntu), inbound IPv4 connections are logged to utmpx in this mapped form, so the guard returns false and the entire remote-detection branch is skipped. This is an access-control flaw (CWE-284, Improper Access Control): the security decision relies on a non-robust parse of the address structure. The 0.9.0 fix tests all four words (ut_addr_v6[0] || [1] || [2] || [3]) so any non-zero address word marks the session remote.

RemediationAI

Vendor-released patch: 0.9.0 - upgrade pam_usb to 0.9.0 or later, which corrects pusb_is_tty_local() to check all four words of ut_addr_v6 (fix commit https://github.com/mcdope/pam_usb/commit/804fe24eae3d742d8be05fd015e36abc3c7d94e5; advisory https://github.com/mcdope/pam_usb/security/advisories/GHSA-jmmj-qhrq-w45g). If you cannot upgrade immediately, a targeted compensating control is to stop incoming IPv4 connections from being recorded as IPv4-mapped IPv6: set AddressFamily inet in sshd_config (or bind sshd to explicit IPv4 ListenAddress entries) so IPv4 sessions are logged in ut_addr_v6[0] and correctly detected as remote - the trade-off is loss of native IPv6 SSH connectivity on that host. Alternatively, restrict or disable remote SSH access to systems relying on pam_usb (for example, limit sshd exposure with firewall rules or move the USB factor behind a non-network login path) so the deny_remote gap cannot be reached; this reduces convenience and remote administration capability. Do not rely on deny_remote alone on vulnerable versions, as it does not block the authentication in this scenario.