CVE-2021-29455

Executive Summary

CVE-2021-29455 is a JSON Web Token (JWT) signature verification bypass vulnerability affecting Grassroot Platform, an open-source application designed for organizing and mobilizing communities in low-income settings. Versions prior to 1.3.1 (and the master deployment as of 2021-04-16) fail to properly verify the cryptographic signature of JWTs when an existing token is refreshed, allowing an unauthenticated attacker to forge a valid token and gain unauthorized access to the application. The vulnerability carries a CVSS score of 7.5 (High) and was patched in version 1.3.1, although patch confidence remains at 2/4 (CLAIMED) with only a single source confirming the fix. No public exploits have been observed as of the reporting date, and the CVE is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog.

Technical Analysis

Grassroot Platform operates as a web-based system that facilitates community organizing, group communication, and decision-making processes. The application relies on JSON Web Tokens (JWTs) as a stateless authentication mechanism, allowing users to authenticate once and maintain a session without repeatedly transmitting credentials.

The vulnerability resides in the token refresh mechanism. In typical JWT-based authentication architectures, access tokens are short-lived (minutes to hours) and are accompanied by a longer-lived refresh token. When the access token expires, the client presents the refresh token to a dedicated endpoint, which validates the refresh token's signature and issues a new access token. The critical flaw in Grassroot Platform versions prior to 1.3.1 is that the signature of the incoming JWT is not verified during the refresh operation. Specifically, the application does not properly validate the cryptographic signature of JSON Web Tokens when refreshing an existing JWT.

This missing validation introduces a signature-bypass vulnerability. An attacker who obtains any valid JWT (or observes one in transit) can modify the token's claims — such as the user identifier, role, or expiration timestamp — without possessing the secret key used to sign legitimate tokens. Because the refresh endpoint fails to verify the signature, the modified token is accepted as valid, and the application issues a new, legitimate token based on the attacker-controlled claims. Effectively, the attacker can forge a valid JWT with arbitrary claims and gain privileges they are not entitled to.

It is important to note that the NVD description does not specify the exact code path, function names, or endpoint URLs involved in this flaw. The description indicates that the refresh flow has been deprecated in version 1.3.1, noting that the "refresh" flow is no longer used by the application. This deprecation suggests that the refresh mechanism was a legacy feature that had been superseded by other authentication flows, but its continued presence in the codebase introduced a security risk.

From an attack surface perspective, the vulnerability is remotely exploitable over the network. No authentication is required to trigger the flaw — an attacker only needs to reach the application's token refresh functionality. The complexity of exploitation is low: the attacker must craft a JWT with modified claims, a process well understood within the security community, and submit it to the refresh endpoint. There are no user interaction requirements, making this vulnerability attractive for automated exploitation.

The CWE classification is not provided in the CVE data, but the vulnerability maps most directly to CWE-347 (Improper Verification of Cryptographic Signature), which covers scenarios where software fails to verify that a cryptographic signature is valid before trusting the signed data. An alternative mapping could be CWE-345 (Insufficient Verification of Data Authenticity).

The CVSS vector, while not explicitly provided, is consistent with a network-exploitable vulnerability requiring no privileges and no user interaction, with high confidentiality impact but limited integrity and availability impact. The 7.5 score reflects the potential for complete authentication bypass and unauthorized data access.

Exploitation Scenarios

The following attack chain is inferred from the vulnerability class and the NVD description. No public PoC exists, and specific implementation details (endpoint paths, parameter names, payload structures) are not disclosed in the available data. Consequently, the steps below describe the attack at the class level.

Step 1 — Reconnaissance/Target Identification. An attacker identifies a Grassroot Platform instance exposed to the internet. Discovery can occur through Shodan queries targeting platform-specific banners, default ports, or known login pages. The attacker may also use application fingerprinting techniques, such as analyzing the login response headers or identifying JWT-bearing cookies/localStorage tokens in the client-side code. Grassroot Platform's open-source nature allows an attacker to review the source code (pre-patch) to locate the refresh-endpoint logic and understand the exact request format required.

Step 2 — Triggering the Signature Verification Bypass. The attacker obtains a valid JWT from the target application. This may be achieved by registering a legitimate account (if self-registration is enabled) or by intercepting a token in transit (e.g., through a man-in-the-middle attack on an unencrypted channel). Once a valid token is acquired, the attacker decodes the JWT payload (the base64-encoded middle segment) and modifies the claims — for example, changing the "sub" (subject) claim to an administrator's user identifier or adding elevated role claims. The attacker then re-encodes the header and payload but does not re-sign the token (or provides a dummy signature). Because the target application fails to verify the signature during the refresh operation, the forged token is accepted.

Step 3 — Payload/Execution at the Vulnerability-Class Level. The attacker submits the forged token to the application's JWT refresh endpoint. The application, lacking signature verification, processes the token as valid. It then issues a new access token that reflects the attacker-modified claims. This newly issued token is cryptographically valid (properly signed by the application's secret), meaning the attacker now holds a legitimate, signed token granting the privileges encoded in their forged claims.

Step 4 — Post-Exploitation Impact. With a valid token containing elevated or arbitrary user claims, the attacker can impersonate any user, including administrators. Depending on the application's feature set, this could allow: reading sensitive community member data, modifying group membership, deleting or altering organizing campaigns, sending messages as another user, or extracting PII of community organizers and members. The persistence of the compromise depends on the token's expiration (which the attacker can control by extending the "exp" claim) and whether the application revokes issued tokens on user logout. The attacker can also use the forged token to access any API endpoints protected by JWT authentication, potentially chaining this vulnerability with other application-specific attack vectors.

Note on Exploit Availability. No public PoC or exploit code exists as of this writing. The attack chain is inferred from the vulnerability class (JWT signature verification bypass) and the well-documented JWT attack techniques. The lack of public exploits may be attributable to the application's niche audience (community organizing in low-income regions) rather than the absence of exploitability.

Impact Assessment

The business impact of CVE-2021-29455 is significant for organizations deploying Grassroot Platform, particularly given the application's purpose in serving low-income communities. The primary impact is authentication bypass, allowing an attacker to forge valid JWTs and impersonate any user within the system.

From a confidentiality standpoint (the predominant CVSS sub-score impact), the attacker can access all data visible to the impersonated user. In a community-organizing platform, this typically includes: member lists with names, phone numbers, addresses, and other PII; group communication histories and messages; campaign and event details; decision-making records; and potentially financial or donation information. The sensitivity of this data is elevated because the platform serves vulnerable populations — low-income community members may be at risk of targeting, discrimination, or harassment if their organizing activities are exposed.

Integrity impact is moderate but non-trivial. The attacker can modify data through authenticated API calls, potentially altering group membership, changing campaign details, or injecting misinformation into organizational communications. In authoritarian contexts where community organizing is restricted, this could have serious real-world consequences, including putting activists at risk.

Availability impact is low, as the vulnerability does not directly enable denial-of-service or system downtime. However, an attacker with administrative access could delete critical data or disable accounts, indirectly affecting availability.

The blast radius is constrained to a single Grassroot Platform instance. The application does not appear to have a centralized multi-tenant architecture (it is a standalone platform), so a compromise does not directly affect other deployments. However, if the platform integrates with external services (e.g., SMS gateways, email providers), the attacker may pivot through the compromised instance to reach those services.

The CVSS score of 7.5 (High) reflects the network exploitability, low attack complexity, and high confidentiality impact. The EPSS score of 0.00757 (51.9th percentile) indicates that exploitation is currently unlikely but not unheard of — the vulnerability sits slightly above the median in terms of predicted exploitation probability, likely due to the niche nature of the product. The absence of the CVE from CISA's KEV catalog confirms there is no confirmed in-the-wild exploitation as of the reporting date.

Detection Guidance

The following detection rules are designed to identify exploitation attempts against Grassroot Platform's JWT refresh endpoint. Because the vulnerability exists in a signature validation logic flaw, detection focuses on anomalous JWT requests — specifically, tokens with modified signatures, unusual claim values, or repeated refresh patterns that deviate from normal application usage. These rules are generic enough to apply to any HTTP-based application implementing JWT-based authentication.

Note that without knowledge of the specific endpoint path or request format, rules targeting path patterns may require tuning based on observed legitimate traffic.

Sigma Rule

title: Suspicious JWT Refresh Request with Signature Anomaly
id: 5e3a9b1c-7d4f-4a2e-9c8b-1f6d5a2e4f10
status: experimental
description: >
  Detects JWT refresh requests where the signature portion of the JWT
  appears malformed or uses a non-standard algorithm, potentially
  indicating a signature verification bypass attempt (CVE-2021-29455).
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2021-29455
author: Valtersit Threat Intelligence
date: 2025/01/01
logsource:
    category: webserver
    product: generic
detection:
    selection_jwt_in_request:
        # JWT is typically found in Authorization header, cookie, or POST body
        fields:
            - http.authorization
            - http.request.body
        contains:
            - 'eyJ'  # Base64 prefix for '{"' (JSON header)
    selection_signature_anomaly:
        # Signatures are normally 32-512 chars of base64url with no extra dots
        # Anomaly: token has exactly 3 dot-separated parts but last part is empty
        http.authorization|re: 'eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.$'
    condition: selection_jwt_in_request and selection_signature_anomaly
falsepositives:
    - Legitimate tokens with unusual but valid signatures (rare)
    - Client-side bugs producing malformed tokens
level: high
tags:
    - attack.t1190
    - cve.2021.29455
    - jwt.bypass

YARA Rule

rule JWT_Signature_Bypass_Grassroot
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects JWT tokens with modified claims and invalid signatures indicative of CVE-2021-29455 exploitation"
        cve = "CVE-2021-29455"
        date = "2025-01-01"
        severity = "high"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2021-29455"
    strings:
        // Base64-encoded JWT header with alg:none (common bypass)
        $alg_none = { 61 6c 67 3a 22 6e 6f 6e 65 22 } // "alg":"none"
        $alg_none_caps = { 61 6c 67 3a 22 4e 4f 4e 45 22 } // "alg":"NONE"
        // JWT header with HS256 but misplaced (indicating manual tampering)
        $hs256_header = { 61 6c 67 3a 22 48 53 32 35 36 22 } // "alg":"HS256"
        // Pattern for three-part JWT where third segment (signature) is base64 of 0 bytes
        $empty_sig = { 2e 2e 24 } // "..$" or similar empty signature markers
    condition:
        uint32be(0) == 0x65794a or
        #alg_none > 0 or
        #alg_none_caps > 0 or
        ($hs256_header and #empty_sig > 0)
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2021-29455 Attempt - JWT Refresh with Unverified Signature"; flow:established,to_server; content:"POST"; http_method; content:"refresh"; http_uri; nocase; content:"eyJ"; http_header; name:"Authorization"; pcre:"/eyJ[A-Za-z0-9_-]{5,}\.[A-Za-z0-9_-]{5,}\.$/U"; classtype:attempted-admin; sid:9100001; rev:1; metadata:created_at 2025_01_01, updated_at 2025_01_01, cve CVE-2021-29455, mitre_attack_technique T1190;)

Elastic Detection

/* Detect JWT strings in HTTP requests with empty or malformed signature segments */
sequence by source.ip, user.name with maxspan=5m
  [ network where
    http.request.method == "POST" and
    http.request.bytes > 200 and
    (url.path contains "refresh" or url.path contains "token") and
    wildcard(http.request.body.content, "*eyJ*.*.*") or
    wildcard(http.request.headers.authorization, "eyJ*.*.*")
  ]
  [ network where
    // Look for JWT with 3 parts where third is empty or tiny (< 10 chars base64)
    (wildcard(http.request.headers.authorization, "*.?.?$") or
     string(http.request.headers.authorization).length > 300 and
     string(http.request.headers.authorization).length < 400)
  ]

Splunk SPL Query

index=* sourcetype=access_combined
| where like(authorization, "eyJ%") OR like(form_data, "%eyJ%")
| rex field=authorization "^(?<jwt>[^\s]+)$"
| eval parts=split(jwt, ".")
| eval part_count=mvcount(parts)
| where part_count==3 AND (length(mvindex(parts,2)) < 10 OR mvindex(parts,2) == "")
| eval header_base64=mvindex(parts,0)
| eval payload_base64=mvindex(parts,1)
| eval decoded_header=urldecode(base64_decode(header_base64))
| search decoded_header="*none*" OR decoded_header="*NONE*"
| table _time, src_ip, uri, authorization, decoded_header
| stats count by src_ip, uri
| where count > 5
| sort - count

Wazuh OSSEC Rule

<group name="grassroot-jwt,">
  <rule id="253435" level="12">
    <decoded>
      <prematch>Authorization: eyJ</prematch>
    </decoded>
    <regex>Authorization: eyJ\S+\.\S+\.\S*$</regex>
    <description>CVE-2021-29455: JWT token with missing or malformed signature detected</description>
    <group>authentication_failures,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
    <info type="cve">CVE-2021-29455</info>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence Assessment: 2/4 — CLAIMED. The patch is asserted by the CNA (Grassroot), which indicates that version 1.3.1 fixes the vulnerability. However, this is not independently confirmed by a secondary source. Organizations should validate the patch in their own testing environments before deploying to production.

Immediate Mitigations (to apply immediately if unable to patch):

1. Disable or block the JWT refresh endpoint. If the application allows disabling specific routes, restrict access to any endpoint associated with token refresh. The NVD description notes that the refresh flow is no longer used by the application, suggesting that blocking it should not impact normal operations. Consult your deployment's configuration documentation to identify how to disable this endpoint.
2. Deploy a WAF rule to block requests containing JWTs with malformed signature segments (as defined in the detection rules above). Specifically, block tokens where the third dot-separated segment is empty or contains fewer than 10 base64url characters.
3. Restrict network access to the Grassroot Platform application to trusted IP ranges if possible. Since the vulnerability requires network access to the refresh endpoint, limiting network exposure reduces the attack surface.
4. Monitor logs for anomalous JWT refresh activity, including multiple refresh attempts from the same source IP, tokens with unusual "alg" headers (e.g., "none"), or tokens with modified claims that do not match the expected user profile.

Patch/Upgrade Steps:

1. Upgrade Grassroot Platform to version 1.3.1 or later as soon as feasible. Version 1.3.1 deprecates the JWT refresh function entirely, eliminating the vulnerable code path.
2. Because the patch confidence is 2/4, verify the upgrade in a staging environment and conduct regression testing, especially around authentication flows. Confirm that the refresh endpoint is disabled and that no legacy clients depend on it.
3. If your deployment is source-based, pull the latest master branch from the official repository (commit after 2021-04-16) and rebuild/deploy per your standard process. Verify the specific commit includes the deprecation of the refresh flow.
4. After patching, invalidate all existing JWTs by rotating the application's JWT signing secret. This forces all users to re-authenticate and ensures any previously forged tokens become invalid.

Long-Term Hardening:

• Adopt standards-based JWT libraries that enforce signature verification by default with minimal configuration options.
• Implement short-lived access tokens (5-15 minutes) paired with rotating refresh tokens that are cryptographically bound to the client, reducing the window of opportunity for token forgery.
• Conduct a full code audit of all authentication and session management paths in the application, not just the refresh flow, to identify similar signature verification gaps.
• Enable comprehensive logging on authentication-related endpoints, including token validation failures, to support future forensic analysis.
• Consider a full deprecation of custom JWT handling in favor of an established identity provider (e.g., OAuth 2.0/OIDC) with mature, well-tested implementations.

References

1. NVD Entry — CVE-2021-29455: https://nvd.nist.gov/vuln/detail/CVE-2021-29455
2. Grassroot Platform Official Repository: https://github.com/grassrootza/grassroot-platform (connection failed — verify manually) (patch commit in version 1.3.1, dated 2021-04-16)
3. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2021-29455 not listed — confirms no confirmed in-the-wild exploitation)
4. OWASP JWT Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html (authoritative reference for JWT algorithm confusion and signature verification risks)
5. MITRE ATT&CK Technique T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Threat Actor Campaigns / Exploit-in-the-Wild Evidence: As of the reporting date (January 1, 2025), there are no known threat actor campaigns exploiting CVE-2021-29455. The CVE is not present in the CISA KEV catalog, and no public PoC or exploit code has been identified. The EPSS score of 0.00757 indicates a low but non-zero probability of exploitation, consistent with the application's niche user base (community organizing platforms). Organizations using Grassroot Platform should nevertheless prioritize patching given the high confidentiality impact and the relative ease of exploitation once the vulnerability class is understood.