This weakness occurs when software compares or validates user input without properly accounting for case differences uppercase vs. lowercase. An attacker can…
This weakness occurs when software compares or validates user input without properly accounting for case differences (uppercase vs. lowercase). An attacker can bypass security filters, access controls, or validation rules by submitting input in an unexpected case — for example, using Admin instead of admin to evade a blocklist, or ../ instead of ../ in a path filter. The impact ranges from minor (logic errors) to severe (authentication bypass or file access).
Most programming languages treat uppercase and lowercase letters as distinct characters by default. When developers write validation logic that compares strings directly without normalizing case first, they create a gap: a filter that blocks admin will not catch ADMIN or AdMiN. This is especially dangerous in security contexts like role checking, file extension validation, URL path filtering, and command blocklists. The flaw often stems from incomplete threat modeling — developers may test the "obvious" case but miss that case variation is a trivial bypass.
Case-sensitivity bypasses can lead to authentication bypass (logging in as a different user role), unauthorized file access (uploading a .PHP file when .php is blocked), SQL injection (using UnIoN to evade a UNION filter), or command execution (running CaT when cat is blocked). The severity depends on what is being validated; a case-insensitive role check in an admin panel is critical, while a case-insensitive log message filter is low-risk.
def is_admin(username):
blocked_users = ["admin", "root", "system"]
if username in blocked_users:
return False
return True
# Attacker bypasses with: "Admin", "ADMIN", "AdMiN"
user_input = "Admin"
if is_admin(user_input):
grant_privileges(user_input)Why it's vulnerable:
The blocked_users list contains lowercase strings, but the comparison does not normalize the input case. An attacker can use any case variation to bypass the check.
def is_admin(username):
blocked_users = ["admin", "root", "system"]
if username.lower() in blocked_users:
return False
return True
# Now "Admin", "ADMIN", "AdMiN" are all caught
user_input = "Admin"
if is_admin(user_input):
grant_privileges(user_input)<?php
$allowed_extensions = array("jpg", "png", "gif");
$filename = $_FILES["upload"]["name"];
$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));
// Vulnerable: direct string comparison without case normalization
if (in_array($ext, $allowed_extensions)) {
move_uploaded_file($_FILES["upload"]["tmp_name"], "/uploads/" . $filename);
}
?>Why it's vulnerable:
Although strtolower() is used on the extension, the original filename is still used in the move operation. An attacker uploading shell.PHP could bypass extension checks if the server executes .PHP files.
<?php
$allowed_extensions = array("jpg", "png", "gif");
$filename = $_FILES["upload"]["name"];
$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));
// Fixed: normalize and validate, then use a sanitized filename
if (in_array($ext, $allowed_extensions)) {
$safe_filename = bin2hex(random_bytes(16)) . "." . $ext;
move_uploaded_file($_FILES["upload"]["tmp_name"], "/uploads/" . $safe_filename);
} else {
die("Invalid file type");
}
?>str.lower() in Python, strtolower() in PHP) or locale-aware comparison if internationalization is a concern.
Review your authentication and authorization logs for unusual login attempts using case variations of known usernames (e.g., Admin, ADMIN, root, ROOT). Check file upload directories for files with unexpected case extensions (e.g., .PHP, .pHP, .Php) that may have bypassed extension filters. Search your codebase for direct string comparisons in security-critical functions (role checks, permission validation, file type checks) that do not explicitly normalize case.
