If you discover a security vulnerability in WildflowerJS, please report it responsibly.

Do not open a public issue. Instead, email security@wildflowerjs.com with:

• A description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

We will acknowledge receipt within 48 hours and aim to provide a fix or mitigation within 7 days for critical issues.

WildflowerJS is a client-side framework. Security concerns typically involve:

• XSS through data-bind-html (warns in dev builds; configure wildflower.setHtmlSanitizer() with DOMPurify or similar)
• Expression evaluation safety (CSP-compliant evaluator available)
• Prototype pollution in state management

We take all reports seriously regardless of severity.

WildflowerJS ships as a single pre-built JavaScript file. Users who follow the documented integration path (one <script> tag pointing at the CDN-hosted bundle) never run npm install to use the framework, so the npm postinstall / build-time supply-chain attack class (Shai-Hulud, event-stream, ua-parser-js, node-ipc, etc.) does not apply to framework consumers.

Maintainers building the framework from source use a vendored, SHA-512-pinned toolchain (rollup + terser, fetched once via direct tarball download with integrity verification, no npm install during the build, no postinstall scripts). The build trust footprint is 8 frozen tarballs pinned in scripts/fetch-rollup.cjs and scripts/fetch-terser.cjs. Version bumps require explicit hash updates and changelog review.

If you spot a way to introduce attacker-controlled code into a published WildflowerJS bundle through the build path, treat it as in-scope and report via the email above.