GHSA-gjx9-j8f8-7j74 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 contentAny system that renders untrusted Jinja templates using HubSpot's Jinjava implementationUsers 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:**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()`**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 contextInstantiate `ObjectMapper` to enable default typingCreate arbitrary Java classes by bypassing type allowlistsRead files from the server filesystem (demonstrated with `/etc/passwd`)Potentially execute arbitrary codePatches**Status**: Patched - CVE-2026-25526Users 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**:**ForTag Security Hardening**Added security checks to `ForTag.renderForCollection()` to enforce `JinjavaBeanELResolver` restrictionsImplemented property access validation against restricted properties/methods before invoking getter methodsAdded checks for restricted class types before introspection**Enhanced Type Validation**Improved validation in `JinjavaBeanELResolver.isRestrictedClass()` to prevent instantiation of sensitive typesAdded additional restricted types to the denylistImplemented deeper validation for types created via ObjectMapper deserialization**Configuration Protection**Added checks to prevent creation of new `JinjavaConfig` or `JinjavaELContext` instances via ObjectMapperPrevented modification of `readOnlyResolver` configuration from untrusted templatesImplemented additional safeguards around ELResolver configuration**Collection Type Validation**Implemented proper type validation in `HubLELResolver` to prevent collection type wrapping bypassesAdded checks for wrapped types in collection deserializationImplemented validation for all types within collections against allowlists**ObjectMapper Restrictions**Added additional restrictions on `ObjectMapper.enableDefaultTyping()` to prevent enabling via less restrictive ELResolverEnsured 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.ReferencesProject Resources**Jinjava Source Code**: [github.com/HubSpot/jinjava](https://github.com/HubSpot/jinjava)**Jinjava Releases**: [github.com/HubSpot/jinjava/releases](https://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 SystemAdditional Resources[OWASP Template Injection](https://owasp.org/www-community/attacks/Server_Side_Template_Injection)[Java Deserialization Security](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)[CVE Standards and Procedures](https://cve.mitre.org/)
CVSS v3.1 score: 9.8