CVE-2026-118494 in JReviews Extension
Summary
by MITRE • 11/05/2026
Joomla Extension - jreviews.com - Secret configs cached in a web-accessible in JReviews 1.0.0-5.12.0, 6.0.0-6.6.9 - JReviews caches its full settings table, including the Joomla global configuration secret (copied into cms_secret) and third-party API keys and secrets, to a serialized file under components/com_s2framework/tmp/cache/core/ inside the web root. The file has no PHP guard and the directory has no .htaccess, so anyone who knows the file name can read it without authentication.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in JReviews versions 1.0.0 through 5.12.0 and 6.0.0 through 6.6.9 represents a critical information disclosure flaw stemming from improper handling of sensitive configuration data within the Joomla content management system ecosystem. This issue is classified under CWE-312, which describes Cleartext Storage of Sensitive Information, as well as CWE-538 regarding File and Directory Information Exposure. The core technical failure lies in how the JReviews extension manages its internal settings table during runtime operations. Instead of storing these configurations securely or encrypting them before persistence, the application serializes the entire configuration array into a flat file located within the web-accessible directory structure at components/com_s2framework/tmp/cache/core/. This location is directly served by standard web servers such as Apache or Nginx without any additional access controls.
The severity of this vulnerability is significantly amplified by the specific contents cached in these files. The serialized data includes not only general extension settings but also critical security parameters derived from the Joomla global configuration, specifically the cms_secret value which serves as a cryptographic salt for session management and password hashing. Furthermore, if administrators have integrated third-party services such as payment gateways, email providers, or social media APIs via JReviews, their corresponding API keys and secrets are stored in plaintext within this cache file. Because the directory lacks an .htaccess rule to deny direct access and the PHP script that generates the cache does not implement any authentication checks before writing sensitive data, an unauthenticated attacker can retrieve these files simply by knowing or guessing the filename structure. This aligns with ATT&CK technique T1005, which covers Data from Local System Retrieval, allowing adversaries to harvest credentials for lateral movement or further exploitation of integrated services.
The operational impact of this vulnerability is severe and multifaceted. An attacker who successfully retrieves these cache files gains immediate access to the Joomla secret key, potentially enabling session hijacking attacks if combined with other vulnerabilities such as cross-site scripting that allows cookie theft. More critically, exposure of third-party API keys can lead to financial loss through unauthorized transactions on payment gateways or reputational damage via compromised email accounts used for notifications. Since JReviews is a widely used extension, this flaw affects a large number of websites running vulnerable versions, creating a widespread attack surface across the Joomla platform. The lack of authentication requirements means that no privilege escalation is necessary to exploit this condition; it relies entirely on path traversal or directory enumeration techniques which are trivial to automate using standard web scanning tools.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators running affected versions should immediately upgrade JReviews to a patched version where the caching mechanism has been revised to store sensitive data outside the web root or in an encrypted format that requires application-level decryption keys not exposed via simple file access. In environments where upgrading is temporarily impossible, administrators can manually delete the cached files and configure their web server software to explicitly deny direct HTTP requests to the components/com_s2framework/tmp/cache/core/ directory using directives such as Deny from all in Apache or return 403 in Nginx configurations. Additionally, implementing strict file permissions that restrict write access for the web server user while ensuring read access is only available through the application logic can provide a layer of defense-in-depth. Regular security audits should include checks for plaintext storage of secrets and verification that temporary directories are not publicly accessible to ensure compliance with secure coding standards like OWASP Top 10 guidelines regarding sensitive data exposure.