Switch 2 jailbreak

[chester222]

https://pepsipu.com/blog/2026-10-switch2-jailbreak-ns2jb/

Good times are finally here

 

[Mike83]

What great news to wake up to

 

[Vultix93]

Time to buy smileBasic 4?

 

[lightwo]

Exciting, even on latest firmware! But looks like a very time-limited exploit with it requiring a game/software, and it has limited utility for such an expensive device, given there's no way this could be used for emuMMC. Such is the nature of a tethered jailbreak.

 

[SylverReZ]

Wow, first ever PoC exploit for the Switch 2 that actually works. Unfortunately, I don't have SmileBASIC installed on my Switch 2 and I'm worried about updating it, just because I'd like to know if there are any exploits that could take advantage of older FWs.

 

[Octoblimp]

Exciting, even on latest firmware! But looks like a very time-limited exploit with it requiring a game/software, and it has limited utility for such an expensive device, given there's no way this could be used for emuMMC. Such is the nature of a tethered jailbreak.

You know I only finally got my 3DS homebrewed after EmuNAND went out of fashion. What's the benefit of emulated NANDs and MMCs to begin with? Why was it done for the 3DS and now no more?

 

[lightwo]

You know I only finally got my 3DS homebrewed after EmuNAND went out of fashion. What's the benefit of emulated NANDs and MMCs to begin with? Why was it done for the 3DS and now no more?

I'm talking mainly about ban risk. Nowadays it is virtually non-existent on 3DS (not that Nintendo Network is around any more), but on Switch (and clearly Switch 2) it is very real, depending on what you do. On Switch, it has been instrumental to making the most use out of the device in a modded state, so I can't imagine Switch 2 being very different in that regard.

Updates, too, but brick risk could be very real as well, given the still somewhat early developments. Safe hacking is supposed to prevent that, but times have changed...

 

[Octoblimp]

I'm talking mainly about ban risk. Nowadays it is virtually non-existent on 3DS (not that Nintendo Network is around any more), but on Switch (and clearly Switch 2) it is very real, depending on what you do. On Switch, it has been instrumental to making the most use out of the device in a modded state, so I can't imagine Switch 2 being very different in that regard.

Although brick risk could be very real too, given the still somewhat early developments.

Even back when the 3DS was still the newest handheld, EmuNAND's were killed off later on and were advised against due to high risk. Nintendo Network is also still around, just...not for much. Its around for the eShop only pretty much.

 

[Vultix93]

Exciting, even on latest firmware! But looks like a very time-limited exploit with it requiring a game/software, and it has limited utility for such an expensive device, given there's no way this could be used for emuMMC. Such is the nature of a tethered jailbreak.

I'm not well versed in this stuff but I asked claude to make a simple recap of the article. Apparently, if what the author says is true, you could:

• Run homebrew. Your own native code, with the permissions of an ordinary system service or of fs.
• Mod games. He modded Mario Kart World to add characters.
• Reverse-engineer games and the system. He dumped the console’s internal storage and the code of system services so they could be analyzed offline.
• Back up save files off the console.
• Access hardware directly, since most of the Switch 2’s peripherals can be reached at a low level.
  
  That's pretty neat

 

[Reshiban]

Oh gosh, should I stay on this firmware and say bye to the online...

 

[lightwo]

I'm not well versed in this stuff but I asked claude to make a simple recap of the article. Apparently, if what the author says is true, you could:

• Run homebrew. Your own native code, with the permissions of an ordinary system service or of fs.
• Mod games. He modded Mario Kart World to add characters.
• Reverse-engineer games and the system. He dumped the console’s internal storage and the code of system services so they could be analyzed offline.
• Back up save files off the console.
• Access hardware directly, since most of the Switch 2’s peripherals can be reached at a low level.
  
  That's pretty neat

I'm not saying it isn't interesting, I'm just saying it will probably more interesting for developers rather than regular users. At least if you don't mind no updates, and a ban and brick risk, which to me is quite concerning considering the price of Switch 2.

 

[ChanseyIsTheBest]

WTF We are living in a crazy world
AI has infinite patience and someone could just send out infinite agents to try and hack the Switch 2 and I guess this is what happens.

 

[Apache Thunder]

Wait...this is real? I thought this was a spam bot posting a malware/scam link and just assumed it will get nuked by mods soon so I moved on with to other things....LOL

Still userland I suspect but interesting someone finally got something going on this console.

 

[ertaboy356b]

Time to buy the game and have it installed, just in case.

 

[Givemesteak]

@ChibiMofo

ChibiMofo

Now you're proven wrong as I said you would be

And before you go "Well this is only a userland exploit" That's enough for now.
This will skyrocket our understanding of the system and help out tremendously in our search for other vulnerabilities.

 

[Apache Thunder]

If only this was revealed after the 40th Anniversary Zelda Switch 2 arrived. Else I'd consider trying this. But at this point I will probably hold off because I am like 90% sure the exploit will be patched and/or the exploited game will be patched/pulled by next week. I just doubt it will survive the system transfer I need to do to from my old Switch 2 to my new one.

 

[lightwo]

If only this was revealed after the 40th Anniversary Zelda Switch 2 arrived. Else I'd consider trying this. But at this point I will probably hold off because I am like 90% sure the exploit will be patched and/or the exploited game will be patched/pulled by next week. I just doubt it will survive the system transfer I need to do to from my old Switch 2 to my new one.

Can "match with other users" be useful at all here? Either way, it definitely wouldn't help for smileBASIC as it would be updated by then (if not already)...

 

[ertaboy356b]

Deepseek AI writeup

ns2jb / software-only, tethered Switch 2 jailbreak
firmware 23.0.1 - first of its kind - tether required

Write-up https://pepsipu.com/blog/2026-10-switch2-jailbreak-ns2jb/
Source https://gitlab.com/pepsipu/ns2jb

--------------------------------------------------------------

>> WHAT IT DOES

• Tethered, software-only, on the latest 23.0.1 firmware.
• Arbitrary native code execution as any ordinary sysmodule, plus the built-in fs sysmodule.
• Enough for homebrew, game modding and reverse engineering, pulling saves off the console, and MMIO access to most peripherals.
• Demo: Mario Kart World modded with three added characters.

>> HOW IT WAS DEVELOPED

• The author built a rig so an AI agent (Codex) could operate the consoles unattended: two JetKVMs (USB controller input in, HDMI video out) plus a Bluetooth light-switch flicker rig to press the power button after crashes.
• Opening prompt: "set a goal to jailbreak the switch 2. make no mistakes"
• Several Codex instances worked different attack surfaces in parallel.

>> ATTEMPT 1: WEBKIT - FAILED

• An n-day got a claimed native control-flow hijack using Math.expm1 and XHR, delivered via a custom Wi-Fi captive portal.
• It does not generalize to arbitrary IPC calls. Three reasons:
  • XOM - you cannot find a usable gadget even with arbitrary read/write.
  • PAC - you cannot build a valid signed pointer for it.
  • CFI - most call sites are type-checked, so you could not call it anyway.
• The goal was reset to attack those three; a footnote confirms it did not succeed.
• Worth revisiting later: WebKit ships offline, so Nintendo cannot withdraw it the way it can delist an eShop title.

>> ATTEMPT 2: SMILEBASIC - THE PATH THAT WORKED

• Switch 1 games were targeted deliberately: the Switch 1 does not support PAC, and its root of trust is owned, so game code can be decrypted and read.
• Bug: 32-bit integer overflow in the BASIC interpreter's array REMOVE. The bounds check (position + count <= length) can wrap negative.
• With a 4-element string array, REMOVE R,&H60000000,&H3FFFFFFF makes the gap-filling memmove become effectively memmove(backing, backing - 8, 32).
• The 8 bytes before any array hold a pointer to the array itself, so that pointer lands in R[0]'s length field: huge fake string, arbitrary OOB read/write via substring copies.
• It reports Out of memory afterwards, but the copy has already happened.
• This agent iterated on a Switch 1 while the WebKit agent worked on the Switch 2, and eventually got ROP.

>> ESCALATION 1: READ/WRITE IN THE fs SYSMODULE

• fs was chosen because it can serve decrypted code, it is a large codebase, and its API barely changed from Switch 1.
• Heap overflow: IFileSystem::GetEntryType normalizes the path, and a parent-dir component with a backslash (/..\) takes a path that allocates a 0x301-byte temporary heap buffer, then copies the oversized path in.
• Overflow target: a BufferedStorage per-file cache entry; hijack its backing pointer for arbitrary read/write.
• Stability trick: use one overflow to point cache entry A's backing pointer at cache entry B's metadata, then swap B's pointer freely without more overflows.
• Then set SmileBASIC's saved PID in fs' connection object to 1. Built-in sysmodules get hardcoded registration data, so the process gains FullPermission.
• Result: internal storage and the code of every ordinary sysmodule dumped for offline analysis.

>> ESCALATION 2: CODE EXECUTION AS ANY ORDINARY SYSMODULE

• The only ordinary sysmodule allowed to map executable memory is ro, and its interface is minimal, so the author went after a logic bug rather than memory corruption.
• The loading signature chain looks sound on paper:
  • NPDM signature fixes process permissions and the dev key
  • dev key fixes the NCA header signature
  • signature fixes the header hash
  • header fixes the filesystem hashes
  • filesystem hashes fix the code
• The weak link is the last one. fs is the one trusted to prove the served filesystem matches the header hash, and by this point we own fs.
• So swap the ExeFS object behind ldr's IPC handle for a temporary filesystem serving the real main.npdm alongside an arbitrary main. The header checks still pass, because fs already handed over the legitimate hash and signature for the original filesystem.
• Timing is the hard part: two writes must land after the ExeFS request but before fs handles the following file requests.
• Solved by replacing the handle fs waits on for ldr's connection with an attacker-controlled event handle, gating exactly when fs services loader messages.
• The second write exists only to keep refcounts consistent so fs does not crash.

>> GETTING INTO A BUILT-IN SYSMODULE (fs ITSELF)

• With arbitrary read/write, any program's NPDM can be copied out through loader's fsp-srv connection.
• Launch custom code under ro's NPDM, which may call SetProcessMemoryPermission, MapProcessCodeMemory and MapProcessMemory.
• MapProcessMemory gives a writable view of fs' live code, which also lets you dump it.
• Those SVCs need a KProcess handle to fs. Trick: overwrite IEventNotifier's 4-byte handle with 0xffff8001 (the current-process pseudo-handle) and call GetEventHandle from SmileBASIC to receive fs' KProcess handle.
• Hand it to the ro process, which patches fs' code.
• Because fs is a built-in sysmodule, SM skips its service ACL checks, so this is smhax-equivalent capability.

>> CAVEATS AND NEXT STEPS

• Still tethered, and there is no route into built-in sysmodules other than fs yet.
• Next obvious move: port the fs primitive to WebKit. With the target bug already known, a data-only attack may be enough, and it would take the tether out of the entry point.
• With code execution in fs, its crypto hardware can be driven directly, for example for NCA4 decryption.
• Also works on Switch 1, but is not packaged yet. Not modchip-equivalent, though it needs no external hardware.
• Closing thought from the author: Nintendo may eventually serve all code as encrypted blobs only the kernel or secure monitor can decrypt, which would eliminate RX mappings in userspace entirely. They have already removed dynamic-code features like the JIT sysmodule.

 

[Elrasiel]

I wonder if it’s a hardware vulnerability that can never be completely patched out.

 

[Givemesteak]

I wonder if it’s a hardware vulnerability that can never be completely patched out.

No this is a software exploit, I expect it to be patched soon