GHSA-gjx9-j8f8-7j74 JinJava Bypass through ForTag leads to Arbitrary Java Execution

• Maven com.hubspot.jinjava:jinjava: >= 2.8.0, < 2.8.3 → fixed in 2.8.3 • Maven com.hubspot.jinjava:jinjava: < 2.7.6 → fixed in 2.7.6

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