Nari is pre-1.0 (current language version 0.0.1, stdlib 0.0.4). Only the main branch and the most recent tagged release receive security fixes.

Please do not open a public GitHub issue for security-sensitive reports.

Instead, file a private vulnerability report through GitHub's built-in advisory workflow:

1. Go to https://github.com/nari-lang/nari/security/advisories.
2. Click Report a vulnerability.
3. Include:

• a description of the issue and the impact you believe it has,
• a minimal reproducer (Nari script, command line, or naric input),
• affected versions / commit SHA,
• any suggested mitigations.

You should receive an acknowledgment within a few days. We will work with you to confirm the issue, prepare a fix, and coordinate disclosure.

• Memory-safety bugs in the interpreter, JIT, bytecode verifier, or builtins (e.g. UAF, OOB read/write, type confusion, double free).
• Sandbox escapes in the naric bytecode loader / verifier.
• Vulnerabilities in stdlib facilities that handle untrusted input (JSON.parse, Hex.decode, Base64.decode, Archive.extract, Hash.sha256File, HTTP client, FFI loader).
• Authentication, authorization, or integrity issues in the package manager (npkg) or the package registry interaction.

• Issues that require an attacker to already control the source .nari / .naric file and the host system. Nari is not a security boundary against attacker-supplied source code.
• Denial-of-service via deliberately pathological scripts (deep recursion, infinite loops, huge allocations) - these are language-level concerns, not vulnerabilities, unless they bypass an explicit limit such as the parser's nesting cap or the bytecode verifier.
• Issues only reproducible in the --musl experimental build (FFI is known not to work cleanly there).
• Reports generated by automated scanners with no demonstrated exploit.

We aim to:

• Acknowledge reports within 7 days.
• Provide a triage decision within 14 days.
• Land a fix on main and request CVEs for confirmed issues before public disclosure.