The core vulnerability stems from the parse function's handling of template variables. Key evidence:

1. The function uses eval(name) to process numeric values, though this isn't directly XSS-related
2. User-controlled values are inserted via _replaceAll() without any default HTML escaping
3. Filters must be explicitly applied (via |filter syntax) for sanitization, but no default escaping filter exists
4. The Snyk PoC shows direct injection of <script> tags through unfiltered variables
5. The library's responsibility as a template engine requires output encoding by default, which is not implemented
6. The vulnerability manifests when users don't manually apply HTML-escaping filters to every potentially dangerous variable