rNES is a Nintendo Entertainment System emulator written in C. It parses untrusted input by design — a .nes ROM file is attacker-controlled data — so memory-safety bugs in the ROM decoder, the cartridge mappers, or the emulated hardware modules are real security issues, not just accuracy bugs. We take them seriously.

rNES is a small project. Security fixes land on main.

Third-party builds and packages are the responsibility of whoever produced them.

Please do not report security vulnerabilities in public issues, pull requests, or discussions.

Report privately through GitHub:

1. Go to https://github.com/rene/rNES/security/advisories/new (repository → Security tab → Advisories → Report a vulnerability).
2. Fill in the report. Only the repository maintainers can see it.

If private advisory reporting is unavailable to you for any reason, open a regular issue that says only that you have a security report and would like a private channel — with no technical details — and a maintainer will follow up.

The more of this you can provide, the faster the fix:

• A description of the issue and the impact you believe it has.
• A proof-of-concept ROM. A crafted .nes file that triggers the bug is by far the most useful thing you can send. Attach it to the advisory, or include a small script that generates it. Do not send copyrighted commercial ROMs — construct a minimal file instead.
• Reproduction steps, including the exact command line (./rNES <rom>, scale factor, flags).
• Build details: commit hash, compiler and version, OS, SDL2 version, and whether it was a native POSIX build or the MinGW-w64 cross-build.
• Sanitizer output, if you have it. A build with -fsanitize=address,undefined -g and the resulting stack trace makes triage dramatically easier.
• Whether you believe the issue is exploitable beyond a crash, and any constraints you found.

Anything where loading or running a malicious ROM (or other untrusted input) lets that input reach beyond emulation:

• Out-of-bounds reads or writes in romdec.c, cartridge.c, sbus.c, the PPU or APU, or any mapper — including from malformed iNES / NES 2.0 headers, inconsistent PRG/CHR sizes, or out-of-range bank numbers.
• Heap or stack buffer overflows, use-after-free, double free, or type confusion.
• Integer overflows in size or offset computations that lead to any of the above.
• Uncontrolled memory allocation or unbounded recursion driven by header fields.
• Path traversal or unsafe file handling in the HAL file I/O layer.
• Any path from a ROM file to code execution on the host.

• Emulation inaccuracy. Wrong colors, wrong audio, a game that hangs or glitches, an unimplemented mapper — these are bugs, not vulnerabilities. Please file them as normal issues.
• Crashes on invalid input that only affect the emulator process, where the emulated program is behaving as the hardware would. rNES does not sandbox the emulated machine from itself; a game that crashes itself is not a rNES vulnerability. A malformed file that crashes rNES is.
• Issues in dependencies (SDL2, SDL2_ttf, the MinGW-w64 toolchain, Qt6 for the PaletteEditor). Report those to their maintainers; if rNES uses them in an unsafe way, that part is in scope here.
• Bugs that require the user to build rNES with modified sources or non-default compile flags.
• Reports generated by automated scanners with no demonstrated impact.

Note also that rNES runs with the privileges of the user who started it and opens whatever file it is pointed at. It is not a security boundary, and it is not designed to safely execute deliberately hostile software — the goal of this policy is that a malicious ROM file cannot corrupt memory or escape onto the host.

rNES is maintained in spare time, so these are good-faith targets rather than guarantees:

• Acknowledgement of your report within 7 days.
• An initial assessment — confirmed, needs more information, or out of scope — within 14 days.
• A fix on main as quickly as the severity warrants, with high-severity memory-corruption issues taking priority over everything else.
• Public disclosure once a fix is available, via a GitHub Security Advisory. We aim to coordinate disclosure within 90 days of the report; if a fix will take longer, we will tell you and agree on a timeline with you.
• Credit in the advisory and in the commit message, under whatever name and contact you prefer. Tell us if you would rather stay anonymous.

rNES has no bug bounty program.

We will not pursue or support legal action against anyone who reports a vulnerability in good faith under this policy: research on your own systems, using ROMs you are entitled to have, without exfiltrating data belonging to others, and giving us a reasonable opportunity to fix the issue before disclosing it publicly.

For ordinary bugs and accuracy problems, please open a public issue — see CONTRIBUTING.md for what to include.