CVE-2026-35477: InvenTree RCE Vulnerability

CVE-2026-35477 Overview

InvenTree, an Open Source Inventory Management System, contains a Jinja2 template sandbox bypass vulnerability affecting versions 1.2.3 through 1.2.6. The vulnerability exists because the fix for CVE-2026-27629, which upgraded the PART_NAME_FORMAT validator to use jinja2.sandbox.SandboxedEnvironment, was not consistently applied throughout the codebase. Specifically, the actual renderer in part/helpers.py still uses the non-sandboxed jinja2.Environment, creating a critical security gap where templates can pass validation but execute arbitrary code during rendering.

Critical Impact

A staff user with settings access can craft a malicious template that exploits the validation vs. rendering discrepancy to achieve arbitrary code execution on the server.

Affected Products

• InvenTree versions 1.2.3 through 1.2.6

Discovery Timeline

• April 8, 2026 - CVE-2026-35477 published to NVD
• April 8, 2026 - Last updated in NVD database

Technical Details for CVE-2026-35477

Vulnerability Analysis

This vulnerability is classified as CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine). The root issue stems from an incomplete security patch that introduced a sandbox environment for template validation while leaving the production renderer unprotected.

The security gap arises from two distinct problems: First, the validator uses jinja2.sandbox.SandboxedEnvironment while the renderer in part/helpers.py uses the standard jinja2.Environment. Second, the validator uses a dummy Part instance with pk=None, which allows attackers to craft conditional template expressions that behave differently during validation versus production rendering.

This means an attacker can design a template containing conditional logic that appears benign during validation (when pk is None) but executes malicious code when rendered with an actual Part object that has a valid primary key.

Root Cause

The root cause is a mismatch between the template validation and rendering environments. When the security fix for CVE-2026-27629 was implemented, developers upgraded the validator to use a sandboxed Jinja2 environment but failed to update the actual rendering code path. The use of a dummy Part instance with pk=None during validation further compounds the issue by allowing attackers to use conditional expressions that only trigger during production rendering.

Attack Vector

The attack requires a staff user with settings access privileges. The attacker crafts a malicious PART_NAME_FORMAT template containing conditional logic that checks if the Part's primary key is not None. During validation, this condition evaluates to false (since the validator uses a dummy Part with pk=None), causing the template to appear safe. However, during actual rendering with real Part objects, the condition evaluates to true, and the malicious code executes within the unsandboxed Jinja2 environment, leading to arbitrary code execution on the server.

The attack is network-accessible and requires no user interaction beyond the attacker's initial access. Since the vulnerability requires staff-level permissions, the scope of potential attackers is limited to trusted users who have been granted elevated privileges.

Detection Methods for CVE-2026-35477

Indicators of Compromise

• Unusual PART_NAME_FORMAT settings containing complex conditional expressions or Jinja2 constructs beyond simple variable substitution
• Server logs showing template rendering errors or unexpected system calls originating from the part naming functionality
• Modified settings entries in the application database related to part name formatting

Detection Strategies

• Monitor InvenTree application settings for changes to PART_NAME_FORMAT values, especially those containing conditional logic or Jinja2 expressions
• Implement code review processes for any template configurations that include conditional statements or advanced Jinja2 features
• Deploy web application firewalls (WAF) with rules to detect template injection patterns in POST requests to settings endpoints

Monitoring Recommendations

• Enable detailed logging for all settings changes in InvenTree and alert on modifications to template-related configurations
• Monitor server processes for unexpected child processes or network connections that could indicate code execution
• Implement file integrity monitoring on the InvenTree installation directory to detect any unauthorized modifications

How to Mitigate CVE-2026-35477

Immediate Actions Required

• Upgrade InvenTree to version 1.2.7 or 1.3.0 immediately to apply the security patch
• Audit all staff user accounts and restrict settings access to only essential personnel
• Review current PART_NAME_FORMAT settings for any suspicious template expressions and reset to default if necessary

Patch Information

This vulnerability is fixed in InvenTree versions 1.2.7 and 1.3.0. The fix ensures that the same sandboxed Jinja2 environment is used consistently for both validation and rendering, eliminating the security gap. For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• If immediate patching is not possible, temporarily restrict settings access permissions to only the most trusted administrators
• Implement network-level access controls to limit which users can reach the InvenTree settings interface
• Consider disabling custom PART_NAME_FORMAT templates entirely and using default naming conventions until the patch can be applied

# Verify InvenTree version and check for updates
inventree-admin version
# Review current part name format settings
inventree-admin shell -c "from common.models import InvenTreeSetting; print(InvenTreeSetting.get_setting('PART_NAME_FORMAT'))"