CVE-2026-113602 in Json-smart
Summary
by MITRE • 10/20/2026
json-smart through 2.6.0 contains an input validation bypass vulnerability that allows attackers to evade strict-mode trailing-data checks by inserting a literal 0x1A character. Attackers can append 0x1A and malformed content to pass JSONValue.parseStrict or isValidJsonStrict validation, creating parser differentials with downstream parsers like Jackson or Gson.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The json-smart library, specifically through version 2.6.0, contains a critical input validation bypass vulnerability that undermines the integrity of strict-mode parsing operations. This flaw allows attackers to evade trailing-data checks by inserting a literal ASCII character with the hexadecimal value 0x1A into JSON payloads. The presence of this specific control character enables malicious actors to append malformed content after valid JSON structures without triggering the expected rejection mechanisms in json-smart's strict validation methods, such as isValidJsonStrict or JSONValue.parseStrict. This behavior represents a significant deviation from standard parsing expectations and creates a dangerous inconsistency between different JSON processing libraries within Java-based ecosystems.
From a technical perspective, this vulnerability stems from an insufficient check for non-printable control characters during the final stages of string parsing in strict mode. While json-smart is designed to reject inputs that contain trailing data after the primary JSON object or array, it fails to properly validate against the 0x1A character, often referred to as the substitute character in ASCII standards. By exploiting this oversight, an attacker can craft a payload where the core JSON structure appears valid and complete according to json-smart's parser, while simultaneously embedding additional malicious data immediately following it. This differential behavior is particularly dangerous because many enterprise applications rely on multiple parsers for interoperability or fallback purposes, assuming that if one strict parser accepts input, others will behave consistently.
The operational impact of this vulnerability extends beyond simple parsing errors and can lead to severe security consequences including injection attacks, logic bypasses, and data integrity issues. When downstream parsers like Jackson or Gson process the same payload, they may interpret the trailing malformed content differently than json-smart did. For instance, if an application uses json-smart for initial validation but then passes the parsed object to another component that re-parses or serializes using a different library, the discrepancy can lead to unexpected behavior. In security-sensitive contexts such as authentication token processing or configuration file parsing, this inconsistency could allow attackers to inject arbitrary commands, bypass access controls, or corrupt application state by exploiting the gap between what json-smart considers valid and what other parsers might execute or interpret differently.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically relating to insufficient sanitization of special characters that can alter parsing logic. It also maps to MITRE ATT&CK technique T1568.002 Dynamic Disassembly, where attackers use subtle variations in parser behavior to evade detection mechanisms or security controls designed around standard input formats. The ability to create parser differentials is a known attack vector used by sophisticated threat actors to bypass web application firewalls and intrusion detection systems that rely on specific parsing rules for signature matching.
Mitigation strategies should prioritize immediate updates to json-smart version 2.6.1 or later, where this validation flaw has been addressed. Organizations relying on older versions must implement strict input filtering at the network perimeter or application entry point to block payloads containing ASCII control characters such as 0x1A before they reach the parsing layer. Additionally, developers should avoid mixing multiple JSON parsers for the same data stream without explicit normalization steps. If json-smart is used solely for validation, it is crucial to ensure that subsequent processing uses a parser with identical strictness settings and character handling rules to prevent differential exploitation. Regular security audits of third-party library configurations are essential to identify such inconsistencies before they can be leveraged in production environments.