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.
Plexicus auto-detects CWE-187 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
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 when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.