# Security Policy
## Reporting a Vulnerability
Please report security vulnerabilities through GitHub's [private vulnerability
reporting](https://github.com/quickjs-ng/quickjs/security/advisories/new)
feature, **only if** your report meets the rules below. Reports that do not
meet these rules should be filed as regular public issues instead.
## Out of Scope
**Bytecode hardening is out of scope.** QuickJS bytecode is not designed for
adversarial input. Loading untrusted bytecode (e.g. via `JS_ReadObject` with
`JS_READ_OBJ_BYTECODE`) is equivalent to executing untrusted native code, and
crashes, memory corruption, or sandbox escapes resulting from malformed or
malicious bytecode are not considered security vulnerabilities. Only load
bytecode you produced yourself or obtained from a trusted source. See the
documentation for `JS_READ_OBJ_BYTECODE` and `JS_READ_OBJ_SAB` for details.
## Rules for Private Reports
Private reporting exists to protect users from issues an attacker could not
otherwise discover.
**AI-detected bugs are by definition not secret.** If a publicly available
tool found a bug by reading our public source, anyone else running the same
tool will find the same bug. Filing such reports privately just produces
duplicate work since previous reports of the same issue are not visible.
The right place for these is a public issue, where duplicates are visible and
the fix discussion is shared.
AI tools are welcome, but use them to add value on top of what the tool
produced. Read the code, confirm the bug, write a patch, write a test. A
"drive-by" forward of a tool's raw output, with no real understanding behind
it, is not a useful report.
Before submitting a private report, ensure all of the following:
- **You have manually verified the bug.** You understand the code path, you
have confirmed the issue is real, and you can explain it in your own words
without referring back to a tool's output. Reports that you cannot defend
on your own should not be filed.
- **You have a working reproducer.** Attach a minimal reproducer (a JS file,
or a short C snippet against the public API) that triggers the bug on a
recent `master` commit. If you cannot produce one, the report should not be
filed privately.
- **Impact is concrete and verifiable.** State what an attacker can actually
do (e.g. "out-of-bounds read of N bytes from the heap reachable from any
script"), not speculative consequences. Do not enumerate hypothetical
downstream impact.
- **The report is concise and in plain text.** No multi-page write-ups, no
Markdown decorations, no boilerplate severity tables. Lead with the
affected file and function, the trigger, and the impact. If a triager has
to scroll to find what is broken, the report is too long.
- **The threat model matches QuickJS.** The bug must be reachable from
untrusted JavaScript source running in an otherwise trusted embedder. Bugs
that require loading untrusted bytecode, passing crafted values through the
C API, or otherwise compromiing the embedder are out of scope (see above).
- **A proposed fix is welcome, and must be tested.** If you include a patch,
it should compile, pass the existing test suite, and include a regression
test. Untested patches generated by a tool are worse than no patch.
Reports that do not meet these rules may be closed without detailed response
and asked to be refiled publicly.
## CVEs
Not every security-relevant fix in QuickJS requires a CVE. CVE identifiers
exist to help downstream consumers track issues that meaningfully affect
their security posture, they are not a scoreboard, and inflating the count
with marginal or speculative findings makes the catalog less useful for the
people who actually rely on it.
We **mnight** request a CVE when an issue:
- Is reachable from untrusted JavaScript running in an otherwise trusted
embedder (matches the threat model in "Rules for Private Reports"),
- Has a concrete, demonstrated high impact (memory corruption, out-of-bounds
access, etc.), and
- Affects a released version that downstream users are likely to be running.
We will generally **not** request a CVE for:
- Crashes or assertion failures that require malicious bytecode, crafted C
API input, or other embedder compromise (out of scope, see above).
- Bugs found purely by running a publicly available AI tool against the code,
with no additional analysis. By definition, anyone else can run the same
tool and find the same thing.
- Issues already discoverable from the public commit history or issue
tracker by the time the report arrives.