Happy Friday. Almost that time of the week again:

Annnnnyway 👇

In Case You Missed It...

• Google Cloud VRP: Enhancing Transparency and Impact in Our Rewards Program - Some VRP updates for Google Cloud with more transparency and consistency, less ambiguity
• New chITchat by pamoutaf Episode - A chat with @PinkDraconian that released today!
• As many as 2 million Cisco devices affected by actively exploited 0-day - Very cool...

Resources And Write-Ups From This Week:

• CVE-2025-23298: Getting Remote Code Execution in NVIDIA Merlin - ZDI took to the interwebs this week to release details on a recent deserialization bug they found in NVIDIA Merlin Transformers4Rec. The post starts with an overview of NVIDIA Transformer4Rec, describing how it is used in production environments "for building recommendation systems, specifically in e-commerce and content platforms". From there, the post shows how this particular codebase calls directly into PyTorch's torch.load() without any checks. Because this uses Python's pickle module under the hood, this leads to a class deserialization vuln. ZDI also highlights the attack surface in more detail, shows how to craft an exploit to trigger the buggy code path, and talks about the potential impact. It rounds out with an analysis of NVIDIA's patch and some takeaways.
• Exploring GrapheneOS secure allocator: Hardened Malloc - Everyone knows the best reason to pick up a Pixel these days is so you can run Graphene on it. And if you were ever curious about the custom, hardened allocator the Graphene team has implemented...well, fear not. Synacktiv decided to put together a little rundown of it for you this week on their blog. The post starts broadly outlining protections that contribute to the memory allocator hardening, such as the extended address space, the secure app spawning, and MTE. From there, we learn a bit more about the hardened malloc architecture, digging into how the metadata and user data are stored in separate memory regions and what structures are used to accomplish this isolation. Next, we look at small vs large allocations and how they are classified, allocated, and subsequently freed. Synacktiv then quickly touches on how this makes different bug classes much more difficult to exploit, and comments both on the cleanliness and effectiveness of the implementation.
• Hibernation crash traced to Intel GPU driver (igdkmdn64) during power transition - Who doesn't enjoy a good RCA...slowly pulling on a thread until either a bug or your mental health unravels. In a write-up released this week, we get a first-hand look at this process for a non-reproducible crash in an Intel GPU driver. The post walks us through the initial crash dump and a quick analysis, indicating it might have happened while Windows was "decompressing a paged-out, compressed memory page". Next, we look at the load the device was under when the crash occurred, understanding the amount of memory committed and potential kernel stack-pressure. After ruling out Chrome as the culprit, we then run through some additional backtracking, eventually keying in on the faulty driver. A bit more triaging leads us to the conclusion: "The laptop crashed while going into hibernation because the Intel graphics driver didn’t finish powering the GPU down." The post comes loaded with all the commands run, and the full process to identify the cause of this crash. Certainly useful for anyone getting into Windows work!
• Project Rain:L1TF - Google has really been digging into CPU vulns as of recent. And for good reason given the potential effects on their cloud environments. In August, we saw them digging into how Retbleed could be exploited in the real world. This week, they followed up with some new research in conjunction with VuSec to disclose a new CPU vulnerability affecting some Intel CPUs. Per usual, the post starts with the "context to help readers understand how someone could exploit L1TF to hypothetically conduct an attack, and mitigation strategies to fix the vulnerability." This includes sections on caching, speculative execution, hyper-threading, multitasking, memory addressing, virtualization...basically CPUs 101. It then moves into the actual vulnerability, an arbitrary speculative read of data in the L1 data cache. This can be abused to achieve an arbitrary RAM read primitive. After explaining how this vulnerability manifests, we then run through how the exploit actually works. Finally, it rounds out with a discussion on mitigation and the subsequent fix.
• Taming 2,500 compiler warnings with CodeQL, an OpenVPN2 case study - What do you do when your research target has 2,500 implicit conversion compiler warnings? Well, if you are ToB, you write a new CodeQL query. In their new post, the team discusses how while looking at OpenVPN2, they were forced to try and pare down these compiler warnings to find the security critical ones. The post walks through what may make a conversion security critical (putting together a nice little chart for your review). From there, they move to modeling these patterns in CodeQL, walking step by step through finding the conversions, getting the to and from types, ruling out constants, applying range analysis, leveraging code-base specific patterns, and focusing on user-controlled inputs. They walk through how each of these steps trimmed the potential findings list down, with just 20 remaining high-priority review cases (no vulns though, sadly). The queries are open source, should you want to review or use them!
• This Virtual Memory Trick Copies Data Instantly (iOS VM Internals) - @bellis1000 returns to YouTube this week, back with the trademarked color-scheme and animations. This time, he is helping you better understand how the iOS Kernel copies memory. The post starts with a high level overview of how virtual and physical addresses work, using a hypothetical translation to solidify the idea. From there, we move to understanding the kernel's vm layer, walking through each step of a theoretical userspace program using the kernel's virtual memory API. It's a great primer for anyone looking to better understand the subsystem for either a development or VR lens.

Interesting Job Postings:

• Founding Security Researcher @ ZeroPath (Remote: USA)
• Security Researcher, Security Products @ OpenAI (On-Site: San Francisco, CA)
• Vulnerability Researcher / Exploit Developer @ REDLattice (On-Site: Annapolis, MD)
• Senior Software Security Compiler Engineer @ NVIDIA (Remote, maybe (?))
• Malware Reverse Engineer @ Booz Allen Hamilton (On-Site: Annapolis Junction, MD)

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 🏴‍☠️