pybars3 EUVD-2026-114121

Exploitation requires that the application feed attacker-controlled content into the Handlebars template SOURCE processed by pybars3 - specifically crafted bracketed path segments placed in helper or block arguments that escape the string literal in the Python code pybars3 compiles (per pybars/_compiler.py L159-160). The decisive limiting factor is deployment design: applications that render only trusted, developer-authored templates and pass untrusted values only as runtime data are NOT exposed; only applications that accept untrusted users' template bodies (an SSTI-style exposure) are affected. The CVSS AC:H/AT:P metrics reflect this non-default precondition. No authentication is inherent to the flaw itself (PR:N), and no user interaction is required (UI:N), but the trigger beyond 'supply a crafted template' is not detailed in the available sources.

The input CVSS 4.0 score of 9.2 (Critical) reflects the worst-case impact of arbitrary Python execution (VC:H/VI:H/VA:H), but several signals temper real-world urgency. The vector itself encodes meaningful friction: AC:H and AT:P indicate the attack is not a simple default-config hit but depends on specific conditions, and the gating prerequisite from the description is that the application must render attacker-controlled Handlebars template source - not merely attacker-controlled data fed into a trusted template. This is effectively a server-side template injection (SSTI) class issue: it is a genuine RCE only for applications that let untrusted users author or supply template bodies, which is an uncommon design. The vuln.today Decision label is 'monitor' (not act_now/emergency), consistent with this conditional exploitation profile. No EPSS score was provided, so exploitation probability cannot be weighed. It is not listed in CISA KEV, so there is no evidence of active exploitation. Public advisories describing the technique exist (VulnCheck advisory and the independent vladko312 advisory), so the mechanism is documented, but the input does not confirm weaponized exploit code. Net: a high-impact but condition-dependent issue - a real priority for any product that exposes template authoring to untrusted input, and lower practical risk where only developer-authored static templates are used. Note the AV:N/PR:N framing describes severity reachability, not that every pybars3 deployment is remotely exploitable without the untrusted-template path.

An application uses pybars3 to render Handlebars templates whose source is derived from untrusted input (e.g., a user-customizable report, email, or dashboard template). An attacker submits a template containing crafted bracketed path segments inside a helper or block argument that break out of the string literal in the Python code pybars3 generates, causing their Python to run in the application process. Public advisories (VulnCheck, vladko312) document the technique, though the input does not confirm working exploit code.