CVE-2026-34460
OAuth Login CSRF in NamelessMC
Publication date: 2026-06-02
Last updated on: 2026-06-02
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| namelessmc | namelessmc | to 2.2.5 (exc) |
| namelessmc | namelessmc | 2.2.5 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-346 | The product does not properly verify that the source of data or communication is valid. |
| 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. |
| CWE-302 | The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The CVE-2026-34460 vulnerability affects NamelessMC versions 2.2.4 and earlier. It occurs because the OAuth callback handling does not validate the 'state' parameter on the server side before exchanging the authorization code.
This flaw allows an attacker to capture a valid OAuth callback URL linked to their own account and trick a victim into navigating to it. As a result, the victim's session becomes authenticated as the attacker's account, effectively swapping the victim's session with the attacker's.
The root cause is that the application does not store or compare the OAuth state value during the callback process, enabling login CSRF (Cross-Site Request Forgery) or session swapping attacks.
How can this vulnerability impact me? :
This vulnerability can lead to an attacker hijacking a victim's session by causing the victim's browser to authenticate as the attacker's account on the NamelessMC website.
Such session swapping can result in unauthorized access to the victim's session, potentially allowing the attacker to perform actions or access information under the victim's identity.
Because the attacker can control the session, this may lead to privacy breaches, manipulation of user data, or other malicious activities within the affected application.
What immediate steps should I take to mitigate this vulnerability?
To mitigate the CVE-2026-34460 vulnerability in NamelessMC versions 2.2.4 and earlier, you should upgrade to version 2.2.5 or later where the issue is patched.
The vulnerability arises because the OAuth callback handling does not validate the state parameter server-side, allowing session swapping attacks.
The recommended fix involves generating a cryptographically random state parameter for each authorization request, storing it server-side, and validating it during the OAuth callback before exchanging the authorization code for a token.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an attacker to perform OAuth login CSRF or session swapping, which can lead to unauthorized access to user sessions.
Such unauthorized access could potentially result in exposure or misuse of personal data, which may impact compliance with data protection regulations like GDPR or HIPAA that require safeguarding user authentication and session integrity.
However, the provided information does not explicitly discuss the direct impact on compliance with these standards.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the OAuth callback handling in NamelessMC not validating the state parameter server-side, which is a logic flaw in the web application. Detection typically requires inspecting the application code or behavior rather than simple network commands.
To detect if your NamelessMC instance is vulnerable, verify the version is 2.2.4 or earlier, as the issue is patched in version 2.2.5.
For network or system detection, you can monitor OAuth callback URLs for missing or unvalidated state parameters. For example, you could capture HTTP requests to the OAuth callback endpoint and check if the state parameter is present and validated.
Suggested commands to capture and inspect OAuth callback requests include:
- Using tcpdump to capture HTTP traffic on port 80 or 443 (if not encrypted): tcpdump -i any -A 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
- Using tshark to filter HTTP requests to the OAuth callback endpoint (replace /oauth/callback with actual path): tshark -Y 'http.request.uri contains "/oauth/callback"' -T fields -e http.request.uri
- Using curl or browser developer tools to manually test the OAuth flow and observe if the state parameter is used and validated.
Ultimately, confirming the vulnerability requires checking the application version or reviewing the OAuth callback implementation to ensure the state parameter is generated, stored, and validated server-side.