CWE-1390, Weak Authentication, is the case where a product uses an authentication mechanism to restrict access, but the mechanism does not sufficiently prove that the claimed identity is correct.
It is a broad class. MITRE puts it plainly: attackers may be able to bypass weak authentication faster, or with less effort, than expected. It applies to web apps, proxies, chat tools and industrial systems alike.
How it happens
The record's observed examples show that weak authentication is rarely one big hole. It is usually a small logic slip in a mechanism that otherwise exists.
- CVE-2024-48445: an e-commerce app relies on an easily guessable timestamp in its authentication algorithm.
- CVE-2022-30034: the web UI of a Python RPC framework does not use regex anchors when validating login emails, which could allow an OAuth bypass.
- CVE-2022-35248: a chat application skips validation when Central Authentication Service is enabled, which removes the second factor from two factor authentication.
- CVE-2021-3116: a Python based HTTP proxy uses the wrong boolean operators, causing an incorrect comparison in its authentication failure check.
Four different mistakes: a guessable value, an unanchored pattern, a skipped step and a wrong operator. Each one leaves the login screen in place while weakening what it proves.
What an attacker gains
MITRE lists a wide spread of consequences: loss of confidentiality, integrity and availability, bypass of access control, reading application data, gaining privileges or assuming another identity, and executing unauthorized code or commands. Weak authentication can expose resources or functionality to actors who should never see them, and the downstream impact depends on what sits behind the login.
How to find it
The record gives no detection methods, so here are checks drawn from the examples above.
- Read your authentication code for anything derived from a timestamp or another predictable value.
- Check every regular expression used to validate emails or usernames for anchors at both ends.
- Test each alternate login path, such as single sign on modes, and confirm the second factor is still enforced on every one.
- Review boolean logic in authentication checks. Write a test for each combination of conditions, including the failing ones.
How to fix it
MITRE lists no specific mitigations for this entry, so these steps follow from the weaknesses above.
- Use unpredictable, randomly generated values wherever a value gates access.
- Anchor validation patterns, and prefer exact comparison to substring matching.
- Make second factor enforcement a single code path that every login mode must pass through.
- Cover authentication with tests that try to fail it on purpose.
Quick check
Does having a login screen mean authentication is strong?
No. The examples in the record all had authentication in place, yet a guessable value, a missing anchor, a skipped step or a wrong operator weakened it.
Why do unanchored regular expressions matter for login?
Without anchors, a pattern can match part of a string, so an input can pass validation that was meant to reject it. CVE-2022-30034 is an example involving login emails.
