GHSA-gjx9-j8f8-7j74

## 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](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 System ### Additional 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/)