When a vulnerability lives in the login form, the front door of the application becomes the attacker's instrument. CVE-2021-47966, published to the National Vulnerability Database on May 15, 2026, is exactly that: an unauthenticated blind SQL injection in PHP Timeclock 1.04, an open-source employee time-tracking application. NVD scores it 8.2 (HIGH) on CVSS 3.1, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N — reachable over the network with no prior authentication and no user interaction, with a high impact on confidentiality. The weakness is catalogued as CWE-89: SQL Injection, and what makes it especially relevant to anyone covering authentication weaknesses is precisely where it sits.
According to the NVD description, the vulnerable parameter is login_userid in login.php. An attacker submits crafted POST requests whose payloads manipulate the SQL query that the login page builds to look up a user. Because the input is not safely parameterized, the attacker's text becomes part of the query logic rather than data. The record specifically calls out time-based and boolean-based blind techniques — SLEEP functions to infer answers from response delays, and RLIKE conditional statements to infer them from differences in behavior — to extract sensitive database information including employee names and credentials.
Why an authentication endpoint is the worst place for this bug
SQL injection is a decades-old class, but its placement matters enormously to severity. A login form is, by design, reachable before any authentication has occurred — that is its whole purpose. So an injection there requires no account, no token, and no social engineering. The attacker is invited to submit a username, and the application turns that username directly into query logic. That is why CVE-2021-47966 carries a Privileges Required value of None: the precondition the attacker would normally have to satisfy — being authenticated — is the very thing the vulnerable endpoint exists to grant, and it can be bypassed as a data-extraction channel without ever logging in.
The blind nature of the injection is worth explaining, because it shapes how the attack actually runs. In a classic injection, results come straight back in the response. “Blind” means the application does not return query results directly, so the attacker infers data one bit at a time. A time-based payload might say, in effect, “if the first character of the admin's password hash is greater than ‘m’, sleep for five seconds.” By measuring whether the response is slow, the attacker learns that bit and moves on. It is slower than direct extraction but, with automation, entirely practical — and it can reconstruct an entire credential table character by character.
From injection to credential compromise
The confidentiality impact here is not abstract. The NVD record states the extracted data includes employee names and credentials. For a time-tracking system, that table is the crown jewels: usernames map to real people, and any stored password material — especially if hashing is weak or absent — becomes a springboard. Credential reuse across systems means a dumped time-clock password may unlock email, VPN, or HR portals. The integrity impact is rated Low and availability None, so this is fundamentally a data-disclosure event, but disclosure of authentication material is among the most damaging forms of disclosure because it cascades.
The fix is structural and well established: never build SQL by concatenating user input. Parameterized queries (prepared statements) keep the boundary between code and data inviolate, so that login_userid is always treated as a value to compare, never as syntax to execute. Input validation and least-privilege database accounts are useful supplements — a login query that runs as a read-limited role cannot be coerced into writing — but parameterization is the actual remedy. Applications that still concatenate user input into queries in 2026 are carrying a liability that has had a known, simple fix for twenty years.
What defenders should do now
The references attached to the NVD record include an Exploit-DB entry (49849) and a VulnCheck advisory, so working exploit details are public. Organizations running PHP Timeclock 1.04 should treat exposure of that login page to untrusted networks as an active risk and remove or isolate the application pending a patched release; the project's SourceForge pages are linked from the advisory for tracking updates. As an immediate compensating control, a web application firewall can flag injection signatures — SLEEP(, RLIKE, and similar tokens — in the login_userid field, and unusual response-time clustering on the login endpoint is a useful detection signal for the time-based variant.
The credential-disclosure cascade
What elevates a SQL injection on a login page above an ordinary data-disclosure bug is the nature of the data it exposes. A login table is not merely sensitive; it is the keystone of the application's entire authentication model. Once an attacker can read it, every assumption downstream collapses. If passwords are stored in plaintext or with a fast, unsalted hash, the attacker simply logs in as any employee — including administrators — and the SQL injection becomes a full authentication bypass. Even if the storage is reasonably hardened, the attacker now possesses the usernames and the hashes, which they can attack offline at leisure with no rate limiting and no lockout. Modern password-cracking rigs make short or common passwords trivial to recover, so “hashed” is not the same as “safe” when the hashes have been exfiltrated.
The credential-reuse dimension widens the blast radius beyond the vulnerable application entirely. Studies of breach corpora consistently show that a large fraction of users reuse passwords across services, so a dumped time-clock credential is frequently a working credential somewhere far more valuable — corporate email, single sign-on, a VPN. This is why defenders treat the disclosure of any authentication store as a potential organization-wide incident rather than a problem confined to the breached app. For CVE-2021-47966 specifically, the responsible response after patching includes forcing password resets for every affected account and watching for anomalous logins elsewhere that might indicate the harvested credentials are being replayed.
The broader lesson of CVE-2021-47966 is one defenders repeat often because it keeps mattering: the authentication layer is not just a gate to protect, it is a surface to harden. A login form that mishandles its single most attacker-controlled input doesn't merely fail to keep people out — it actively hands over the credentials of everyone who was supposed to be inside.