CVE-2025-10084
BaseFortify
Publication date: 2025-09-08
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| eladmin | eladmin | to 2.7 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-285 | The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. |
| CWE-266 | A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-10084 is a Broken Function Level Authorization vulnerability in the elunez eladmin software up to version 2.7. It affects the queryErrorLogDetail function in the SysLogController component, which handles requests to the API endpoint /api/logs/error/{id}. The vulnerability arises because the function does not perform proper authorization or ownership checks on the requested error log ID. This means any authenticated user can access error log details belonging to other users without permission, potentially exposing sensitive information. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability allows an authenticated attacker to view error logs generated by other users without proper authorization. Accessing these logs can expose sensitive information that may be leveraged for further attacks or privilege escalation. The exploit is remotely executable and publicly available, increasing the risk of unauthorized data disclosure and potential compromise of confidentiality. [1, 2, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to access the API endpoint `/api/logs/error/{id}` with a valid authorization token for different log IDs to check if unauthorized access is possible. A simple detection command would be to send GET requests to `/api/logs/error/{id}` with varying IDs using tools like curl or HTTP clients, for example: `curl -H "Authorization: Bearer <token>" https://<target>/api/logs/error/1` and then changing the ID to other values to see if error logs of other users are accessible without proper authorization. [1, 2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting access to the vulnerable API endpoint `/api/logs/error/{id}` to only authorized users with proper ownership checks. Since no known mitigations or patches are published yet, consider disabling or restricting the SysLogController's queryErrorLogDetail function or applying access control rules at the network or application firewall level. Additionally, consider replacing or upgrading the affected product if possible. [3]