Please report security vulnerabilities through GitHub's private vulnerability reporting feature, only if your report meets the rules below. Reports that do not meet these rules should be filed as regular public issues instead.

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.

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.

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.