CVE-2026-3184

What it actually does

The flaw is an authorization bypass in util-linux login(1) hostname handling. When login is invoked with the -h option, it may canonicalize or alter the attacker-supplied remote hostname before assigning it to PAM_RHOST. PAM modules and access-control configurations that make allow/deny decisions based on fully qualified domain names may therefore evaluate a different hostname than the one originally supplied by the remote login path. In deployments where host-based PAM rules trust particular hostnames or domains, a crafted hostname could cause PAM policy checks to match an unintended trusted pattern, allowing authentication or access decisions that should have been denied. The CVSS score is low-to-moderate because exploitation depends on a specific login invocation pattern and vulnerable PAM hostname-based policy usage, but the impact can still be meaningful where host-based access controls are relied upon.

Why it matters to the business

Systems that rely on hostname-based PAM access rules may allow logins from hosts that should not be trusted, weakening administrative access boundaries on Linux systems and hardened images. The issue is most relevant for servers, appliances, container/base images, or remote-access paths that invoke util-linux login with the -h option and enforce access using fully qualified domain names. Although public exploitation is not currently reported, EPSS is low and stable, and it is not listed in CISA KEV or ransomware exploitation data, affected organizations should still remediate because the flaw can undermine a core access-control assumption and may be difficult to notice in normal authentication logs.

How an attack unfolds

An attacker first identifies a reachable service or login flow that passes a remote hostname to util-linux login(1) using the -h option. They then study or infer the target’s host-based PAM access rules, such as pam_access or related controls that permit or deny authentication based on PAM_RHOST values and trusted fully qualified domain names. The attacker supplies a specially crafted hostname that is transformed during login’s hostname canonicalization. Because PAM_RHOST is populated after this transformation, PAM evaluates the modified hostname rather than the original supplied hostname. If the transformed value matches an allowed hostname or domain rule, the attacker may bypass the intended host restriction and proceed with access that should have been blocked by policy. Successful exploitation still typically requires that the target use affected util-linux behavior, that the login path accept attacker-controlled hostname input, and that PAM policy depend on hostname or FQDN matching.

How to fix it

Upgrade util-linux packages to vendor-provided fixed versions as soon as they are available for the affected distribution or image. No specific fixed version was provided in the input, so track the relevant Linux distribution advisories for kernel util-linux and any redhat hardened images, then rebuild or redeploy images after updating the package. As a mitigation, avoid relying solely on hostname or FQDN-based PAM access rules for security-sensitive decisions; prefer IP/CIDR-based controls, cryptographic host identity, network-layer allowlists, strong authentication, and centralized access policy where possible. Review PAM configurations such as pam_access, pam_listfile, or custom PAM modules that consume PAM_RHOST. Where feasible, disable or restrict remote login flows that pass attacker-controlled values to login -h, and ensure reverse DNS or hostname-derived access decisions are not treated as authoritative trust signals.

How to confirm the fix worked

Confirm exposure by checking installed util-linux package versions against the distribution’s security advisory for this vulnerability. Validate whether /bin/login or /usr/bin/login comes from the affected util-linux build and whether any remote access service invokes login with the -h option. Review PAM policy under /etc/pam.d/ and access-control files such as /etc/security/access.conf for rules that depend on hostnames, domains, or PAM_RHOST-derived values. After patching, verify that the util-linux package is updated in both running hosts and golden/container images, then test a representative remote login attempt using previously problematic crafted hostname forms to confirm that PAM no longer receives a canonicalized value that bypasses policy. Also confirm that rebuilt hardened images no longer contain the vulnerable package version.

Typical attack path

1. Identify Linux systems or images using vulnerable util-linux login(1).
2. Find a remote login path that invokes login with the -h option and accepts or propagates a remote hostname value.
3. Determine whether PAM access controls use PAM_RHOST, hostnames, or fully qualified domain names for allow/deny decisions.
4. Craft a hostname that is changed by login hostname canonicalization into a value matching a trusted PAM rule.
5. Attempt authentication through the affected login path using the crafted hostname.
6. If PAM host-based controls are bypassed, continue with interactive access or subsequent privilege/use-case actions permitted to the authenticated account.

How to detect it

Detection should focus on authentication and PAM telemetry rather than malware artifacts. Review /var/log/auth.log, /var/log/secure, journalctl output for login, sshd, telnet, rlogin, getty, or other services that may invoke login, and PAM module logs around successful or failed authentication. Look for remote host values containing unusual hostname syntax, repeated dots, trailing dots, mixed-case or overlong labels, embedded domain suffix tricks, short names that unexpectedly resolve to trusted fully qualified names, or discrepancies between source IP addresses and logged remote hostnames. Compare successful logins against PAM host-based policy to identify sessions that originated from IP ranges or hosts that should not have been allowed. If centralized authentication logs are available, correlate PAM_RHOST or remote-host fields with DNS records and network connection metadata. There are no public threat actors or campaigns tied to this issue in the provided data, so detections should be behavior- and configuration-focused.

• login -h
• PAM_RHOST
• pam_access
• /etc/security/access.conf
• /etc/pam.d/login
• /var/log/auth.log
• /var/log/secure
• journalctl -u sshd
• journalctl -t login
• authentication failure
• session opened for user
• PAM: access denied
• pam_access(login:account)

What your security team should do

• Prioritize patching systems and base images where util-linux login is exposed through remote login services and PAM rules use hostnames or fully qualified domain names.
• Inventory PAM configurations for host-based allow/deny rules and replace hostname-dependent trust decisions with IP/CIDR, identity-aware, or certificate-backed controls where possible.
• Track distribution advisories for exact fixed util-linux versions, then update hosts, container images, hardened images, and downstream artifacts built from them.
• Hunt authentication logs for unusual remote hostname values, hostname truncation/canonicalization anomalies, and successful logins from sources that should have been denied by PAM host policy.
• Add regression tests for PAM access policy to ensure crafted or non-canonical hostnames cannot match trusted FQDN rules unexpectedly.
• Because EPSS is low, stable, not KEV-listed, and has no known exploit maturity, treat this as targeted hardening priority rather than an emergency internet-wide exploitation event unless local exposure is confirmed.