Auth Bypass via SQLi in Task Manager Login

Overview

CVE-2026-19342 is a high-severity improper authentication vulnerability affecting the login component of code-projects Task Management System version 1.0. The flaw resides in the Password parameter handled by /index.php, where unsanitized user input is passed directly into an authentication query — a textbook case of SQL injection enabling authentication bypass. With a CVSS score of 7.3, this vulnerability is remotely exploitable with no authentication required, making it immediately actionable for any attacker who can reach the login page.

The issue was identified by security researchers and publicly disclosed via a GitHub issue tracker, with a working proof-of-concept now available in the wild. This means the exploitation window is effectively open: any unpatched deployment of Task Management System 1.0 reachable from a network should be treated as compromised until verified otherwise. The application is a PHP-based project distributed through code-projects.org, a platform hosting numerous small-scale academic and hobbyist PHP applications that are frequently deployed in internal tooling, educational settings, and small business environments — often without the security oversight applied to enterprise software.

The vulnerability class itself — SQL injection leading to authentication bypass — is neither novel nor exotic. What makes it persistently dangerous is its prevalence in PHP applications that handle authentication with raw query construction, and the fact that deployed instances of such tools rarely receive security patches once installed.

Technical Analysis

The root cause is classic: the Password field in the login form is incorporated into a SQL query without sanitization, parameterization, or prepared statements. When PHP code constructs authentication logic by embedding raw POST input directly into a SELECT or WHERE clause, an attacker can manipulate the query’s logical structure.

A representative vulnerable pattern consistent with this class of application looks like this:

<?php
// /index.php - Vulnerable login handler
$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

if (mysqli_num_rows($result) > 0) {
    $_SESSION['authenticated'] = true;
    header("Location: dashboard.php");
    exit();
} else {
    echo "Invalid credentials.";
}
?>

An attacker supplying the following payload in the Password field:

' OR '1'='1

causes the executed query to become:

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

The OR '1'='1' condition is always true, so the query returns rows regardless of the actual password value. The application then evaluates mysqli_num_rows($result) > 0 as true and grants the attacker an authenticated session — no valid credentials required.

More aggressive payloads can target specific accounts:

' OR 1=1 -- -

This comments out everything after the injected condition, bypassing even more complex query structures. The mechanism is entirely deterministic: the application has surrendered control of its own query logic to the user because it treats input as trusted code rather than untrusted data. The password argument is the injection point named in the CVE, but in applications built with this pattern, the username field is typically equally vulnerable.

Impact

An attacker who successfully exploits this vulnerability achieves full authentication bypass, gaining access to whatever administrative or user-level functionality the Task Management System exposes. In a task management context, that typically includes reading and modifying all task records, accessing user account data (potentially including stored credentials for other users), and exfiltrating any personally identifiable information stored in the application database.

The CVSS 7.3 score reflects the AV:N (network-accessible), AC:L (low complexity), and PR:N (no privileges required) vectors — meaning exploitation requires nothing more than an HTTP client and knowledge of the login endpoint. With a public proof-of-concept in circulation, the skill floor for exploitation is negligible.

Beyond data theft, an attacker with authenticated access to the application may be able to leverage secondary vulnerabilities — file uploads, stored XSS, or privilege escalation — to achieve deeper system compromise depending on the hosting environment. In shared hosting scenarios common to small PHP deployments, this can cascade to neighboring applications.

How to Fix It

The remediation is unambiguous: replace string-concatenated queries with parameterized prepared statements. This eliminates the injection surface entirely by separating query logic from user-supplied data.

<?php
// /index.php - Fixed login handler using prepared statements
$username = $_POST['username'];
$password = $_POST['password'];

// Use a prepared statement — user input never touches query structure
$stmt = $conn->prepare("SELECT id, password_hash FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();
$result = $stmt->get_result();

if ($result->num_rows === 1) {
    $row = $result->fetch_assoc();
    // Verify password against a stored bcrypt/argon2 hash
    if (password_verify($password, $row['password_hash'])) {
        $_SESSION['authenticated'] = true;
        $_SESSION['user_id'] = $row['id'];
        header("Location: dashboard.php");
        exit();
    }
}

echo "Invalid credentials.";
$stmt->close();
?>

Key changes:

1. Prepared statement with ? placeholder — the query structure is compiled before any user data is bound. Injected SQL metacharacters are treated as literal string values.
2. password_verify() against a hash — passwords must be stored as bcrypt or Argon2 hashes, not plaintext. If the existing schema stores plaintext passwords, a migration to password_hash() is also required.
3. Row count checked before hash comparison — authentication only proceeds when a matching username exists, preventing timing oracle attacks.

Since this is a standalone PHP project rather than a Composer-managed package, there is no composer update command to run. Administrators should apply the code fix directly to /index.php and audit all other query-construction patterns across the codebase using the same methodology.

Our Take

Authentication bypass via SQL injection in PHP login forms is one of the most well-documented vulnerability patterns in existence — documented in OWASP guides, covered in every web security curriculum, and yet it continues to appear in deployed software. The persistence of this class of vulnerability in 2026 reflects a structural problem: a large volume of PHP application code was written before secure-by-default practices became standard, and it circulates through code sharing platforms where it gets deployed without security review.

For enterprises, the lesson is about asset inventory and provenance. Small internal tools, academic projects, and departmental applications frequently bypass the security scrutiny applied to approved software. Any PHP application handling authentication deserves the same scrutiny as a production API: parameterized queries are non-negotiable, password hashing is non-negotiable, and externally facing login endpoints need to be in scope for both SAST and DAST coverage.

This vulnerability also underscores why “low complexity, no privileges required” vulnerabilities consistently punch above their apparent weight class — they are the ones attackers actually use at scale.

Detection with SAST

This vulnerability maps to CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) and CWE-287 (Improper Authentication). SAST detection targets two complementary patterns:

Taint analysis — tracking the flow of data from HTTP input sources ($_POST, $_GET, $_REQUEST, $_COOKIE) through string concatenation or interpolation into database query functions (mysqli_query(), mysql_query(), pg_query(), PDO::query() when called with concatenated strings). Any path where tainted data reaches a query execution sink without passing through a parameterization boundary is flagged.

Pattern matching on query construction — direct heuristic rules that identify string interpolation inside SQL keyword contexts: "SELECT ... WHERE ... '$var'", "... AND password = '" . $var . "'". These fire regardless of taint tracking and catch cases where intermediate variables obscure the flow.

Offensive360’s PHP rule set specifically targets authentication handlers — files and functions whose names or context suggest login logic (login, auth, signin, index.php with $_SESSION writes) and applies elevated sensitivity to query construction within those scopes. The combination of a $_POST source, SQL sink, and $_SESSION['authenticated'] assignment in the same control flow is a high-confidence signal for exactly this vulnerability pattern.

References

• https://github.com/littleRain1355/PHPissue/issues/1
• https://code-projects.org/
• https://vuldb.com/cve/CVE-2026-19342
• https://vuldb.com/submit/865315
• https://vuldb.com/vuln/387178
• https://vuldb.com/vuln/387178/cti