ns2jb explained: the software-only exploit chain that broke the Nintendo Switch 2’s trust boundary

On October 22, 2026, security researcher Sammy Hajhamid, who goes by pepsipu, publicly detailed ns2jb, a software-only jailbreak for the Nintendo Switch 2 on firmware 23.0.1. The previous generation’s homebrew scene depended on hardware modchips. ns2jb needs no hardware changes. It chains a bug in a legacy application with a privilege escalation in the console’s filesystem service, and the result is native code execution inside that service. Hajhamid also used AI-assisted development tools, including OpenAI’s Codex, to work through the new architecture.

Much of the coverage has treated this as a finished custom firmware. It is a tethered research proof-of-concept. This article walks through each stage of the chain and what it shows about memory safety, interprocess communication (IPC), and cryptographic verification.

Why the browser route failed on the Switch 2

Console exploitation usually starts with the web browser, which has a large attack surface and a lot of complex parsing code. Hajhamid first tried a WebKit-based vector and got a control-flow hijack inside the browser. Turning that foothold into the IPC calls needed to reach privileged system services did not work, because the Switch 2 ships with strong ARM mitigations.

Three of them matter here. Execute-Only Memory (XOM) blocks ordinary reads of memory regions that hold code, so an attacker cannot scan for return-oriented programming (ROP) gadgets. Pointer Authentication Codes (PAC) cryptographically sign critical pointers, which stops arbitrary control-flow redirection. Control-Flow Integrity (CFI) limits indirect branches to verified targets. With all three in place, a browser exploit can crash a process or run code locally, but it lacks the stability and visibility needed to build the IPC payloads that attack the operating system. The research moved to a less hardened part of the system: the backward compatibility layer.

The SmileBASIC 4 integer overflow

The entry point was SmileBASIC 4, a programming environment first built for the earlier hardware and supported on the Switch 2 through backward compatibility. Keeping old code also keeps the security assumptions it was written under. SmileBASIC is a large C++ application, and its interpreter has a memory-handling bug caused by faulty arithmetic validation when elements are removed from an array.

The interpreter has to confirm that the requested range fits inside the allocated bounds. A common but flawed check adds the start position and the element count, then compares the sum to the array length:

if (position + count <= length) {
    /* Proceed with memmove */
}

In 32-bit arithmetic, a sum that exceeds the maximum value wraps around to a small number, and that number passes the check. The safe version compares each operand against the space available, so the addition never happens:

if (position > length || count > length - position) {
    return ERROR_OUT_OF_RANGE;
}

Because the interpreter relies on the wrapped arithmetic, it accepts the invalid range and shifts the remaining elements with a memmove-style copy. The copy length and source pointers come from the corrupted arithmetic, so the copy pulls in data from just before the array’s backing store. The interpreter may throw an out-of-memory exception afterward, but only once the corruption has already happened. That leaves the process unstable and exploitable.

How the overflow becomes arbitrary read and write

How useful this corruption is depends on how SmileBASIC lays out its objects. According to the technical analysis, the eight bytes before the array’s backing store hold a pointer to the array’s own metadata. The out-of-bounds copy drags that pointer into the array, where the type-handling logic treats it as a string element. The pointer lands in the field that normally stores string length, so the interpreter reads a memory address as an enormous length.

That turns a local arithmetic error into an arbitrary read and write primitive. Ordinary substring operations can reach nearly any address in the SmileBASIC process. The primitive stays inside that userland process, and it gives no kernel access or filesystem privileges. It does let the attacker map the heap, find key objects, and build a stable ROP chain, which is the base needed to talk to the console’s IPC layer and go after a more privileged service.

The heap overflow in fs path normalization

The next target was the filesystem system module, called fs. System modules run with elevated privileges and mediate access to critical resources. fs is especially valuable because it handles ordinary file I/O and also takes part in verifying and loading executable content for other system modules and games.

The bug is in path normalization, in the Path::Normalize routine called during GetEntryType operations. Filesystem APIs have to sanitize relative components such as parent-directory references to prevent directory traversal. In the vulnerable code, a helper allocates a fixed 769-byte temporary heap buffer for the normalized path but does not properly enforce the relationship between that capacity and the length of the attacker-controlled input. A path with specific backslash and parent-directory sequences triggers a heap buffer overflow, which writes past the allocation and corrupts adjacent heap metadata.

Heap feng shui with BufferedStorage

A heap overflow is only as useful as what sits next to the vulnerable buffer. To turn it into a reliable read and write primitive inside fs, the exploit uses heap feng shui to shape the service’s allocation state. It targets a BufferedStorage object, a cache that reduces redundant access to physical storage. Each cache entry holds metadata, including pointers to the cached data buffers and a flag showing whether the data has been modified, known as the dirty bit.

By grooming the heap, the exploit places the vulnerable path buffer right next to the metadata of a target BufferedStorage entry. The overflow then overwrites that entry’s internal pointers and sets its dirty bit. When fs later reads or writes the entry, it follows the corrupted pointers, which gives the attacker arbitrary memory read and write inside the highly privileged address space of fs. This is where the chain crosses a process boundary, moving from a restricted userland application into a core operating system service.

A time-of-check to time-of-use flaw in code loading

With arbitrary memory control inside fs, the exploit goes after the executable loading mechanism. The Switch 2 packages executable content in Nintendo Content Archives (NCAs). An NCA includes an ExeFS filesystem holding the main binary and a metadata file, main.npdm, which defines the process’s permissions, capabilities, and the developer’s public key. Nintendo’s signature guarantees the integrity of the NPDM file.

The system loader, ldr, requests the ExeFS from fs over an IPC handle and checks the executable against the provided cryptographic hashes before mapping it into memory. The security model assumes fs will serve exactly the data that was verified, following this chain of trust:

Nintendo's signature -> Authenticated process metadata (main.npdm) -> Developer public key -> Authenticated NCA header -> Filesystem integrity information -> Executable content (main)

ns2jb breaks that assumption with a time-of-check to time-of-use (TOCTOU) inconsistency. By changing the internal IPC state of the compromised fs service, the researcher replaces the handle fs waits on for the loader’s connection with an event handle controlled by the initial SmileBASIC payload. That lets the attacker control when the loader’s requests arrive: after verification of the original NCA header has succeeded, but before the executable bytes are read into memory.

In that window, the arbitrary write primitive inside fs swaps the ExeFS object tied to the loader’s IPC handle. The substitute keeps the original, validly signed main.npdm, so the loader’s permission and identity checks pass. The main binary, however, is replaced with attacker-controlled code. The loader trusts fs to preserve the integrity of the verified package, so it maps the malicious binary and runs it.

The signatures and hashes are mathematically sound. They just do not help when the component that delivers the verified data can be made to deliver something else afterward. The exploit does not break Nintendo’s cryptography, forge signatures, or extract private signing keys. It uses the gap between the verification decision and the use of the verified resource to bypass the console’s executable integrity model.

Getting code execution inside fs

Running native code under a valid NPDM file grants the permissions of an ordinary system module, but the research aimed higher: code execution inside fs itself. The exploit uses the permissions of the ro (Relocation) system module, which has the memory-mapping abilities needed to load and patch executable code.

It manipulates an IEventNotifier object and overwrites a four-byte handle field with the value 0xffff8001. In the Switch 2 kernel, that value is interpreted as a reference to the current process, which hands the exploit a KProcess handle to fs. With that handle and the memory-mapping system calls available in the context of ro, the attacker maps the code section of fs into their own address space as writable and patches the filesystem service’s executable code in memory. The result is a privileged execution environment inside one of the console’s most critical system modules.

Is ns2jb a full jailbreak for the Switch 2?

No. Hajhamid’s public repository is a narrow proof-of-concept. It demonstrates native execution inside fs, verifies the results, and restores the original instructions. It does not include a custom firmware, a persistent homebrew launcher, or any permanent change to the console’s firmware.

The exploit is tethered, so its effects disappear on reboot. The activation sequence depends on timing-sensitive manipulation of IPC handles and does not succeed every time on every hardware revision. Setup requires a computer running macOS or Linux, Node.js 22 or later, a network connection to the console, and a $25 copy of SmileBASIC 4. The work shows that the Switch 2’s security boundaries can be crossed through software alone, but it is a research-grade exploit chain, not a platform for everyday homebrew development.

Security lessons from ns2jb

These lessons apply well beyond the Switch 2.

Memory safety bugs still turn up in privileged code. Integer overflows and heap buffer overflows survived in both the SmileBASIC interpreter and a core system service. PAC and XOM raise the cost of browser exploitation, but they cannot make up for logic errors in array handling or path normalization.

Privilege separation only works if the interfaces between processes are carefully sanitized. Internal state such as cache pointers and IPC handles has to be treated as security-sensitive, so that adjacent memory operations cannot corrupt it.

A valid signature is a statement about a specific message at a specific moment. For verification to mean anything, the link between verified metadata and the data actually used must stay fixed through loading and execution.

Backward compatibility also carries old attack surface forward. A memory-handling flaw in a game-era application became the entry point into a modern, heavily protected console. Nintendo can be expected to patch the SmileBASIC 4 bug and the fs path normalization flaw.

Frequently asked questions about ns2jb

What is ns2jb?

ns2jb is a software-only exploit chain for the Nintendo Switch 2 on firmware 23.0.1, detailed publicly by researcher Sammy Hajhamid (pepsipu) on October 22, 2026. It achieves native code execution inside the fs filesystem service without hardware modifications.

Which vulnerabilities does ns2jb use?

It chains an integer overflow in the SmileBASIC 4 interpreter’s array handling, a heap buffer overflow in fs path normalization, and a time-of-check to time-of-use inconsistency in how the loader receives verified executable content.

Does ns2jb permanently jailbreak the console?

No. It is tethered, so its effects are lost on reboot, and the public repository does not provide a custom firmware or a persistent homebrew launcher.

What do you need to run ns2jb?

A computer running macOS or Linux, Node.js 22 or later, a network connection to the console, and a copy of SmileBASIC 4, which costs $25.