CVE-2025-55795
BaseFortify
Publication date: 2025-09-29
Last updated on: 2025-10-16
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openml | openml.org | to 2.0.20241110 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
| CWE-639 | The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the OpenML web application allows an authenticated attacker with a lower user ID to change their email address to that of another user with a higher user ID without proper verification. Because user IDs are incremental and predictable, the attacker can identify victim accounts and update their email to the victim's email. This causes the victim's account to be locked out immediately, as their email is reassigned to the attacker’s account. The attacker does not gain direct access to the victim's private data but causes a denial-of-service by locking the victim out. [1]
How can this vulnerability impact me? :
The vulnerability can impact you by causing a denial-of-service condition where your account is locked out if an attacker reassigns your email to their account. This means you would lose access to your account immediately and be unable to log in. Although the attacker does not gain direct access to your private data, they effectively hijack your account's email identity, preventing you from using your account. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection can focus on monitoring suspicious email change activities on the affected endpoint `/profile`. Look for authenticated requests where a user updates their email address to one already in use by another account, especially involving incremental user IDs. Commands to detect such activity depend on your logging system, but for example, using grep on web server logs: `grep '/profile' access.log | grep 'email='` to find email update attempts. Additionally, monitoring for multiple email changes from accounts with low user IDs targeting higher user ID accounts may indicate exploitation attempts. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include enforcing strict email ownership verification before allowing email updates, such as requiring confirmation via the original email address or multi-factor verification. Prevent duplicate email addresses across accounts to avoid reassignment. Avoid relying on incremental user IDs for critical workflows. Implement monitoring and alerting for suspicious email change activities. Since no patched versions are available yet, consider restricting or disabling email update functionality temporarily if possible. [1]