CVE-2026-86241 in FeehiCMS
Summary
by MITRE • 09/07/2026
A weakness has been identified in liufee FeehiCMS up to 2.1.1. This impacts an unknown function of the file environments/prod/backend/config/main-local.php of the component Cookie Validation. This manipulation of the argument cookieValidationKey causes use of hard-coded cryptographic key
. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability identified in liufee FeehiCMS versions up to 2.1.1 represents a critical configuration error within the application's security architecture, specifically affecting the Cookie Validation component. The flaw resides in the file environments/prod/backend/config/main-local.php, where the argument cookieValidationKey is manipulated improperly. This misconfiguration results in the use of hard-coded cryptographic keys rather than dynamically generated or securely stored secrets. In modern web frameworks such as Yii2, which FeehiCMS is based on, the cookie validation key serves a vital role in ensuring the integrity and authenticity of session cookies. By relying on static, hardcoded values, the application fails to adhere to fundamental principles of secure configuration management, thereby exposing all instances running this version to significant risk.
From a technical perspective, the use of hard-coded cryptographic keys undermines the confidentiality and integrity guarantees provided by symmetric encryption algorithms typically employed for cookie validation. When the same key is used across multiple deployments or remains static over time, it becomes susceptible to offline brute-force attacks if an attacker can obtain any valid signed cookies from the application traffic. Furthermore, because the key is embedded in the source code or configuration files that may be exposed through version control systems or misconfigured servers, attackers do not need complex exploitation techniques to discover this secret. This significantly lowers the barrier for entry, allowing even less sophisticated threat actors to forge authentication tokens and session identifiers.
The operational impact of this vulnerability is severe due to its remote exploitable nature. An attacker can leverage publicly available exploits to perform Session Hijacking or Privilege Escalation attacks without requiring user interaction beyond visiting a maliciously crafted page if cross-site scripting vectors are also present, though the primary vector here is likely direct manipulation of cookies via network requests. By forging valid session tokens using the known hard-coded key, an attacker can impersonate legitimate users, potentially gaining unauthorized access to administrative panels or sensitive user data. This effectively bypasses authentication mechanisms entirely for any account that relies on cookie-based sessions protected by this flawed validation process.
This issue aligns with CWE-798: Use of Hard-coded Credentials and CWE-321: Use of a Key That is Not Random, as the root cause lies in the failure to generate unique, random secrets for each deployment environment. In terms of offensive security frameworks, this vulnerability facilitates actions categorized under MITRE ATT&CK technique T1078: Valid Accounts, specifically when used to maintain persistence or escalate privileges by impersonating existing users. The lack of response from the project maintainers despite early notification exacerbates the risk profile, leaving a large number of deployments vulnerable without an official patch available in the short term.
Mitigation strategies must focus on immediate remediation steps since no upstream fix has been released. Administrators should manually edit the environments/prod/backend/config/main-local.php file to replace the hard-coded cookieValidationKey with a strong, randomly generated string unique to that specific instance. It is crucial to ensure this key is not committed to public version control repositories and is instead managed through secure environment variable injection or secret management tools. Additionally, forcing all users to log out by changing the validation key will invalidate any existing forged sessions held by attackers who may have already exploited this weakness. Regular audits of configuration files for hardcoded secrets are recommended as part of a broader security hygiene practice to prevent similar misconfigurations in future updates.