CVE-2025-42616
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-08

Last updated on: 2025-12-08

Assigner: ENISA

Description
Some endpoints in vulnerability-lookup that modified application state (e.g. changing database entries, user data, configurations, or other privileged actions) may have been accessible via HTTP GET requests without requiring a CSRF token. This flaw leaves the application vulnerable to Cross-Site Request Forgery (CSRF) attacks: an attacker who tricks a logged-in user into visiting a malicious website could cause the user’s browser to issue GET requests that perform unintended state-changing operations in the context of their authenticated session. Because the server would treat these GET requests as valid (since no CSRF protection or POST method enforcement was in place), the attacker could exploit this to escalate privileges, change settings, or carry out other unauthorized actions without needing the user’s explicit consent or awareness.Β  The fix ensures that all state-changing endpoints now require HTTP POST requests and include a valid CSRF token. This enforces that state changes cannot be triggered by arbitrary cross-site GET requests.Β This issue affects Vulnerability-Lookup: before 2.18.0.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-08
Last Modified
2025-12-08
Generated
2026-05-07
AI Q&A
2025-12-08
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
vulnerability-lookup vulnerability-lookup *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-352 The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a Cross-Site Request Forgery (CSRF) issue in the vulnerability-lookup application. Some endpoints that modify application state (such as changing database entries, user data, or configurations) were accessible via HTTP GET requests without requiring a CSRF token. This means an attacker could trick a logged-in user into visiting a malicious website, causing the user's browser to send GET requests that perform unintended state-changing actions without the user's consent or awareness. The server treated these GET requests as valid because there was no CSRF protection or enforcement of POST methods for state-changing operations.


How can this vulnerability impact me? :

This vulnerability can allow an attacker to perform unauthorized actions on behalf of a logged-in user without their knowledge. Specifically, the attacker could escalate privileges, change settings, or carry out other unauthorized state-changing operations by exploiting the lack of CSRF protection on GET requests. This could lead to compromised user accounts, altered application configurations, or other malicious changes within the application.


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

You can detect this vulnerability by monitoring HTTP GET requests to endpoints that modify application state without requiring CSRF tokens. Look for GET requests that perform actions such as changing database entries, user data, or configurations. Commands like using curl or wget to test endpoints for state-changing operations via GET requests can help. For example, you might run: curl -v -X GET "http://yourserver/endpoint" and observe if the request changes state without requiring a CSRF token or POST method. Additionally, reviewing server logs for GET requests that result in state changes can help identify vulnerable endpoints.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include ensuring that all state-changing endpoints require HTTP POST requests instead of GET requests and enforce the presence of a valid CSRF token. Updating the Vulnerability-Lookup application to version 2.18.0 or later, where this fix is implemented, is recommended. Until the update is applied, consider implementing additional CSRF protections such as validating CSRF tokens on all state-changing requests and restricting the use of GET methods for operations that modify application state.


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