CVE-2025-63523: 
PHP vulnerability analysis and mitigation

CVE-2025-63523 is a parameter tampering vulnerability in FeehiCMS version 2.1.1 that allows authenticated attackers to modify parameters presented to clients as read-only, specifically enabling unauthorized username changes. The vulnerability was disclosed on December 1, 2025, and affects only FeehiCMS version 2.1.1. It carries a CVSS v3.1 base score of 6.5 (Medium) per Feedly threat intelligence data, though the original researcher assessed it as Low (3.5) (GitHub Issue, Feedly).

The root cause is a failure to enforce server-side immutability for parameters marked as read-only in the client interface (CWE-125 is listed, though the vulnerability more accurately reflects improper server-side input validation / parameter tampering). The backend user management module accepts the username parameter in update requests without validating whether it should be immutable, meaning an authenticated attacker can intercept an HTTP update request and inject the username field to overwrite another user's username. Exploitation requires an authenticated session with access to the backend user module, and no additional privileges beyond a standard authenticated user are needed (GitHub Issue, PoC Write-up).

Successful exploitation allows an authenticated attacker to arbitrarily change usernames of any user account managed through the backend, potentially disrupting account integrity and enabling identity-related attacks such as account confusion or impersonation. The confidentiality and integrity impacts are low — no sensitive data is directly exposed, but unauthorized account modifications could facilitate further privilege escalation or social engineering. Availability is not impacted (GitHub Issue, Feedly).

Public proof-of-concept (PoC) exploit details are available on GitHub, demonstrating the parameter tampering technique step by step. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is 0.00030 (very low probability of exploitation), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (PoC Write-up, Feedly).

1. Authenticate: Log in to the FeehiCMS backend with any valid authenticated user account.
2. Navigate to user module: Access the backend user management module and select a target user record to edit.
3. Intercept the update request: Use a web proxy tool (e.g., Burp Suite) to intercept the HTTP request sent when saving/updating the user record.
4. Inject the username parameter: Add or modify the username parameter in the intercepted request body (the field is rendered as read-only in the UI but is not validated server-side).
5. Forward the modified request: Send the tampered request to the server; the backend accepts the change and updates the target user's username to the attacker-supplied value.
6. Verify the change: Confirm the username has been altered by reviewing the user record in the backend (GitHub Issue, PoC Write-up).

• Logs: Web server or application logs showing HTTP POST/PUT requests to the user update endpoint containing an unexpected username parameter not normally submitted by the frontend UI.
• Application Data: Unexpected or unauthorized changes to usernames in the FeehiCMS user database, particularly changes not initiated by an administrator.
• Network: Anomalous HTTP requests to backend user management endpoints with additional parameters beyond the standard form fields, potentially intercepted via WAF or proxy logs (GitHub Issue).

The recommended remediation is to upgrade FeehiCMS beyond version 2.1.1, as a patch reference has been noted in the project's GitHub repository. As a workaround, administrators should implement strict server-side validation to whitelist only permitted parameters for user update operations and explicitly omit or ignore the username field on the server side during update processing. Additionally, enforcing HTTPS to reduce interception risk and conducting a review of all read-only parameter handling in the application is advised (GitHub Issue, Feedly).