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.

rquickjs provides safe, high-level Rust bindings to the QuickJS-NG engine. This policy covers bugs in the bindings: unsoundness in the safe API, incorrect unsafe at the FFI boundary, memory-safety issues reachable without writing unsafe, and mistakes in features rquickjs itself implements (data conversion, class registration, module loaders/resolvers, allocators, the embed macro, async integration).

• Soundness holes: any way to trigger undefined behavior, memory corruption, or a data race from safe Rust using only the public API. A safe wrapper that allows UB without unsafe is a bug in rquickjs.
• Incorrect FFI assumptions: lifetime, ownership, or invariant mismatches between the Rust layer and the C engine that lead to use-after-free, double free, or out-of-bounds access.
• Wrapper logic errors in conversion, class binding, Trace/GC integration, loaders, or the embed-generated bytecode path.

• Bugs inside the QuickJS-NG engine itself. Crashes, memory corruption, or sandbox escapes originating in the C engine (reachable from untrusted JS source) should be reported upstream to quickjs-ng/quickjs. If a fix requires changing engine C code, it is upstream's issue, not rquickjs's.
• Bytecode hardening. QuickJS bytecode is not designed for adversarial input. Loading untrusted bytecode (including via the embed macro or JS_READ_OBJ_BYTECODE) is equivalent to executing untrusted native code. Only load bytecode you produced yourself or obtained from a trusted source.
• Misuse of unsafe APIs by the caller. rquickjs exposes some unsafe functions with documented invariants; violating those invariants is caller error, not a vulnerability.
• Untrusted C API input passed through raw handles, or anything that requires the embedder to already be compromised.

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. File those as public issues, where duplicates are visible and the fix discussion is shared. AI tools are welcome, but use them to add value: read the code, confirm the bug, write a patch, write a test. A drive-by forward of a tool's raw output 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, confirmed the issue is real, and can explain it in your own words.
• You have a working reproducer. Attach a minimal reproducer — ideally a small Rust program using only safe rquickjs APIs (or a short snippet showing the exact unsafe invariant that is unsound) that triggers the bug on a recent master commit. Note the rquickjs version and the QuickJS-NG submodule commit.
• Impact is concrete and verifiable. State what actually happens (e.g. "use-after-free reachable from safe code via Ctx::…"), not speculative consequences.
• The report is concise and in plain text. Lead with the affected module, function, and the invariant that breaks. No multi-page write-ups or severity tables.
• The threat model matches rquickjs. The bug must be a soundness or memory-safety defect in the bindings, triggerable without the caller writing incorrect unsafe. Engine-internal bugs and bytecode issues are out of scope (see above).
• A proposed fix is welcome, and must be tested. A patch should compile, pass cargo test (including under Miri where applicable), and include a regression test.

Reports that do not meet these rules may be closed without detailed response and asked to be refiled publicly.

Confirmed, released soundness or memory-safety issues in the bindings will be published as GitHub Security Advisories and, where they meaningfully affect downstream crates, submitted to the RustSec Advisory Database. We generally will not request advisories for issues that require unsafe misuse by the caller, engine-internal bugs (track those upstream), or findings already discoverable from the public commit history by the time the report arrives.