CVE-2025-63739
BaseFortify
Publication date: 2025-12-09
Last updated on: 2025-12-12
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| rockoa | rockoa | 2.7.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the phpinisaveAction function of the Xinhu Rainrock RockOA 2.7.0 software. It allows authenticated users to modify PHP configuration files by exploiting the 'a' parameter in the index.php endpoint.
How can this vulnerability impact me? :
An attacker who is authenticated can modify PHP configuration files, which could lead to unauthorized changes in the server's behavior, potentially compromising the security, stability, or functionality of the affected system.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided resources do not contain information regarding the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking for the presence of the phpinfo() endpoint and attempts to access or modify PHP configuration via the vulnerable endpoints. Specifically, you can monitor for GET requests to /index.php?a=phpinfo&m=index to gather php.ini path information, and POST requests to /index.php?a=phpinisave&m=cogini&d=system with parameters like upload_max_filesize, post_max_size, memory_limit, etc. Commands to detect this might include using network monitoring tools or web server logs to search for these requests. For example, using grep on web server logs: grep 'index.php?a=phpinfo&m=index' /var/log/apache2/access.log and grep 'index.php?a=phpinisave&m=cogini&d=system' /var/log/apache2/access.log. Additionally, you can use tools like curl to test the endpoints manually: curl -i 'http://yourserver/index.php?a=phpinfo&m=index' to check if phpinfo() is accessible, and curl -X POST -d 'upload_max_filesize=100M' 'http://yourserver/index.php?a=phpinisave&m=cogini&d=system' to test if configuration changes are accepted without proper authorization. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting access to the vulnerable endpoints by implementing proper authentication and authorization checks, especially for the phpinisaveAction endpoint. Disable or restrict access to the phpinfo() endpoint to prevent information disclosure of php.ini paths and configuration. Additionally, review and harden PHP configuration to prevent unauthorized modifications, and monitor for suspicious POST requests attempting to change PHP settings. Applying patches or updates from the vendor that fix the vulnerability is also critical once available. If patching is not immediately possible, consider blocking or filtering requests to /index.php?a=phpinisave&m=cogini&d=system at the web server or firewall level to prevent exploitation. [1]