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