This vulnerability lives in ember-dynamic-render-template, an Ember addon that accepts a templateString prop and compiles it as a live Glimmer template. The vulnerability is straightforward: the addon passes this string directly to Handlebars.compile() (or its Ember equivalent) without sanitization, creating a classic template injection vector that enables arbitrary JavaScript execution in the victim's browser.
The practical risk hinges entirely on whether attacker-controlled data can reach the templateString parameter in your application. Most legitimate uses involve developer-controlled strings—rendering pre-defined templates, dynamic content from internal CMS systems, or template previews. The real danger emerges if your architecture passes URL parameters, user-submitted content, or database fields directly into this prop without validation. Check whether any route handlers, query parameters, or third-party data integrations flow into this component.
The fix is simple: validate that templateString comes from a trusted source before compilation. If user input must reach this addon, implement an allowlist of permitted templates or use Ember's built-in sanitization helpers. The addon maintainers should document this boundary clearly—current documentation provides no warning that this is a security-critical prop, which is the real systemic failure here.
Note that CVSS 6.1 reflects technical severity but overstates practical risk for most deployments. The addon fills a legitimate niche for dynamic template rendering, and the vulnerability only manifests under specific misuse patterns. Prioritize auditing applications that use this addon with any external data source as input.