LLMs are helping devs write code, but is it secure code? How are LLMs helping appsec teams? Keith Hoodlet returns to talk about where he's seen value from genAI, where it fits in with tools like source code analysis and fuzzers, and where its limitations mean we'll be relying on humans for a while. Those limitations don't mean appsec should dismiss LLMs as a tool. It means appsec should understand how things like context windows might limit a tool's security analysis to a few files, leaving a security architecture review to humans.
Segment resources:
Keith Hoodlet is an Engineering Director at Trail of Bits, where he leads a world-class team of AI/ML and Application Security consultants that blend cutting-edge security research with a practical attacker mindset. In addition to being a pioneer in AI bias bounty hunting, Keith holds both the Offensive Security Certified Professional (OSCP) and Offensive Security Web Assessor (OSWA) certifications.
Identiverse 2025 is returning to Las Vegas, June 3-6. Hear from 250+ expert speakers and connect with 3,000+ identity security professionals across four days of keynotes, breakout sessions, and deep dives into the latest identity security trends. Plus, take part in hands-on workshops and explore the brand-new Non-Human Identity Pavilion. Register now and save 25% with code IDV25-SecurityWeekly at https://www.securityweekly.com/IDV2025
Mike Shema
- Next.js and the corrupt middleware: the authorizing artifact – zhero_web_security
Next.js provides devs with a toolchain to deliver React-based frameworks. Some bug bounty researchers discovered how to bypass its middleware controls by including a x-middleware-subrequest header with some easy-to-determine routes. (There's a wonderful nuance for some versions where it's necessary to repeat the value five times to trigger a recursion depth check.)
The consequence is that if the app relies on the Next.js middleware for authentication or authorization checks, then an attacker can trivially bypass those checks. If the app is enforcing such checks on the server side (not to be confused with rendering server-side React), then the app is fine.
- Harden-Runner detection: tj-actions/changed-files action is compromised
Attackers compromised a project maintainer's GitHub Personal Access Token (PAT), created a malicious commit, used their access to point every release tag to the malicious commit, and watched as all the infected CI/CD pipeline Actions started logging secrets.
It's an example of shifting attack surfaces and another example of trust in supply chains. The commit masqueraded as coming from a Renovate bot, which wouldn't be unfamiliar at a glance from devs or appsec folks. But the commit wasn't signed. I'd hope that requiring signed commits would have prevented this attack outright or at least made the malicious activities more obvious.
As the recommendations section of the article points out, this is another good reason to pin Actions to known-good SHAs. That's something that feels like it's easy to automate and easy to include signature checks for.
- SAML roulette: the hacker always wins
Excellent research from the Portswigger crew as always. I couldn't pass this up because it hits on another favorite topic of mine -- parsers.
There are a few lessons in software engineering choices in this story. A long time ago, GitHub originally relied on the ruby-saml library, but switched to their own implementation in 2014 due to missing features. Their implementation received a slew of bug bounty reports, which led them to reconsider going back to ruby-saml. It's interesting to track the reasons behind choosing open source vs. building your own, forking projects, and improving security in open source.
The other lesson is in the ruby-saml library itself. It had code paths that led to two different XML parsers. One parser handled the manipulation messages and the other handled verification of the messages' signatures. However, the parsers exhibited different parsing behavior and tolerances, which is terrible for security. In this situation, it meant an attacker could insert any known valid signature (which is often easy to obtain) into an arbitrary message of their own and consequently log in as anyone else. The library saw a valid signature, but didn't validate that the signature matched the message.
Related articles:
- Sign in as anyone: Bypassing SAML SSO authentication with parser differentials - The GitHub Blog
- SAMLStorm: Critical Authentication Bypass in xml-crypto and Node.js libraries — WorkOS -- a different vulnerability with similar parsing problems
- A Survey of Parser Differential Anti-Patterns -- different ways parser mismatches manifest flaws
- XML Signatures are a bad idea executed even worse | SSOReady -- it's not just parsing that's the problem
- Leaking Passwords…and more on macOS
This is one of those articles that takes the time to educate the reader with background context on a technical topic. The author gives a very nice overview of the Mach kernel, what makes its message handling between threads stand out, and how those messages are constructed.
Then it shows how a missing message verification step meant an attacker could leak credentials. The good news is that there's an existing secure design, both in access controls on keychain items and sender verification for these kinds of messages. This seems like the kind of bug that should be trivial to lint or have compiler warnings (or errors!) for.
- CVE-2025-24071: NTLM Hash Leak via RAR/ZIP Extraction and .library-ms File
I admit that this mostly caught my eye because the exploit example relied on an XML file. But the more important discussion points are around secure design choices and app behavior.
On one hand you have a feature intended to provide a better UX where "Windows Explorer automatically parses the contents of this file due to its built-in indexing and preview mechanism." It does this "automatically upon extraction to generate previews, thumbnails, or index metadata, even if the file is never explicitly opened or clicked by the user.”
However, that lack of initial user interaction or intent leads to a problem where a malicious file "triggers an implicit NTLM authentication handshake from the victim's system to the attacker-controlled SMB server. Consequently, the victim's NTLMv2 hash is sent without explicit user interaction."
For security and human sanity, it'd be nice to do away with XML altogether. But that wouldn't fix the underlying problem here. This needs some secure design answers to questions like, Should the preview wait until the user interacts with the file, What's a safe vs. unsafe file to preview, What are the security benefits and privacy consequences of proxying requests that a preview might trigger?
- AI coding tools ‘fix’ bugs by adding bugs
- OpenAI Researchers Find That Even the Best AI Is “Unable To Solve the Majority” of Coding Problems
- [FYI] Prepping for post-quantum: a beginner’s guide to lattice cryptography
A very accessible high-level explanation of a new cryptographic foundation for the post-quantum world.
- [FYI] LibAFL | Testing Handbook
Now updated with more guidance on fuzzing.
- [FYI] FLIPPYR.AM
What's the real world impact and exploitability of Rowhammer? Contribute to research that's trying to better understand the implications of this type of attack.
