Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 2.8.3 or 2.7.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
jinjava’s current sandbox restrictions prevent direct access to dangerous methods such as getClass(), and block instantiation of Class objects. However, these protections can be bypassed. By using mapper.getTypeFactory().constructFromCanonical(), it is possible to instruct the underlying ObjectMapper to deserialize attacker-controlled input into arbitrary classes. This enables the creation of semi-arbitrary class instances without directly invoking restricted methods or class literals. As a result, an attacker can escape the sandbox and instantiate classes such as java.net.URL, opening up the ability to access local files and URLs(e.g., file:///etc/passwd). With further chaining, this primitive can potentially lead to remote code execution (RCE). Details jinjava templates expose a built-in variable int3rpr3t3r, which provides direct access to the jinjavaInterpreter instance. This variable was previously abused and protections were added to prevent call method from…
Recommended action: Upgrade to 2.8.1 or 2.7.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jinjava before 2.5.4 allow access to arbitrary classes by calling Java methods on objects passed into a Jinjava context. This could allow for abuse of the application class loader, including Arbitrary File Disclosure.
Recommended action: Upgrade to 2.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Jinjava before 2.4.6 does not block the getClass method, related to com/hubspot/jinjava/el/ext/JinjavaBeanELResolver.java.
Recommended action: Upgrade to 2.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.