CVE-2026-37504
Sensitive Server Token Exposure in V2Board via GET Parameter
Publication date: 2026-05-01
Last updated on: 2026-05-01
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| v2board | v2board | 1.7.4 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-598 | The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
If an attacker obtains the exposed server token from logs or other sources, they can impersonate a proxy server node within the system.
This impersonation allows the attacker to potentially intercept all user traffic passing through the proxy, leading to serious confidentiality breaches.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability exposes sensitive server authentication tokens via GET parameters, which are logged in various places such as web server access logs, browser history, HTTP Referer headers, and proxy/CDN logs. This exposure can lead to unauthorized access and impersonation of proxy server nodes, potentially allowing interception of user traffic.
Such exposure of sensitive authentication tokens can lead to violations of data protection regulations like GDPR and HIPAA, which require the protection of sensitive data and user privacy. Logging sensitive tokens in accessible logs and histories increases the risk of data breaches and unauthorized data access, which are non-compliant with these standards.
To comply with these regulations, sensitive tokens should not be transmitted via URL parameters but rather through more secure methods such as request headers or POST bodies, minimizing exposure in logs and histories.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring web server access logs, proxy/CDN logs, and browser histories for URLs containing the server_token as a GET parameter, such as /api/v1/server/UniProxy/user?token=SECRET.
Commands to detect this might include searching log files for the token parameter in URLs. For example, using grep on Linux systems:
- grep -r "token=" /var/log/nginx/access.log
- grep -r "token=" /var/log/apache2/access.log
- grep -r "token=" /path/to/proxy/logs/
These commands search for occurrences of the token parameter in the logs, which indicates exposure of the sensitive server_token.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves stopping the transmission of the server_token via GET parameters in URLs.
Specifically, the token acceptance should be moved from URL query parameters to more secure methods such as request headers or POST request bodies, which are not logged or cached in the same way.
Additionally, reviewing and purging logs that may contain the exposed tokens is recommended to prevent attackers from retrieving them.
Can you explain this vulnerability to me?
This vulnerability involves the exposure of a sensitive server authentication token in V2Board versions up to 1.7.4. The token is transmitted via a GET parameter in URLs, such as /api/v1/server/UniProxy/user?token=SECRET. Because the token appears in the URL, it can be recorded in various places like web server access logs, browser history, HTTP Referer headers, and proxy or CDN logs.
An attacker who gains access to any of these logs can extract the token and use it to impersonate a proxy server node.