CVE-2026-25526: JinJava Bypass through ForTag leads to Arbitrary Java Execution

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 - Jinjava Source Code: github.com/HubSpot/jinjava - Jinjava Releases: github.com/HubSpot/jinjava/releases

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 - OWASP Template Injection - Java Deserialization Security - CVE Standards and Procedures