Someone recently reached out any said it was supposed to be "anyway" instead of....Annnnnnyways 👇

In Case You Missed It...

• BSides London CFP Open Now - get-em in!

Honestly...nothing else really happened this week. I finished Sword Of Kaigen

Resources And Write-Ups From This Week:

• The One Where We Just Steal The Vulnerabilities (CrushFTP CVE-2025-54309) - Now normally, when our friends over at Watchtowr catch wind of a recently patched vuln targeted ITW, they break out the patch differ. This go-round, they decided to try something a bit different. Instead of trying to go through an RCA themselves, they decided just to throw a vulnerable CrushFTP into their honeypot environment and see what happens. Within a few days, it went offline and with some investigation the team was able to find a pattern in what appeared to be malicious requests. Setting up an internal instance for testing, they copied the attacker's homework (or in this case...a race condition triggered by two HTTP requests) and were successfully able to reproduce the ITW exploit...no patch diffing required.
• HITCON CTF 2025: calc - We always enjoy a good "how-the-sausage-gets-made" post when it comes to CTF chals. This week, @bruce30262 took to his blog to discuss a recent pwn challenge he designed for HITCON CTF. The post starts with a little background on the challenge and what inspired its creation, and then digs into the set-up, the vulnerability, and exploitation. The binary in question is AARCH64, with both PAC and BTI enabled and a fairly straight forward UAF. However, the added mitigations make it anything but trivial to try and exploit, especially the relative vtables, which render the standard BTI bypass techniques obsolete. The full exploit involves leaking the base address by triggering a virtual function, controlling the vtable and getting arb read / write, and turning that into RCE. Overall it's a fun but tough challenge - only 5 teams came away with a solve!
• ARTIPHISHELL: The Requiem - At this rate, we are just covering one AIxCC contestant per week. On the chopping block this week: Shellphish. The team just released a post about the "errors and failings" of their final submission, discussing how the team's final system fared and how they ended up taking 5th overall. The architecture of the solution looks very reminiscent of the others we have covered here at the club: a static analysis engine -> dynamic analysis engine -> triage engine -> patching engine. During the post-mortem, the team walked through a handful of issues - most notably a misconfiguration that effectively rendered their "secret weapon" grammar generator all but useless. Because this was a core component, it had quite a few downstream effects on pipeline components that relied on this system to be working properly. Not only that, but the submitter had a bug as well, meaning some valid submissions didn't make their way into the competition. Their post includes other last minute issues as well as learnings from each mistake, and is certainly worth the read for anyone in the space.
• From Chrome renderer code exec to kernel with MSG_OOB - During all the hacker summer camp madness, we admittedly missed a P0 blogpost. And as self-proclaimed Project Zero fanboys, we recognize this unacceptable behavior and sincerely apologize. That said, Jann Horn released a post about a bug he found in the new Linux Kernel MSG_OOB feature. After reporting the bug, he noticed something interesting...the attack surface was exposed to the Chrome renderer sandbox. That naturally lead to the question: can you go from native code exec in the renderer directly to the kernel? Spoiler alert...yes, if you are Jann Horn. What follows is an explanation of each step of the exploitation process, as Jann discusses the initial primitives from the bug, challenges in the constrained environment, and the ever evolving strategy he took to write a successful exploit.
• Walk through Android physical memory: CVE-2025-21479 - Break out the Google translate for this one, it's worth it. After 3 vulnerabilities in the Qualcomm June Bulletin, jd decided to dig into the patches and better understand what was going on. Well as it turns out, the Adreno firmware had a fatal microcode miscarriage that led to a misrepresentation of the privilege directive. In plain words, the GPU microcode "is mistakenly granted the highest privilege at its RB Level". This has ramifications related the the SMMU, and allows for the GPU's first level page table to be reconfigured. From there, it's possible to get physical read / write. The post then goes through the various ways this can be converted to LPE, including bypasses for SELinux and data only exploit strategies that help bypass core integrity protection mechanisms.

Interesting Job Postings:

• Offensive Cyber Engineer @ REDLattice (On-Site: Arlington, VA)
• Senior Vulnerability Researcher @ Two Six Technologies (On-Site: Arlington, VA)
• Reverse Engineer @ Worldpanel (Hybrid: Copenhagen, Denmark)
• Firmware Security Engineer @ AMD (On-Site: Austin, TX)
• Senior Cyber-Physical Security Engineer @ Integer Technologies (On-Site: Baton Rouge, LA)

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