jinjava has Sandbox Bypass via JavaType-Based Deserialization

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

9.8 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS

• CVE-2025-59340: 2.19% estimated exploitation activity in the next 30 days; percentile 82.41 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

Summary jinjava’s current sandbox restrictions prevent direct access to dangerous methods such as getClass(), and block instantiation of Class objects. However, these protections can be bypassed. By using mapper.getTypeFactory().constructFromCanonical(), it is possible to instruct the underlying ObjectMapper to deserialize attacker-controlled input into arbitrary classes. This enables the creation of semi-arbitrary class instances without directly invoking restricted methods or class literals. As a result, an attacker can escape the sandbox and instantiate classes such as java.net.URL, opening up the ability to access local files and URLs(e.g., file:///etc/passwd). With further chaining, this primitive can potentially lead to remote code execution (RCE). Details jinjava templates expose a built-in variable int3rpr3t3r, which provides direct access to the jinjavaInterpreter instance. This variable was previously abused and protections were added to prevent call method from…

Published by the source

17 Sep 2025, 19:56 UTC

Last modified by the source

31 Jul 2026, 22:15 UTC

Source last checked

26 Oct 2026, 16:54 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-m49c-g9wr-hv6v

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2025-59340

Advisory: jinjava has Sandbox Bypass via JavaType-Based Deserialization
IDs: CVE-2025-59340, GHSA-m49c-g9wr-hv6v
Record: https://patchnext.com/advisories/cve-2025-59340 (revision 1, source checked 26 Oct 2026, 16:54 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Critical (CVSS 9.8)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: com.hubspot.jinjava:jinjava 2.8.1, 2.7.5. A vendor fix does not mean a deployment is fixed.

## Affected components
- Maven com.hubspot.jinjava:jinjava: affected >= 2.8.0, <= 2.8.0; >= 2.7.0, < 2.7.5; fixed in 2.8.1, 2.7.5

## Suggested inspection (read-only)
- Maven com.hubspot.jinjava:jinjava: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on com.hubspot.jinjava:jinjava.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-m49c-g9wr-hv6v (GitHub-reviewed advisory GHSA-m49c-g9wr-hv6v lists affected ranges: Maven com.hubspot.jinjava:jinjava >=2.8.0 =2.7.0 <2.7.5)

Commands are suggestions: review each one before running it.