Incorrect access control in the REST API endpoint of HubSpot v1.29441 allows unauthenticated attackers to view users' data without proper authorization.

The HubSpot All-In-One Marketing – Forms, Popups, Live Chat plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 11.3.62 via the wplocalizescript() / window.leadinConfig JavaScript object. This makes it possible for authenticated attackers, with contributor-level access and above, to extract the site's plaintext HubSpot OAuth refresh token exposed via the window.leadinConfig JavaScript object, which can then be used to access or modify data in the connected HubSpot tenant. Although the refresh token is stored at rest with AES-256-CTR encryption, decryption occurs server-side before the plaintext value is passed to wplocalizescript(), rendering the at-rest encryption ineffective against this exposure path.

Insertion of Sensitive Information Into Sent Data vulnerability in HubSpot allows Retrieve Embedded Sensitive Data.

This issue affects HubSpot: from n/a through 11.3.51.

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

Summary

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 JinjavaInterpreter instances (see Add interpreter to blacklist). However, interacting with the properties of JinjavaInterpreter instances remains unrestricted.

From int3rpr3t3r, it is possible to traverse to the config field, which exposes an ObjectMapper. By invoking readValue(String content, JavaType valueType) on this ObjectMapper, an attacker can instantiate arbitrary classes specified via JavaType.

Although jinjava explicitly restricts dangerous classes such as Class, ClassLoader, and so on inside JinjavaBeanELResolver, the JavaType class itself is not restricted.

As a result, an attacker can leverage JavaType construction (constructFromCanonical) to instantiate semi-arbitrary classes without directly calling restricted methods.

This allows sandbox escape and the creation of powerful primitives.

Impact Escape the Jinjava sandbox and instantiate a wide range of classes using JavaType. This capability can be used to read arbitrary files and to perform full read SSRF by creating network-related objects. In certain environments, depending on the available classes, this primitive can even lead to complete remote code execution.

The HubSpot – CRM, Email Marketing, Live Chat, Forms & Analytics plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'url' attribute of the HubSpot Meeting Widget in all versions up to, and including, 11.1.22 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Affected versions of hubl-server insecurely download dependencies over an unencrypted HTTP connection.

In scenarios where an attacker has a privileged network position, it is possible to intercept the responses and replace the dependencies with malicious ones, resulting in code execution on the system running hubl-server.

Recommendation

No patch is currently available for this vulnerability, and it has not seen any updates since 2015.

The best mitigation is currently to avoid using this package, using a different package if available.

Alternatively, the risk of exploitation can be reduced by ensuring that this package is not installed while connected to a public network. If the package is installed on a private network, the only people who can exploit this vulnerability are those who have compromised yo

Jinjava before 2.4.6 does not block the getClass method, related to com/hubspot/jinjava/el/ext/JinjavaBeanELResolver.java.

A user with privileges to write JinJava templates, for example in a CMS context, will be able to read arbitrary files from the file system.

The HubSpot WordPress plugin before 8.8.15 does not validate the proxy URL given to the proxy REST endpoint, which could allow users with the editposts capability (by default contributor and above) to perform SSRF attacks