pybars4 EUVD-2026-114122

The application must compile a Handlebars template whose SOURCE is attacker-influenced - specifically a helper or block argument containing a crafted bracketed path segment - not merely render untrusted data through a trusted template. This is the concrete prerequisite: control over template text reaching pybars4's compiler. LIMITING FACTORS: in the typical configuration where templates are static and developer-authored, untrusted input never reaches the compiler and the flaw is not reachable; the CVSS AC:H/AT:P indicates the trigger is not satisfied by default inputs. Affected: pybars4 through 0.9.13; the available sources do not state a fixed version. No authentication is modelled (PR:N), but the trust-boundary requirement, not auth, is the real gate.

Signals conflict, and the gap between them is the whole story. The CVSS 4.0 base score of 9.2 (Critical) reflects full confidentiality/integrity/availability loss on the vulnerable system (VC:H/VI:H/VA:H) via a network vector with no privileges or user interaction (AV:N/PR:N/UI:N), which reads as a top-priority RCE. But the same vector carries AC:H and AT:P, signalling that non-trivial attack requirements must be met, and the vuln.today Decision label is 'monitor' - the lowest urgency tier - not act_now or emergency. CISA KEV status is not indicated (treat as not listed), no EPSS probability was supplied, and no exploit is confirmed as weaponized; the references are advisories (VulnCheck and a third-party write-up) describing the mechanism rather than a verified working exploit. The decisive, undetermined variable is trust boundary: the flaw only matters if the application compiles attacker-controlled Handlebars template SOURCE (not merely untrusted data rendered through a trusted template). In the common deployment where templates are developer-authored and static, real-world risk is low despite the Critical score; where an app accepts user-supplied templates, this is effectively server-side template injection yielding code execution and should be treated as high priority. Net: high CVSS, but real priority is 'monitor' pending confirmation of whether your deployment exposes template source to untrusted input.

An application uses pybars4 (≤0.9.13) and compiles Handlebars template strings that originate, in whole or part, from an untrusted source (e.g. a user-customisable report or email template). The attacker submits a template containing a crafted bracketed path segment inside a helper or block argument that breaks out of the generated resolve() string literal, so when the template is compiled the injected Python executes in the application process. VulnCheck and a third-party advisory describe the technique, but no exploit is confirmed as verified working code at time of analysis.