CVE-2025-56748
BaseFortify
Publication date: 2025-10-15
Last updated on: 2025-10-21
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| creativeitem | academy_lms | to 5.13 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-640 | The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in Creativeitem Academy LMS up to version 5.13 involves password reset tokens that are generated using a predictable pattern. The tokens are Base64 encoded strings composed of the user's email, a fixed template string, and a random integer within a known range. Because these tokens are predictable and there is no rate limiting on password reset attempts, attackers can perform brute force attacks to guess valid tokens. Successfully guessing a token allows an attacker to reset the password and gain unauthorized access to user accounts. [1]
How can this vulnerability impact me? :
The vulnerability can lead to unauthorized access to user accounts, including administrative accounts, potentially resulting in full system compromise. Attackers can automate brute force attacks to compromise many accounts, bypassing authentication mechanisms. This can lead to loss of control over the LMS platform and exposure of sensitive user data. [1]
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 requests to the password reset endpoints, specifically `GET /lms/login/change_password` and `POST /lms/login/forgot_password_request`. Look for unusually high volumes of reset attempts from the same IP or targeting the same user accounts, indicating brute force activity. Additionally, inspecting logs for repeated token validation attempts can help identify exploitation. While no specific commands are provided, using tools like `grep` or `awk` on web server logs to filter these endpoints and count requests per IP or user can be effective. For example, a command to count reset requests per IP might be: `grep '/lms/login/forgot_password_request' access.log | awk '{print $1}' | sort | uniq -c | sort -nr`. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1) Implement strict rate limiting on password reset attempts, such as limiting to 5 attempts per hour per IP or email address to prevent brute force attacks. 2) Replace the current predictable token generation with cryptographically secure random tokens (e.g., 32 bytes from `random_bytes()` converted to hex). 3) Enforce short expiration times for reset tokens (e.g., 15 minutes) and store tokens hashed in the database. 4) Use one-time tokens that are invalidated after use. 5) Add CAPTCHA challenges after failed reset attempts to block automated attacks. 6) Log and monitor reset attempts and notify users of reset requests to detect suspicious activity early. [1]