The CVE describes a semantic bug in cJSON's JSON Patch decoder, not a memory safety issue. decode_pointer_inplace() resolves RFC 6902 escape sequences incorrectly — ~0 should decode to ~ and ~1 to /, but the order matters. The code produces syntactically valid output while traversing the wrong JSON Pointer. No crash occurs. No heap corrupts. The function returns success. That invisibility is the actual threat.
This is not a vulnerability you will discover through fuzzing or sanitizers. It produces correct-looking data that is semantically wrong. Every defensive instrument tuned for crashes or panics misses it entirely. The CVSS 7.5 reflects generic scoring — network-accessible, no auth required, high confidentiality/availability impact — but it treats 'no crash' as neutral when it should be aggravating. Absence of observable failure means absence of detection, which means longer exposure.
The real risk is architectural. Applications using JSON Patch for authorization-gated partial updates — configuration management, document stores, API gateways enforcing row-level permissions — are exposed. The patch operation runs after authentication but before authorization, treating the output as implicitly trusted. An attacker doesn't need a crash; they need the system to silently modify the wrong resource. The corrupted data then poisons every downstream consumer: workers, reporting jobs, cached queries, other microservices that had nothing to do with the patch request.
Remediate the library, but that's incomplete. Audit every application that consumed patches during the vulnerable window — forensic scope extends beyond the code fix. The EPSS 0.00258 reflects tooling scarcity, not actual risk. Automated scanners won't find this. Human recognition that a specific application uses JSON Patch for authorization-critical mutations is the exploitation vector. That's a scanner-time problem that requires domain knowledge to discover.