[Security] Silent coercion of Unicode non-ASCII digit variants in nextInt()/nextLong() bypasses application-level input validation

[the5orcerer]

Attachments

GsonFullWidthHonestTest.java
GsonTypeTest.java
manifest-2.13.2.txt
test-output-2.13.1.txt
test-output-2.13.2.txt

Summary

Gson silently accepts Unicode non-ASCII digit variants (Full-Width, Arabic-Indic, Bengali,
and other Unicode decimal digit blocks) when deserializing JSON values into int and long
fields. This occurs without any exception, warning, or error — even under Strictness.STRICT
mode. The behavior creates a dangerous gap between what application-layer validators observe
in the raw JSON string and what Gson ultimately produces as an integer value.

Affected Versions

• Gson 2.13.1
• Gson 2.13.2 (latest, verified via Bundle-Version: 2.13.2 in MANIFEST.MF)
• Likely all prior versions

Root Cause

Two behaviors combine unsafely:

1. JsonReader.nextInt() / nextLong() accept quoted string tokens for numeric fields
   and pass the raw string directly to Integer.parseInt() / Long.parseLong() without
   any ASCII pre-validation.

2. Integer.parseInt() internally calls Character.digit(c, 10), which recognizes
   any Unicode character designated as a decimal digit — not just ASCII 0-9. This is
   Java spec behavior, but Gson does not guard against it.

This means the string "１２３４５６" (U+FF10–FF15, Full-Width digits) is silently parsed
as the integer 123456.

Notably, double / float fields are not affected because Double.parseDouble() uses
FloatingDecimal internally, which is ASCII-strict and throws NumberFormatException. This
divergence confirms the exact code path and demonstrates this is a Gson-level gap, not a
Java platform issue.

Strictness.STRICT mode does not prevent this. The coercion happens downstream of all
strictness checks, inside parseInt().

Confirmed Vulnerable Input Examples

JSON Input	Field Type	Parsed Value	Unicode Block
{"value": "１２３４５６"}	int	123456	Full-Width Digits (U+FF10–FF19)
{"value": "١٢٣"}	int	123	Arabic-Indic Digits (U+0660–0669)
{"value": "১২৩"}	int	123	Bengali Digits (U+09E6–09EF)
{"value": "1２3"}	int	123	Mixed ASCII + Full-Width
{"value": １２３４５６}	int	123456	Unquoted Full-Width (LENIENT)

Proof of Concept

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.google.gson.ToNumberPolicy;

public class GsonUnicodeDigitPOC {

    static class Payload {
        int value;
    }

    public static void main(String[] args) {
        Gson gson = new Gson();

        // Full-Width digits (U+FF10-FF19)
        String json1 = "{\"value\": \"１２３４５６\"}";
        Payload r1 = gson.fromJson(json1, Payload.class);
        System.out.println("Full-Width: " + r1.value);  // prints 123456

        // Arabic-Indic digits (U+0660-0669)
        String json2 = "{\"value\": \"١٢٣\"}";
        Payload r2 = gson.fromJson(json2, Payload.class);
        System.out.println("Arabic-Indic: " + r2.value);  // prints 123

        // Bengali digits (U+09E6-09EF)
        String json3 = "{\"value\": \"১২৩\"}";
        Payload r3 = gson.fromJson(json3, Payload.class);
        System.out.println("Bengali: " + r3.value);  // prints 123

        // Strictness.STRICT does NOT prevent this
        Gson strictGson = new GsonBuilder()
            .setStrictness(com.google.gson.Strictness.STRICT)
            .create();
        Payload r4 = strictGson.fromJson("{\"value\": \"１２３\"}", Payload.class);
        System.out.println("STRICT mode: " + r4.value);  // still prints 123

        // double is SAFE — for comparison
        try {
            new GsonBuilder().create().fromJson("{\"value\": \"１２３\"}", 
                new Object() { double value; }.getClass());
        } catch (Exception e) {
            System.out.println("double throws: " + e.getClass().getSimpleName()); // throws
        }
    }
}

Security Impact

Any application that validates the raw JSON string before passing it to Gson for
deserialization is vulnerable to a validation bypass. Common patterns at risk:

• OTP / 2FA bypass — regex [0-9]+ passes on raw string, Gson returns valid integer
• WAF / firewall bypass — firewall sees non-numeric Unicode string, backend processes
  as integer
• Financial amount limit bypass — input sanitation runs on raw value, business logic
  runs on parsed integer
• Audit log evasion — raw logs contain Unicode characters, processed values are ASCII
  integers; forensic trail is broken

The validate-then-parse pattern is extremely common in production Java applications, making
this a realistic and exploitable gap in libraries that process untrusted JSON.

Suggested Fix

Add an ASCII digit pre-validation step inside nextInt() and nextLong() before calling
parseInt() / parseLong():

private void validateAsciiDigits(String s) throws IOException {
    int start = (!s.isEmpty() && s.charAt(0) == '-') ? 1 : 0;
    for (int i = start; i < s.length(); i++) {
        char c = s.charAt(i);
        if (c < '0' || c > '9') {
            throw new MalformedJsonException(
                "Expected ASCII digits but found non-ASCII digit: U+" +
                Integer.toHexString(c).toUpperCase() + " at index " + i + locationString()
            );
        }
    }
}

This should be called on the extracted string before passing it to parseInt() in both
nextInt() and nextLong().

Environment

• Gson: 2.13.2 (confirmed via MANIFEST.MF Bundle-Version: 2.13.2)
• Java: OpenJDK 21
• OS: Linux

Thanks,

• rootplinix (Abu Hurayra)
• GitHub: @the5orcerer

[eamonnmcmanus]

While the scenarios in the "Security Impact" section seem somewhat unlikely, I agree that we should fix this. If we don't accept non-ASCII digits in regular JSON numbers ({"value": ১২৩}) then we shouldn't accept them in strings-as-numbers ({"value": "১২৩"}). The validateAsciiDigits suggestion is a bit more than needed: we only need to check whether there are any non-ASCII characters in a string before giving it to Integer.parseInt.

[the5orcerer]

Yerp, i think Integer.parseInt idea would work here. The entire report was written for Google VRP; but from VRP they're like; we are not looking for these bugs. I mean they need something else. So the segment was meant for them. But i faced this type of bug in a private bug bounty program from there i thought to check gson personally. And this report is exact copy pasted from Google VRP report. Which i've reported. Yeah i agree with you! The security scenario is little bit looking aggressive. 😅 But still the bug contain medium severity impact.

Thanks for this! <3

[Marcono1234]

Out of curiosity, what is the scenario where this can have a security impact?
I can only think of cases where users implement a disallow pattern / blocklist which blocks certain JSON numbers. But in that case these non-ASCII chars are not the only problem:

• merely the fact that the number is given as JSON string instead of JSON number could already bypass the blocklist
• when parsing from a JSON string there are some deviations for parseInt, parseLong and especially parseDouble¹ compared to the JSON number syntax, even for ASCII-only strings (as mentioned in the comments on Validate that strings being parsed as integers consist of ASCII characters #2995)
• when parsing as JsonElement tree first, there is even more lenientness involved; e.g. JsonArray can be converted to a number if it contains a single element

I think other JSON libraries like Jackson might be affected by some of this as well; but maybe it is opt-in there instead of opt-out?

Whereas, if the user implements an explicit allowlist where only matching numbers are allowed, I think there would not be any security vulnerability? Numbers being specified as string might already be rejected because they start with an unexpected ".

I am not saying the fix in #2995 isn't a good idea; and I am neither suggesting to drastically change Gson default behavior, which would break backward compatibility. But I am concerned that it could give a wrong sense of security when in reality this whole blocklist approach for validating JSON data seems error-prone (at least in the context of Gson).

Footnotes

1. See its documentation; for example it trims whitespace and control characters, and supports hex notation.
   Additionally both JsonReader nextInt and nextLong fall back to using Double#parseDouble. ↩

[the5orcerer]

Thanks for the detailed analysis. You raise valid points about the broader lenientness in Gson. My report focused specifically on the Unicode digit coercion because it's the most non-obvious
bypass most developers would not expect Strictness.STRICT to silently accept ١٢٣ as 123. The broader points you raise about
string vs number type and JsonElement lenientness could be worth documenting explicitly in Gson's security guidance, so developers
understand the full picture.

[the5orcerer]

Hi, just checking in for an update on PR #2995.

Also, since this has been confirmed as a security-relevant bug
with a fix in progress, could a CVE ID be assigned for this issue?
As Google is a CNA, this can be done directly. I'd appreciate
being credited as the reporter.

Thanks,
Abu Hurayra (rootplinix)

[eamonnmcmanus]

Also, since this has been confirmed as a security-relevant bug with a fix in progress, could a CVE ID be assigned for this issue? As Google is a CNA, this can be done directly. I'd appreciate being credited as the reporter.

I am reluctant to do that, given that the proposed exploit paths seem very implausible. Making a CVE ID means that Gson clients are going to be prompted to update to a new version. That's extra work for them that is hard to justify unless we think there is a genuine security problem here.

If you can spell out a plausible exploit, we can rethink this. (Feel free to email me if you don't want to do that publicly.)

[the5orcerer]

Hi,

Thank you for merging the fix, I appreciate the quick turnaround. Regarding the CVE, here is the concrete exploit demonstrating a realistic attack path. I've attached two working demos with full setup instructions.

The key scenario is Scenario 3 in OtpBypassDemo.java, Strictness.STRICT provides zero protection. A developer who explicitly enables strict mode has a reasonable expectation that non-standard Unicode input would be rejected. It is not.
All three Unicode digit blocks bypass STRICT mode and return the correct integer silently.
Scenario 2 shows presence-only validation, common in microservices that validate field existence and trust the
library for type enforcement being fully bypassed.

FinancialBypassDemo.java shows an API gateway using ASCII-only regex on the raw body (correct approach at gateway level)
finding no match on Unicode digit input, passing it through, and Gson parsing ５０００ as 5000, bypassing a $999 authorization threshold.

Setup:
curl -L -o gson-2.13.2.jar https://repo1.maven.org/maven2/com/google/code/gson/gson/2.13.2/gson-2.13.2.jar
javac --release 11 -cp gson-2.13.2.jar OtpBypassDemo.java FinancialBypassDemo.java
java -cp gson-2.13.2.jar:. OtpBypassDemo
java -cp gson-2.13.2.jar:. FinancialBypassDemo

The Strictness.STRICT bypass is the hardest case to dismiss it is a documented mode that developers explicitly opt into expecting stricter behavior. Silently accepting Unicode digits under STRICT mode is directly contradictory to that expectation.

I'd appreciate reconsideration of the CVE request given the working exploit.

Thanks,
Abu Hurayra (rootplinix)

Attachments:
FinancialBypassDemo.java
OtpBypassDemo.java

[eamonnmcmanus]

Thanks for taking the trouble to put those together! I'm still not convinced, though. In the first case, the system would have to see that the incoming JSON does contain an "amount" field, but then not care that it is unable to parse its value in order to validate the amount. That seems pretty casual if the backend is not going to be performing its own validation. In the second case, I'm not sure I see why it would matter how an OTP is spelled. The resultant number either is or is not a valid password.

I'm inclined to agree with @Marcono1234's assessment. This is basically only a problem if you are going about security in a way that is broken for any number of other reasons.

Regarding STRICT mode, this is documented to mean "Strict compliance with the JSON specification", nothing more, nothing less. The JSON specification doesn't have anything to say about the contents of strings that happen to be interpreted as numbers.