Description

Emlog is an open source website building system. Prior to version 2.6.16, Emlog CMS Pro contains a blind SQL injection in User_Model::getUserDataByLogin(). The $account parameter is directly interpolated into SQL queries without any filtering. The vulnerability is reachable through the auth cookie validation path, where $username is extracted from the cookie and passed unfiltered into SQL — guarded only by an HMAC signature that requires AUTH_KEY to forge. This issue has been patched in version 2.6.16.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.9",
  "pubDate": "2026-09-04T18:17:52.350Z",
  "pubdate": "2026-09-04T18:17:52.350Z",
  "executiveSummary": "Emlog CMS Pro versions prior to 2.6.16 are susceptible to a blind SQL injection vulnerability residing within the User_Model::getUserDataByLogin() function.\nThe vulnerability occurs because the $account parameter is processed via direct SQL interpolation without sufficient sanitization or the use of prepared statements.\nAn attacker capable of forging an HMAC signature using the AUTH_KEY can exploit this flaw to execute arbitrary SQL queries against the underlying database.\nThe primary impact involves the potential for unauthorized data exfiltration, database structure exposure, and the compromise of sensitive administrative information.\nExploitation requires the ability to craft a valid authentication cookie that bypasses the HMAC integrity check, necessitating prior knowledge or acquisition of the AUTH_KEY.\nThis issue represents a significant risk to application data integrity and confidentiality, as it enables blind inference of database content through manipulated cookie values.",
  "technicalDetails": "The vulnerability is located within the User_Model::getUserDataByLogin() method, which handles database lookups for user accounts during the authentication validation flow.\nThe root cause is improper neutralization of user-supplied input extracted from the authentication cookie. Specifically, the $account variable is sourced from the cookie's username field and subsequently concatenated directly into a SQL query string without parameterization or escaping.\nThe attack flow initiates when the application processes an incoming HTTP request containing an authentication cookie. The system extracts the $username component from the cookie and passes this unvalidated string into the vulnerable model function.\nWhile the application attempts to verify the integrity of the cookie via an HMAC signature using a predefined AUTH_KEY, the security of the SQL query relies entirely on the secrecy and strength of this key. If an attacker possesses the AUTH_KEY, they can generate a cryptographically valid cookie containing a crafted SQL injection payload.\nBy embedding blind SQL injection payloads within the username portion of the cookie, an attacker can coerce the application into executing arbitrary SQL commands. Because the vulnerability is blind, the attacker typically utilizes boolean-based or time-based inference techniques to extract data.\nFor example, an attacker can inject ' OR (SELECT 1 FROM (SELECT(SLEEP(5)))a)-- into the $account parameter to identify successful injection points via response latency. More advanced payloads allow for the iterative extraction of database names, table contents, or user credentials by observing the application's response behavior based on conditional SQL triggers.\nSince the function is reachable through the standard authentication validation path, the injection vector is exposed to any network-accessible instance of the software. The lack of parameterized queries at the data access layer makes the system inherently vulnerable to query structure manipulation.\nThe impact of a successful exploitation is severe, as the attacker can perform unauthorized data modification or exfiltration, potentially leading to a full compromise of the database contents associated with the Emlog CMS installation."
}