LiveActive security incident?Get immediate response
CVE Record

CVE-2019-19234: In Sudo through 1.8.29, the fact that a user has been blocked (e.g., by using the !

In Sudo through 1.8.29, the fact that a user has been blocked (e.g., by using the ! character in the shadow file instead of a password hash) is not considered, allowing an attacker (who has access to a Runas ALL sudoer account) to impersonate any blocked user. NOTE: The software maintainer believes that this CVE is not valid. Disabling local password authentication for a user is not the same as disabling all access to that user--the user may still be able to login via other means (ssh key, kerberos, etc). Both the Linux shadow(5) and passwd(1) manuals are clear on this. Indeed it is a valid use case to have local accounts that are _only_ accessible via sudo and that cannot be logged into with a password. Sudo 1.8.30 added an optional setting to check the _shell_ of the target user (not the encrypted password!) against the contents of /etc/shells but that is not the same thing as preventing access to users with an invalid password hash

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This disputed CVE describes sudo allowing a permitted administrator-style user to run commands as a locally password-blocked account. The key business risk is mistaken reliance on a locked local password as full account disablement. The sudo maintainer disputes the CVE because password login blocking does not necessarily mean the account should be unreachable by sudo or other authentication methods.

Executive priority

Handle as a configuration and patch hygiene issue. Prioritize high-trust servers, appliances, and shared administrative environments where sudoers policy is broad and locked-password service accounts are assumed disabled.

Technical view

Reportedly affects sudo through 1.8.29 when an attacker already has access to a sudoers account with Runas ALL. Sudo did not treat an invalid or blocked shadow password hash as preventing run-as use of that target account. Sudo 1.8.30 added an optional target-user shell check, but the maintainer says this is not equivalent to blocking invalid password hashes.

Likely exposure

Exposure is limited to Unix-like systems using affected sudo versions, with sudoers rules allowing broad Runas ALL behavior, and accounts treated operationally as disabled only because local password authentication is blocked.

Exploitation context

The bundle does not show CISA KEV listing or active exploitation evidence. Abuse requires existing access to a sudo-capable account with broad run-as rights, so this is mainly a privilege-boundary and account governance issue, not a remote unauthenticated threat.

Researcher notes

Evidence is complicated by maintainer dispute. The core distinction is password authentication lock versus account disablement. Avoid scoring it as a universal sudo bypass; validate local policy assumptions, distribution backports, and vendor advisories before declaring exposure.

Mitigation direction

  • Check vendor guidance for your OS or appliance distribution.
  • Inventory sudo versions and prioritize systems at or below 1.8.29.
  • Review sudoers entries granting Runas ALL or broad target-user access.
  • Do not treat locked local passwords as full account deactivation.
  • Evaluate sudo 1.8.30 or vendor-supported updates where applicable.
  • Use shells or account controls aligned with vendor guidance for disabled accounts.

Validation and detection

  • Identify systems running sudo through 1.8.29.
  • Review sudoers policy for broad Runas permissions.
  • List accounts with blocked local password hashes but valid shells.
  • Confirm whether those accounts are intended to be reachable through sudo.
  • Check vendor advisories for product-specific affected status and fixes.
  • Review sudo logs for unexpected run-as activity involving blocked-password accounts.
Prepared
Confidence
medium
Sources
9

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

description · low confidence lookup

Credential and access behavior lookup

The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.

Open ATT&CK lookup
cve · low confidence lookup

CVE-2019-19234 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
0Timeline events
0ADP providers
20Source links

CVSS and timeline data

No CVSS vectors or timeline events were available in the normalized CVE source material.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
n/an/an/aListed
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.