Skip to content

JinJava Bypass through ForTag leads to Arbitrary Java Execution

Critical severity GitHub Reviewed Published Feb 3, 2026 in HubSpot/jinjava • Updated Feb 5, 2026

Package

maven com.hubspot.jinjava:jinjava (Maven)

Affected versions

>= 2.8.0, < 2.8.3
< 2.7.6

Patched versions

2.8.3
2.7.6

Description

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

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

References

@jasmith-hs jasmith-hs published to HubSpot/jinjava Feb 3, 2026
Published to the GitHub Advisory Database Feb 3, 2026
Reviewed Feb 3, 2026
Published by the National Vulnerability Database Feb 4, 2026
Last updated Feb 5, 2026

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(12th percentile)

Weaknesses

Improper Neutralization of Special Elements Used in a Template Engine

The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine. Learn more on MITRE.

CVE ID

CVE-2026-25526

GHSA ID

GHSA-gjx9-j8f8-7j74

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.