json-smart EUVD-2026-105168

Exploitation requires the target application to use json-smart's JSONValue.parseStrict or isValidJsonStrict as a validation/security boundary AND to subsequently hand the same raw input to a different JSON parser (e.g., Jackson or Gson) that treats the appended 0x1A byte and following bytes differently. The attacker must be able to supply the JSON input containing the literal 0x1A (SUB) character plus malformed trailing data. Limiting factors: the flaw has no impact if json-smart is the only parser used, if strict mode is not used as a trust gate, or if downstream processing re-validates/canonicalizes input; it affects json-smart versions through 2.6.0 and yields only integrity effects, not RCE or data disclosure in json-smart itself.

This is a medium-severity integrity-only issue rather than a top priority. The source-provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 and indicates a remotely reachable, low-complexity, unauthenticated flaw - but impact is limited to VI:L (low integrity) with VC:N and VA:N, so there is no direct confidentiality or availability loss and no code execution in json-smart itself. The real-world danger is conditional: it is a parser differential (CWE-147 improper input-terminator neutralization) that only matters when an application relies on json-smart strict mode (parseStrict/isValidJsonStrict) as a security/validation gate and then re-parses the same bytes with a different library (Jackson or Gson). No EPSS score was provided in the input, the CVE is not in CISA KEV, and no public exploit was identified, so there is no evidence of active or widespread exploitation. The network-vector/no-privileges metrics make the raw score look alarming, but the requirement for a specific multi-parser validation pipeline substantially limits practical exploitability - treat this as a design-dependent hardening item, not an emergency. Signals are consistent (no KEV/POC, modest integrity-only CVSS); the main missing datum is EPSS, which would help gauge likelihood.

An attacker sends a JSON document to an endpoint that validates input with json-smart's strict mode, appending a literal 0x1A character followed by malformed trailing content. json-smart accepts the payload as valid, but when the application forwards the same bytes to a downstream parser such as Jackson or Gson, that parser interprets the trailing data differently - letting the attacker smuggle values past the validation boundary. No public exploit code was identified at time of analysis.