Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕ Maven

GHSA-gjx9-j8f8-7j74

CRITICAL

JinJava Bypass through ForTag leads to Arbitrary Java Execution

Also known asCVE-2026-25526
Published
Feb 3, 2026
Updated
Feb 5, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.9%probability of exploitation in next 30 days
Lower Risk55th percentile+0.85%
0.00%0.46%0.93%1.39%0.0%0.0%0.0%0.0%0.9%Mar 26May 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

2 pkgs affected
☕com.hubspot.jinjava:jinjava☕com.hubspot.jinjava:jinjava

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Impact

Vulnerability Type: Sandbox Bypass / Remote Code Execution

Affected Component: Jinjava

Affected Users:

  • Organizations using HubSpot's Jinjava template rendering engine for user-provided template content
  • Any system that renders untrusted Jinja templates using HubSpot's Jinjava implementation
  • Users with the ability to create or edit custom code templates

Severity: Critical - allows arbitrary Java class instantiation and file access bypassing built-in sandbox restrictions

Root Cause: Multiple security bypass vulnerabilities in Jinjava's sandbox mechanism:

  1. ForTag Property Access Bypass: The ForTag class does not enforce JinjavaBeanELResolver restrictions when iterating over object properties using Introspector.getBeanInfo() and invoking getter methods via PropertyDescriptor.getReadMethod()

  2. Restricted Class Instantiation: The sandbox's type allowlist can be bypassed by using ObjectMapper to instantiate classes through JSON deserialization, including creating new JinjavaELContext and JinjavaConfig instances

Attack Vector: An attacker with the ability to create or edit Jinja templates can:

  • Access arbitrary getter methods on objects in the template context
  • Instantiate ObjectMapper to enable default typing
  • Create arbitrary Java classes by bypassing type allowlists
  • Read files from the server filesystem (demonstrated with /etc/passwd)
  • Potentially execute arbitrary code

Patches

Status: Patched - CVE-2026-25526

Users should upgrade to one of the following versions which contain fixes for this vulnerability:

  • JinJava 2.8.3 or later
  • JinJava 2.7.6 or later

Fix Components:

  1. ForTag Security Hardening

    • Added security checks to ForTag.renderForCollection() to enforce JinjavaBeanELResolver restrictions
    • Implemented property access validation against restricted properties/methods before invoking getter methods
    • Added checks for restricted class types before introspection

  2. Enhanced Type Validation

    • Improved validation in JinjavaBeanELResolver.isRestrictedClass() to prevent instantiation of sensitive types
    • Added additional restricted types to the denylist
    • Implemented deeper validation for types created via ObjectMapper deserialization

  3. Configuration Protection

    • Added checks to prevent creation of new JinjavaConfig or JinjavaELContext instances via ObjectMapper
    • Prevented modification of readOnlyResolver configuration from untrusted templates
    • Implemented additional safeguards around ELResolver configuration

  4. Collection Type Validation

    • Implemented proper type validation in HubLELResolver to prevent collection type wrapping bypasses
    • Added checks for wrapped types in collection deserialization
    • Implemented validation for all types within collections against allowlists

  5. ObjectMapper Restrictions

    • Added additional restrictions on ObjectMapper.enableDefaultTyping() to prevent enabling via less restrictive ELResolver
    • Ensured default typing cannot be enabled without proper authorization

Information for Users: Upgrade to version 2.8.3 or 2.7.6 or later to address this vulnerability.

References

Project Resources

Security Standards & Classifications

  • CWE-502: Deserialization of Untrusted Data
  • CWE-913: Improper Control of Dynamically-Managed Code Resources
  • CWE-94: Improper Control of Generation of Code ('Code Injection')
  • CVSS v3.1: Common Vulnerability Scoring System

Additional Resources

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
☕Mavencom.hubspot.jinjava:jinjava≥ 2.8.0&&< 2.8.32.8.3
☕Mavencom.hubspot.jinjava:jinjavaall versions2.7.6

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.hubspot.jinjava:jinjava. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update com.hubspot.jinjava:jinjava to 2.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-gjx9-j8f8-7j74 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-gjx9-j8f8-7j74 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-gjx9-j8f8-7j74. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Impact **Vulnerability Type**: Sandbox Bypass / Remote Code Execution **Affected Component**: Jinjava **Affected Users**: - Organizations using HubSpot's Jinjava template rendering engine for user-provided template content - Any system that renders untrusted Jinja templates using HubSpot's Jinjava implementation - Users with the ability to create or edit custom code templates **Severity**: **Critical** - allows arbitrary Java class instantiation and file access bypassing built-in sandbox restrictions **Root Cause**: Multiple security bypass vulnerabilities in Jinjava's sandbox mechanis
O3 Security · Impact-Aware SCA

Is GHSA-gjx9-j8f8-7j74 in your dependencies?

O3 detects GHSA-gjx9-j8f8-7j74 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works