Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
CWE-187 Variant Incomplete
Partial String Comparison
This weakness occurs when software checks only part of a string or token to determine a match, instead of comparing the entire value. This incomplete validation can lead to incorrect security…
Definition
What is CWE-187?
This weakness occurs when software checks only part of a string or token to determine a match, instead of comparing the entire value. This incomplete validation can lead to incorrect security decisions.
Partial string comparison happens when a system, such as an authentication module, validates only the first few characters of an input against a stored value. For example, if a password check only verifies the initial 5 characters, an attacker could gain access by providing any password that starts with those same 5 characters, regardless of the full correct password.
This flaw fundamentally undermines security logic by treating partially matching inputs as fully authorized. Developers should always enforce complete, exact-string comparisons for security-critical operations like authentication, authorization tokens, or integrity checks to prevent attackers from exploiting these predictable shortcuts.
Real-world impact
Real-world CVEs caused by CWE-187
-
Product does not prevent access to restricted directories due to partial string comparison with a public directory
-
Argument parser of an IMAP server treats a partial command "body[p" as if it is "body.peek", leading to index error and out-of-bounds corruption.
-
Web browser only checks the hostname portion of a certificate when the hostname portion of the URI is not a fully qualified domain name (FQDN), which allows remote attackers to spoof trusted certificates.
-
One-character password by attacker checks only against first character of real password.
-
One-character password by attacker checks only against first character of real password.
How attackers exploit it
Step-by-step attacker path
- 1
This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.
- 2
In AuthenticateUser(), the strncmp() call uses the string length of an attacker-provided inPass parameter in order to determine how many characters to check in the password. So, if the attacker only provides a password of length 1, the check will only examine the first byte of the application's password before determining success.
- 3
As a result, this partial comparison leads to improper authentication (CWE-287).
- 4
Any of these passwords would still cause authentication to succeed for the "admin" user:
- 5
This significantly reduces the search space for an attacker, making brute force attacks more feasible.
Vulnerable code example
Vulnerable C
This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded.
```
/* Ignore CWE-259 (hard-coded password) and CWE-309 (use of password system for authentication) for this example. */*
char *username = "admin";
char *pass = "password";
int AuthenticateUser(char *inUser, char *inPass) {
```
if (strncmp(username, inUser, strlen(inUser))) {
logEvent("Auth failure of username using strlen of inUser");
return(AUTH_FAIL);
}
if (! strncmp(pass, inPass, strlen(inPass))) {
logEvent("Auth success of password using strlen of inUser");
return(AUTH_SUCCESS);
}
else {
logEvent("Auth fail of password using sizeof");
return(AUTH_FAIL);
}
}
int main (int argc, char **argv) {
int authResult;
if (argc < 3) {
ExitError("Usage: Provide a username and password");
}
authResult = AuthenticateUser(argv[1], argv[2]);
if (authResult == AUTH_SUCCESS) {
DoAuthenticatedTask(argv[1]);
}
else {
ExitError("Authentication failed");
}
} Attacker payload
Any of these passwords would still cause authentication to succeed for the "admin" user:
p
pa
pas
pass Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-187
- Testing Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing.
Detection signals
How to detect CWE-187
Run dynamic application security testing against the live endpoint.
Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.
Code review: flag any new code that handles input from this surface without using the validated framework helpers.
CWE-187
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Frequently asked questions What is CWE-187?
How serious is CWE-187?
What languages or platforms are affected by CWE-187?
How can I prevent CWE-187?
How does Plexicus detect and fix CWE-187?
Where can I learn more about CWE-187?
Frequently asked questions
What is CWE-187?
This weakness occurs when software checks only part of a string or token to determine a match, instead of comparing the entire value. This incomplete validation can lead to incorrect security decisions.
How serious is CWE-187?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-187?
MITRE has not specified affected platforms for this CWE — it can apply across most application stacks.
How can I prevent CWE-187?
Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing.
How does Plexicus detect and fix CWE-187?
Plexicus's SAST engine matches the data-flow signature for CWE-187 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-187?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/187.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-187
CWE-1023 Parent
Incomplete Comparison with Missing Factors
This weakness occurs when a program compares two items but fails to check all the necessary attributes that define their true…
CWE-184 Sibling
Incomplete List of Disallowed Inputs
This vulnerability occurs when a security filter or validation mechanism relies on a 'denylist'—a predefined list of forbidden inputs—but…
CWE-478 Sibling
Missing Default Case in Multiple Condition Expression
This vulnerability occurs when code with multiple conditional branches, like a switch statement, lacks a default case to handle unexpected…
CWE-839 Sibling
Numeric Range Comparison Without Minimum Check
This vulnerability occurs when software validates that a number is within an acceptable range by only checking that it's less than or…
Ready to validate what matters?
Ready to validate what matters?
Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.