CVE-2023-4641 is a medium-severity information-disclosure vulnerability in shadow-utils, where a failed second password entry during a change can leave the first password lingering in an uncleared memory buffer. It carries a CVSS 3.1 base score of 5.5 and affects shadow-utils versions before 4.14.0. The practical risk is narrow, but it is worth understanding because shadow-utils ships on essentially every Linux system, which makes it a common line item in container image scans.
What shadow-utils is and why it matters
Shadow-utils provides the core account-management commands on Linux: passwd, useradd, usermod, login, chage, and the shadow password file handling behind them. Because it is foundational, it is installed on virtually every distribution and baked into most base container images. That ubiquity is precisely why a medium-severity flaw in it shows up on so many scan reports; you are almost certainly running shadow-utils whether or not you ever think about it.
What the vulnerability does
When you change a password, passwd asks for the new password twice to confirm it. CVE-2023-4641 is a memory-hygiene bug in that flow. If the second entry fails, for example the two entries do not match, shadow-utils does not properly clear the buffer that held the first entered password. The sensitive value stays resident in process memory instead of being zeroed out immediately.
An attacker who can read that process's memory could potentially recover the plaintext password. That is the key constraint: exploiting this requires local access and the ability to inspect the relevant memory, not a remote network position. It is a defense-in-depth failure rather than a direct remote compromise, which is why it lands at medium severity rather than high or critical.
Affected versions and severity
The flaw affects shadow-utils versions up to but not including 4.14.0. The fix landed in 4.14.0, which ensures the password buffer is cleared even when the confirmation step fails.
The assigned CVSS 3.1 base score is 5.5 (Medium), with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. Reading that vector tells you most of what you need to triage it: the attack vector is Local, privileges are required at a Low level, the impact is confidentiality-only with no effect on integrity or availability. In plain terms, a local, semi-privileged actor could learn a password under specific timing conditions. That is a real problem on a multi-user host and a mostly theoretical one on a single-tenant container that never runs passwd interactively.
How to check your systems
On a package-managed host, query the installed version:
# Debian / Ubuntu
dpkg -l | grep -E "passwd|login"
# RHEL / Fedora / Alma / Rocky
rpm -q shadow-utils
Distributions backport security fixes without bumping the upstream version number, so the raw version string can be misleading. The reliable signal on enterprise distros is the vendor advisory and package release. Red Hat, for instance, addressed CVE-2023-4641 across its Enterprise Linux lines through security advisories, and SUSE and the Amazon Linux security stream issued their own. Check whether your installed package includes your vendor's patched build rather than comparing only against the upstream 4.14.0 cutoff.
Remediating CVE-2023-4641
Remediation is ordinary patch management: update the shadow-utils (or passwd/login) package to a build that includes the fix.
# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade passwd login
# RHEL family
sudo dnf update shadow-utils
For container images, the fix is to rebuild on an updated base image rather than patching a running container. A running container is disposable; changing the image and redeploying is the durable fix. This is where the finding most often appears, because a base image built months ago carries whatever shadow-utils version was current then.
# Pull a fresh base and rebuild so the patched package is included
FROM debian:12
RUN apt-get update && apt-get upgrade -y && rm -rf /var/lib/apt/lists/*
Putting the risk in context
Do not let a medium-severity OS-package CVE crowd out higher-priority work, but do not ignore it either. The right response is proportional: on a shared interactive host where users change passwords, patch promptly. On an ephemeral, single-purpose container that never invokes passwd, fold the fix into your normal base-image refresh cycle rather than firefighting it.
The broader lesson is that base images accumulate these findings silently. A rebuild that pulls current packages clears a whole batch of OS-layer CVEs like this one at once, which is why a scheduled rebuild cadence beats chasing individual advisories. Container and dependency scanning through a software composition analysis workflow will keep flagging CVE-2023-4641 until the underlying package is actually updated in the image you ship, so treat a persistent finding as a signal that your base image is stale. An SCA tool such as Safeguard can track which images still carry the vulnerable version across your registry so the rebuild is targeted.
FAQ
Is CVE-2023-4641 remotely exploitable?
No. The CVSS vector specifies a Local attack vector with Low privileges required. An attacker needs local access and the ability to read the relevant process memory, so it is not a remote-compromise vulnerability.
What version of shadow-utils fixes CVE-2023-4641?
Upstream shadow-utils 4.14.0 contains the fix. Enterprise distributions backport it into earlier package versions, so rely on your vendor's advisory and patched package build rather than the upstream version number alone.
How severe is CVE-2023-4641?
It has a CVSS 3.1 base score of 5.5, rated Medium. The impact is confidentiality-only, and exploitation requires local access, which keeps it below high severity.
Why does this CVE keep appearing in my container scans?
Because the vulnerable shadow-utils package is baked into your base image, and a running container cannot be truly patched in place. The finding clears only when you rebuild the image on an updated base that includes the fixed package.