Our NBA Finals game 7 prediction didn't go too well earlier this year, but mark these words now: Piastri and Lando are taking each other out at USGP this week. Annnnnnyways 👇

In Case You Missed It...

• Save the Date for OffensiveCon26 - May 15th and 16th of next year!
• ChkTag: x86 Memory Safety - "ChkTag is a set of new and enhanced x86 instructions to detect memory safety violations, such as buffer overflows and misuses of freed memory (use-after-free). ChkTag is designed to be suitable for hardening applications, operating system kernels, hypervisors for virtualization, and UEFI firmware."
• A major evolution of Apple Security Bounty - Who wants to be a millionaire? Just find an iOS zero click...easy. New max payouts of over $5mil
• Call For Junkyard Bugs - Just a few more days to get your EOL bugs in for DistrictCon's annual Junkyard!

Resources And Write-Ups From This Week:

• Depicting an iOS Vulnerability - Dataflow Security returned to their blog for their third post, this time covering an *OS bug in the GPU kernel driver. The write-up starts with a bit of patch diffing, stepping through the 85 function changes before eventually landing on the buggy culprit. Inside the function intended to create new resource groups, an additional size check was added to ensure one of the attacker supplied parameters is greater than a certain value. The post then takes a bit of a detour, describing background information such as how resource groups work, how hash tables are implemented, and the specific algorithm used by this particular Apple subsystem. All this information becomes relevant to understand how the patched underflow could have led to OOB R/W. However, the write-up concludes with notes about exploitability, concluding that the primitive likely couldn't lead to a working exploit due to modern iOS allocator security hardening.
• Hacking the Nokia Beacon 1 Router: UART, Command Injection, and Password Generation with Qiling - Researcher and best selling author @spaceraccoonsec took to his personal blog this week to discuss a recent Nokia router teardown. We get a first look at the device internals and all of the components. From there, Mr. Racoonsec sets his sights on the UART debug interface, but finds a restricted shell with no low hanging fruit for an easy escape. Pivoting to dumping the flash and REing some web cgi binaries, he then finds a command injection, allowing for a foothold on the device. Next, he takes the binary responsible for generating the password of the UART restricted shell and emulates the key functions using Qniling, outputting the password directly.
• Bootloader to Iris: A Security Teardown of a Hardware Wallet - Sticking with the hardware teardown theme, we have another fun post from @hhj4ck, this time looking at an 'iris-secured' hardware wallet. Spoiler alert, it isn't particularly secured. We first get a glimpse of the various hardware components and the connectivity modules. Next, we immediately learn of a bootloader bug on the device. Specifically, the team seems to have changed some OneKey factory functions, updating the buffer size for the received messages to be much larger. In doing so, the team forgot to propagate those updates to other parts of the fork, leading to a nice stack overflow. Even better, it seems like they just removed the canary entirely, so we can just smash the stack and ROP to code exec. The post then moves on to an interesting auth bypass on the wallet. This bug stems from the fact that the password hash is actually generated by the device id and the user id (both of which can be retrieved via UART) and NOT the 32 byte "password" that we would expect. Disassembling the device and connecting over UART allows you to retrieve the real unlock password.
• Oops! It's a kernel stack use-after-free: Exploiting NVIDIA's GPU Linux drivers - What happens when Quarkslab takes a look at the NVIDIA Linux Open GPU Kernel Modules? Well...they pop them of course. This new post starts with a quick RCA of the two bugs (a null deref and a UAF), but the star of the show is exploitation. The UAF is particularly unusual because it happens in the stack kernel making for quite an interesting primitive. The post gives an overview of why this is and how Vmalloc works under the hood. After this background, we move to shaping primitives, outlining how we can exercise some amount of control over the kernel stack through forking and video4linux2 buffer. In fact, this actually provides enough control to reclaim the UAF, which the post walks through step by step (with very nice numbered lists and colored diagrams). From there, things get even more crazy as we get into leaking addresses and getting a write primitive via the underlying binary Red/Black tree where the UAF lives. We are talking some real big brain exploit stuff going on that our small brains struggled to comprehend on first (and...second) read. The post wraps up with a demo with a full LPE. Prettyyyy sweet.
• CVE-2025-6554: The (rabbit) Hole - Speaking of things we don't understand, a new great post on the recent ITW bug discovered by Google TAG emerged this week. Originally covered @mistymntncop, @r3tr074 decided to put together an analysis of his own, digging deeper into this new variation of "TheHole" exploitation technique. If you are unfamiliar with TheHole, don't worry - the post starts with previous exploits that used the technique to help get you up to speed. Next, we move to looking at this recent June 2025 vulnerability in more depth, understanding how the bug originated from a scope lifetime management bug and breaking down the minimal PoC step by step to show the code paths that lead to its trigger. With a leak of the_hole object "enables a sophisticated and very interesting type confusion attack in TurboFan's compiler", which the post then moves to demonstrate and explain in a step by step breakdown: type confusion, removing the type check, range confusion, and finally crafting a confused index leading to arb read / write.
• Windows ARM64 Internals: Deconstructing Pointer Authentication - Windows extraordinaire @33y0re released a post on the Prelude Security blog this week walking through how PAC works on Windows ARM64. The post starts with a quick overview of PAC in general, and then moves to look at Windows specifics. We start with the enablement / entrypoint, KiSystemStartup, which is in charge of determining if the current device supports PAC and, if it does, doing some brief initialization and set up of the necessary system registers. Next, the post shows how you could actually examine the signing keys using WinDbg, helping to solidify the understanding of how these things are both loaded and used with some dynamic analysis. We then turn our attention to KiDetectPointerAuthSupport, which does the bulk of the PAC set-up. From here, the post looks at how user-mode processes actually get initialized with PAC support, and how each process has its own key. Finally, we get some insight into the practical application and limitations of PAC as an actual exploit mitigation on Windows, as well as a brief section on how Secure Kernel is used to prevent direct system register modification and changing the PAC keys.

Interesting Job Postings:

• Reverse Engineer / Vulnerability Researcher @ The Aerospace Corporation (On-Site: El Segundo, CA)
• Staff Research Analyst (Vulnerability Research) @ Palo Alto Networks (On-Site: Santa Clara, CA)
• Senior Browser Vulnerability Researcher @ Interrupt Labs (Remote: US / Australia)
• Early Career Vulnerability Researcher @ Battelle (On-Site: Columbus, OH)
• Staff Offensive Security Engineer @ Huntress (Remote: US)

Wrapping Up:

As always, thanks for stopping by. We here at the club are always trying to improve so if you have comments, questions, or suggestions, feel free to shoot us an email - info@exploits.club.

Follow us on X - we occasionally Tweet poor attempts at memes

Want to support us? Buy us a coffee ☕️

Don't forget to check out https://bug.directory!

Feel free to join the exploits.club Discord server here 👉 https://discord.gg/2dxN2Gtgpx

Same time next week? See you then 🏴‍☠️