Emlog CMS Pro CVE-2026-53756

Exploitation requires the attacker to first obtain the application's AUTH_KEY secret, used to sign authentication cookies via HMAC; without this key, the cookie fails validation before the injection path is reached. The vulnerable function User_Model::getUserDataByLogin() is invoked during cookie-based session validation on the network-accessible authentication endpoint, requiring no user interaction once the key is held. The injection is blind - query output is not returned to the caller - so attackers must use boolean-based or time-based inference, meaning exfiltration is slow and noisy. No non-default feature flags or platform-specific configuration are required beyond a standard Emlog Pro installation running any version prior to 2.6.16 with AUTH_KEY known to the attacker. The attack produces confidentiality impact only (C:H); integrity and availability are not affected by this injection path.

The CVSS 3.1 base score of 4.9 with vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N accurately reflects the constrained risk profile: network reachability and high confidentiality impact are genuine, but the PR:H designation captures the meaningful prerequisite of holding the AUTH_KEY application secret. Without that key, an attacker cannot generate a valid HMAC-signed cookie and cannot reach the injection path at all. This is not a low-barrier, mass-exploitable vulnerability - it requires a prior compromise of the application's configuration secret. EPSS data is absent from the input, and the vulnerability does not appear in CISA KEV, which is consistent with its constrained preconditions. No public proof-of-concept has been confirmed. Real-world risk is elevated primarily in deployments where AUTH_KEY is weak, shared across environments, or has already been exposed; operators running default or low-entropy keys face meaningfully higher exposure. The CVSS AC:L rating correctly reflects that, once the key is held, cookie forgery itself is computationally trivial.

An attacker who has obtained the Emlog AUTH_KEY - for example from a leaked .env or configuration file, a misconfigured backup, or a previously compromised host - crafts an authentication cookie whose username field embeds a time-based or boolean-based blind SQL payload signed with the stolen key. The CMS validates the HMAC, passes the unsanitized value into getUserDataByLogin(), and the attacker iterates payloads to infer database contents character by character, ultimately recovering password hashes, email addresses, or other sensitive user records. No public exploit code is confirmed at time of analysis.