CVE-2025-15121
Unknown Unknown - Not Provided
Information Disclosure via Parameter Manipulation in JeecgBoot getDeptRoleByUserId

Publication date: 2025-12-28

Last updated on: 2025-12-28

Assigner: VulDB

Description
A vulnerability has been found in JeecgBoot up to 3.9.0. The affected element is the function getDeptRoleByUserId of the file /sys/sysDepartRole/getDeptRoleByUserId. Such manipulation of the argument departId leads to information disclosure. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-28
Last Modified
2025-12-28
Generated
2026-05-07
AI Q&A
2025-12-28
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
jeecg jeecgboot 3.9.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-284 The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
CWE-200 The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in JeecgBoot up to version 3.9.0, specifically in the function getDeptRoleByUserId located in the file /sys/sysDepartRole/getDeptRoleByUserId. The issue arises from manipulation of the argument departId, which leads to information disclosure.


How can this vulnerability impact me? :

The vulnerability can lead to information disclosure, meaning that unauthorized users might gain access to sensitive information by exploiting the manipulation of the departId argument in the affected function.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows unauthorized cross-tenant access to sensitive permission and organizational data, including user role authorizations and department affiliations. Such unauthorized disclosure of sensitive information can lead to violations of data protection regulations like GDPR and HIPAA, which mandate strict controls on access to personal and organizational data. The exposure of cross-tenant user permission data increases the risk of privacy breaches and unauthorized data processing, potentially impacting compliance with these standards. Remediation involves enforcing tenant ownership validation, access control, and audit logging to prevent unauthorized data disclosure. [1, 2]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring and analyzing API requests to the endpoint `/sys/sysDepartRole/getDeptRoleByUserId` for suspicious or unauthorized queries involving `userId` and `departId` parameters from different tenants. Detection involves checking for cross-tenant access attempts where a user from one tenant queries data belonging to another tenant. Commands to detect such activity could include capturing and inspecting HTTP GET requests to this endpoint, for example using tools like curl or network monitoring tools. Example command to test the vulnerability manually: `curl -i -X GET 'https://<target>/sys/sysDepartRole/getDeptRoleByUserId?userId=<otherTenantUserId>&departId=<otherTenantDepartId>' -H 'Authorization: Bearer <valid_token>'`. Additionally, audit logs should be reviewed for role query operations involving cross-tenant data access attempts. Network intrusion detection systems (NIDS) can be configured to alert on such suspicious API calls. [1, 2]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include: 1) Implement tenant ownership validation by verifying that the `departId` and `userId` parameters belong to the current authenticated user's tenant before processing the request. 2) Enforce tenant filtering in all database queries related to roles and users to prevent cross-tenant data leakage. 3) Restrict ordinary users to querying only their own role authorizations; only administrators should be allowed to query others. 4) Enable audit logging for all role query operations, especially those involving cross-tenant data access attempts. If immediate code changes are not possible, consider restricting access to the vulnerable API endpoint or applying network-level controls to limit access. Monitoring and alerting on suspicious API usage should also be implemented. [1, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart