CVE-2014-125136 in Cart Engine
Summary
by MITRE • 10/28/2026
C97net qEngine CMS through 6.0.0, Kemana Directory through 1.5.6, and Cart Engine through 3.0.0 contain an information disclosure vulnerability that exposes database backups in the web-accessible /admin/backup directory. Unauthenticated attackers can list the directory or guess date-based names like 'Full Backup YYYYMMDD.sql' to download dumps containing user records and administrator password hashes.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The identified security flaw represents a critical configuration error within multiple content management systems, specifically C97net qEngine CMS versions up to 6.0.0, Kemana Directory through version 1.5.6, and Cart Engine through version 3.0.0. This vulnerability stems from the improper placement of sensitive database backup files within a web-accessible directory structure, namely /admin/backup. By storing these backups in a location that is directly served by the web server without adequate access controls or authentication checks, the systems inadvertently expose their most critical data assets to any entity capable of accessing the application over HTTP or HTTPS. This misconfiguration violates fundamental security principles regarding the separation of sensitive operational files from public-facing resources, creating a direct pathway for attackers to retrieve comprehensive snapshots of the underlying database.
The technical mechanism of this vulnerability relies on directory listing capabilities and predictable file naming conventions. Unauthenticated actors can exploit standard web server behaviors that allow browsing of directories when index files are missing or explicitly permitted by configuration settings. Furthermore, even if directory listing is disabled, the backup filenames follow a deterministic pattern based on dates, such as Full Backup YYYYMMDD.sql. This predictability allows attackers to use automated tools to guess and request specific file paths with high success rates. Once accessed, these SQL dump files contain raw data from the application's database, including user records, personal identifiable information, and critically, administrator password hashes stored in plaintext or weakly hashed formats depending on the system's configuration at the time of backup creation.
The operational impact of this disclosure is severe and multifaceted. The exposure of full database backups provides attackers with a complete view of the application's data landscape. This includes sensitive user information such as email addresses, usernames, and potentially other personal details, leading to privacy violations and potential identity theft scenarios for affected users. More critically, the inclusion of administrator password hashes allows for offline brute-force or dictionary attacks against these credentials. If weak hashing algorithms like MD5 or SHA1 are used without salting, which is common in older versions of these CMS platforms, attackers can rapidly reverse-engineer passwords to gain administrative access to the web application. This unauthorized elevation of privilege enables further malicious activities such as defacement, malware injection, data exfiltration, and using the compromised server as a pivot point for attacks against internal network resources.
This vulnerability aligns with CWE-538, which classifies file inclusion through directory traversal or improper path resolution, although in this specific context it is more accurately categorized under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-16: Configuration. From a threat modeling perspective utilizing the MITRE ATT&CK framework, this activity corresponds to T1537: Transfer Data to Cloud Account or External Remote Server if exfiltrated, but primarily falls under T1083: File and Directory Discovery for reconnaissance and T1190: Exploit Public-Facing Application. The lack of authentication on the backup directory represents a failure in access control mechanisms that should restrict sensitive administrative functions and data to authorized personnel only.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Immediately, administrators should remove or relocate the /admin/backup directory outside of the web root so it is not directly accessible via HTTP requests. If relocation is not feasible due to application dependencies, strict access controls such as IP whitelisting for administrative subnets or requiring strong authentication before serving any files in that directory are necessary alternatives. Additionally, backup filenames should be randomized and stored with extensions that do not trigger automatic execution or viewing by web servers, such as .bak or .sql.gz combined with server configuration to deny direct access. Long-term solutions involve implementing a secure backup management strategy where backups are encrypted at rest, stored in isolated storage buckets with private permissions, and retained for limited durations to minimize the window of exposure. Regular security audits should verify that no sensitive files reside in publicly accessible directories across all deployed instances of these systems.