JsonPath (Jayway) End of Life (EOL) Dates & Support Timeline
Complete end-of-life dates, support windows, and security status for all JsonPath (Jayway) versions. Data sourced from endoflife.date and official vendor documentation. Updated at every deploy.
Running an EOL version? Get matched with support options — free ↓| Version | Latest Release | Release Date | EOL Date | Days | Status |
|---|---|---|---|---|---|
| 2.5 | 2.5.0 | Dec 10, 2020 | Jun 2, 2021 | 1890 days past EOL | EOL |
| 2.6 | 2.6.0 | Jun 2, 2021 | Jan 30, 2022 | 1648 days past EOL | EOL |
| 2.7 | 2.7.0 | Jan 30, 2022 | Mar 26, 2023 | 1228 days past EOL | EOL |
| 2.8 | 2.8.0 | Mar 26, 2023 | Jan 20, 2024 | 928 days past EOL | EOL |
| 2.9 | 2.9.0 | Jan 20, 2024 | TBD | Supported | Active |
Live EOL badge for your README — updates automatically at every build.
[](https://endoflife.ai/jsonpath)
JsonPath (Jayway) lifecycle status — the real story
JsonPath — com.jayway.jsonpath:json-path — is the library behind almost every $.store.book[0].title expression in Java code, and most projects that carry it never chose it: Spring's own MockMvc test assertions (jsonPath(…)) pull it in transitively, as do a long tail of API-testing and configuration tools. It has no published support policy and effectively a single line of development — each release supersedes the last, and only the newest version ever receives a fix. The table reflects that convention: each minor's EOL date is the release date of its successor.
The cadence makes the risk concrete. Releases are roughly annual at best — 2.7.0 in January 2022, 2.8.0 in March 2023, 2.9.0 in January 2024, and nothing since — so a fix, when one comes, can trail a disclosure by months and strands every earlier version permanently. CVE-2023-51074, a stack-overflow flaw in Criteria.parse(), was disclosed against 2.8.0; the 2.9.0 release that followed it is the only patched line. Any dependency tree still resolving 2.7.x or 2.8.x — common wherever a framework pinned the version years ago — is carrying that flaw today.
The upgrade is usually a version bump — the expression API is stable — but transitive pins are the trap: the copy in your build is whatever your framework chose, not the current release, and a two-year-old JsonPath does not look outdated the way a major-version gap does. Scan the dependency tree first. If a pinned line cannot move, commercial extended support for end-of-life JsonPath versions exists — see the support options below.
What does JsonPath (Jayway) end of life mean for your organization?
When a version of JsonPath (Jayway) reaches end of life, the maintainers stop issuing security patches. Vulnerabilities discovered after this date are publicly disclosed on the National Vulnerability Database, exploit code appears on GitHub, and your systems remain permanently exposed.
The CVE blind spot: Most vulnerability scanners check for known CVEs but do not flag the accumulation of unpatched vulnerabilities in EOL software. With a zero-day, nobody knows about the vulnerability. With EOL software, the vulnerability is public — listed, rated, and often weaponized — but no patch will ever exist. This is the most dangerous gap in enterprise security posture.
Organizations running EOL JsonPath (Jayway) should treat it as a vulnerability class in their risk register, apply compensating controls (network segmentation, enhanced monitoring, access restriction), and prioritize migration to a supported version.
Extended Support Options
If you cannot migrate immediately, extended support vendors provide continued security patches for EOL JsonPath (Jayway) versions. This is a bridge, not a permanent solution — plan your migration in parallel.
JsonPath (Jayway) has 4 versions past end of life — security patches have stopped, but CVE disclosures haven't. The good news: extended support for JsonPath (Jayway) exists — vetted vendors ship security patches for years past the official date. Right now that coverage spans JsonPath (Jayway) 2.x. Tell us where to reach you and we'll reply with matched options and pricing guidance.