Exploited libuser flaw exposes legacy Red Hat systems

What has changed

CISA added CVE-2015-3246 to its Known Exploited Vulnerabilities catalogue on 26 August, confirming that the flaw has been exploited in the wild. The vulnerability is not new: Red Hat documented and fixed it in 2015. The new fact is CISA's exploitation finding, which makes any surviving vulnerable installation a more urgent piece of legacy risk to resolve.

The flaw is a race condition in the libuser library's handling of the /etc/passwd file. Red Hat says an authenticated local user with an account recorded in that file, and the account password, could corrupt the file, cause denial of service or escalate privileges to root. Neither source says every vulnerable host has been compromised or links the activity to ransomware.

Which systems need attention

Red Hat's original advisory says all libuser versions supplied with Red Hat Enterprise Linux 6 and 7 were affected and points to fixed packages in its 2015 security advisories. It also records Red Hat Enterprise Linux 5 as affected without a planned update at the time. These are legacy operating-system generations, so administrators should check the present support position and available content for their exact subscription and release rather than assuming that an old update route still applies.

This is a local privilege-escalation flaw, not an unauthenticated internet attack. It requires an existing local account in /etc/passwd and the relevant password. That limits the route in, but it does not make the issue harmless: shared servers, supplier access, reused service hosts and previously gained low-privilege access can all turn a local boundary into an important one.

What defenders should do

Inventory Red Hat Enterprise Linux 5, 6 and 7 systems across production, recovery, test and supplier-managed environments. Confirm the exact operating-system release, installed libuser package, support entitlement, workload owner and people or services able to obtain a local account. Do not rely on a hostname, an asset age or a network scan to establish package state.

For a supported system, use Red Hat's current supported tooling and advisory data to install the applicable fixed package. Where the release or workload no longer has a supported remediation path, plan migration to a supported platform rather than treating a configuration change as a permanent cure. Red Hat documents PAM rules that prevent non-root use of the affected chfn and chsh functions as a mitigation when updating is not possible, but this changes functionality and should be tested and governed as a temporary risk decision.

For a confirmed vulnerable host with untrusted or broadly assigned local accounts, preserve useful authentication, privilege and system logs before disruptive work. Review evidence proportionately under the incident process. CISA's catalogue confirms exploitation of the vulnerability in the wild; it does not provide a universal indicator set or prove compromise from an installed package alone.

• Locate legacy Red Hat systems, including test, recovery and supplier-managed hosts.
• Confirm the exact release, libuser package and current vendor support route.
• Apply the supported fixed package or migrate the workload to a supported platform.
• Treat Red Hat's PAM mitigation as a tested, temporary risk decision where necessary.
• Preserve useful evidence and investigate according to actual local-account exposure.

The Beekeeper view

A decade-old vulnerability appearing in an exploited catalogue is less a surprise patching story than an asset-lifecycle test. The fix has existed for years; the likely difficulty is finding the forgotten server, proving what package it runs and deciding who owns the migration risk.

Use this alert to close that governance gap. Link legacy-system exceptions to a named owner, support status, local-access list, compensating controls and a dated retirement plan. That work deals with today's verified weakness while making the next old flaw considerably less archaeological.