CVE-2026-27804: Critical Parse Server Flaw Lets Hackers Bypass Google Login Using “alg: none” JWT Trick

CVE Information

CVE ID: CVE-2026-27804
Severity: Critical
CVSS Score: 9.3 (Network exploitable, no authentication required, high impact on confidentiality and integrity)
Attack Vector: Remote
Privileges Required: None
User Interaction: None
Scope: Unchanged
Impact: Account takeover of users authenticated via Google

Exploitability: High (low complexity, no prior access required)
Exploit Availability: No official public exploit released at time of disclosure, however exploitation is technically straightforward and reproducible in controlled environments.

Overview

A critical authentication bypass vulnerability was identified in Parse Server’s Google authentication implementation. Improper handling of JSON Web Token (JWT) verification allowed the alg (algorithm) field supplied within the token header to dictate how verification was performed.

Because the algorithm value from the attacker-controlled token header was trusted, tokens specifying alg: none could bypass signature validation entirely. As a result, an unsigned and attacker-crafted JWT could be accepted as legitimate.

Any Parse Server deployment with Google authentication enabled and running a vulnerable version could allow unauthenticated attackers to log in as arbitrary users associated with Google accounts.

This issue effectively results in full account compromise without requiring valid credentials.

Affected Versions

Parse Server versions prior to 8.6.3
Parse Server versions prior to 9.3.1-alpha.4

Any deployment using Google OAuth authentication in these versions is considered vulnerable.

Technical Root Cause

JWT authentication relies on cryptographic signatures to verify authenticity. In secure implementations:

The expected algorithm (e.g., RS256) must be enforced server-side.
The token header must not be trusted to define verification behavior.
Signature validation must fail if algorithm mismatch occurs.

In the vulnerable implementation:

The alg field from the JWT header was extracted.
That value was passed into the verification routine.
If alg was set to "none", signature validation was effectively skipped.
The token payload was accepted as valid if required claims were present.

Because JWT headers are entirely attacker-controlled, this design flaw created a classic algorithm confusion vulnerability.

Instead of enforcing RS256 verification against Google’s public keys, the server accepted unsigned tokens.

Exploitation Scenario

The attack requires only network access to a Parse endpoint that supports Google login.

Step-by-step attack flow

A target user is identified who has previously authenticated using Google.
A forged JWT is constructed:
- Header: {"alg":"none"}
- Payload: Contains a Google issuer (iss), subject (sub), and email matching the target.
- Signature: Empty (since alg is none).
The forged token is sent to the Parse authentication endpoint.
The server processes the token.
Because alg: none is accepted, no signature verification occurs.
A valid session is issued for the target user.

No brute force, credential stuffing, phishing, or prior access is required.

Proof of Concept (Educational)

The following demonstrates how a vulnerable environment may be tested in a controlled lab setting.

JWT Structure

Header:

{"alg":"none","typ":"JWT"}

Payload:

{
  "iss": "https://accounts.google.com",
  "sub": "123456789012345678901",
  "email": "[email protected]",
  "email_verified": true
}

Encoded format (signature intentionally empty):

Base64Url(header).Base64Url(payload).

If accepted by the server, the vulnerability is confirmed.

Testing must only be performed in environments you own or have written authorization to assess.

Impact Assessment

If exploited successfully:

Unauthorized login as any Google-linked user
Access to stored personal data
Ability to modify application data
Privilege escalation (if admin accounts use Google login)
Potential lateral movement inside application ecosystem

No evidence of data destruction was observed as part of this flaw, but integrity and confidentiality risks are severe.

MITRE Classification

CWE-327 – Use of a Broken or Risky Cryptographic Algorithm
CWE-345 – Insufficient Verification of Data Authenticity

MITRE ATT&CK Technique:

T1078 – Valid Accounts (abuse of improperly validated authentication tokens)

Detection and Threat Hunting

Detection depends heavily on logging configuration. Since JWT bodies are not always logged, behavioral detection becomes critical.

Primary Indicators

Successful Google login events with malformed or unsigned tokens.
Authentication logs lacking signature verification traces.
Login spikes targeting multiple Google-linked accounts from a single IP.
Tokens containing "alg":"none".

Log Sources to Monitor

Parse Server application logs
Reverse proxy logs (Nginx, Apache, API Gateway)
Cloud provider logs (AWS ALB, CloudFront, etc.)
Identity provider verification logs
SIEM authentication index

Detection Queries

Splunk – Detect `alg:none` in Requests

index=web_logs
| search http_method=POST AND (uri_path="/users" OR uri_path="/auth/google")
| search request_body="*\"alg\":\"none\"*"
| stats count by client_ip, uri_path, user_agent, _time

Splunk – Detect Suspicious Google Login Success

index=parse_logs
| search "GoogleAuth" AND "login success"
| stats count by user, src_ip
| where count > 5

Elastic (KQL) – JWT Algorithm None Detection

http.request.method:POST AND 
http.request.body:"\"alg\":\"none\""

Elastic – Abnormal Login Volume

event.category:authentication AND 
authentication.method:"google" 
| stats count() by source.ip, user.name 
| where count > 10

Indicators of Compromise

JWT header containing alg:none
Empty signature segment in token
Google authentication success without signature verification logs
Unusual account logins from new geolocations

Incident Response Recommendations

Immediately disable Google authentication if patching is delayed.
Upgrade to a fixed version.
Invalidate active sessions created during vulnerable window.
Reset credentials or re-verify linked Google accounts if compromise is suspected.
Review privileged accounts first.

Remediation

The vulnerability was corrected by:

Hardcoding the expected JWT algorithm (RS256).
Implementing strict algorithm validation.
Switching to secure JWKS key retrieval and verification logic.
Rejecting unsigned tokens categorically.

Official Patch Links

Parse Server 8.6.3:
https://github.com/parse-community/parse-server/releases/tag/8.6.3

Parse Server 9.3.1-alpha.4:
https://github.com/parse-community/parse-server/releases/tag/9.3.1-alpha.4

Only official releases from the Parse Server repository should be used for upgrade.

Hardening Recommendations

Never trust JWT header parameters.
Enforce expected algorithms explicitly in server configuration.
Reject alg:none at application firewall level.
Enable structured authentication logging.
Implement rate limiting on authentication endpoints.
Apply anomaly detection for identity events.
Enforce MFA for administrative accounts.

Risk Summary

This vulnerability represents a complete breakdown of authentication integrity for affected deployments. Because exploitation requires only a crafted HTTP request and no credentials, exposure should be treated as critical until patched.

Organizations operating internet-facing Parse Server instances with Google authentication enabled should prioritize immediate remediation and log review.