More Vulns and More Guesswork from Less Data – Jeremiah Grossman – ASW #407
Following the catalog of CVEs is great for enumeration, but chasing those CVEs for patching is terrible for strategy. Jeremiah Grossman shows what breach data tells us about the differences between having over 400,000 CVEs, a few thousand KEVs, and a few hundred ways that attackers compromise orgs. We go into the importance of distinguishing vulns from exploits and where we see agents making a meaningful impact. Then we touch on some history of appsec and why the trajectory of vulns like SQL injection and XSS, along with well-known security controls, point to a more secure future -- or even possibly a pretty secure present.
Resources
Jeremiah Grossman is CEO of Root Evidence and a pioneering cybersecurity leader with over 25 years of industry impact. He was one of Yahoo’s first security officers and went on to found WhiteHat Security and Bit Discovery, acquired in just three years. He now invests in cybersecurity startups through Grossman Ventures and continues to shape modern web application security and attack surface management.
Cloud security isn't a cloud problem. It's a software architecture problem.
Your applications are stitched together with APIs, containers, third-party services, and ephemeral infrastructure. One bad IAM policy, exposed secret, or overly permissive service account can undo months of secure coding.
If you're building cloud-native applications, join us for the Cloud Security Virtual Summit on December 2nd and hear how engineering and AppSec teams are reducing cloud risk without slowing development.
Security Weekly listeners can register for free at https://securityweekly.com/cloudsec using the discount code CSS26-SW!
Mike Shema
- PHP2Shell
(Also posted in last week's episode, but we didn't get a chance to talk about it in depth.)
The underlying memory flaw was discovered two years, but its urgency was diminished by uncertain exploitability. Then a few months ago researchers rediscovered and reinvestigated the flaw. Where the original flaw was accepted as a known problem in how PHP managed memory when it encountered allocation failures (such as hitting out of memory limits), this new research hinted at how those situations could be exploited.
Fast forward to October when PHP made announcements to prepare for an impending critical security patch. However, the embargo was broken early, which led to even more scrambling from admins to react before patches were available.
Then the patch landed, coming in at 423 files changed with about 11,500 lines of code added and about 1,000 removed. On one hand, more than half of that code was occupied by new test files to exercise memory allocation code paths and memory management failure modes. But that still left about 5,400 lines of new code that mostly replaced memory allocation functions with equivalent ones that accounted for being fallible when memory couldn't be allocated and allocation flows had to be unwound.
And, yes, there's an LLM element to this story, where researchers relied on agents to assist with developing successful exploits. But post-patch release, there's also been a proliferation of agent-assisted POCs that are long on concept and short on proof.
Ultimately, this feels like a very human story of developers considering how to improve software quality (improve correctness of memory management and exceptions), how to prioritize work (does a memory safety flaw become a security flaw only once it's exploitable), and how to manage large open source projects (what versions get patched and what compatibility issues can a patch introduce).
The main site noted above has links to the PHP Foundation's announcement and several other technical blogs from the security researchers who discovered the flaw. There's a lot of good technical background to dig into there.
- GitLab security incident: attempted exploitation of CVE-2026-97229 | Alpine Linux
It's just as important to talk about why attacks fail and how they get disrupted as it is to talk about how breaches occur.
- Dual-Header Inconsistencies (Zip Cloaking)
Short, simple vuln that's a wonderful example of inconsistent parsing, aka parser differential, that serves as a reminder that memory safety is just one important security property among many.
- The Rise of Agentic Attacks: What They Look Like, and Where They’re Headed | Wiz Blog
I appreciate how this article skips superficial analysis and avoids embracing cliches. It points out properties of traffic and behaviors that are more common to agent-based attacks. For example, distinguishing a wide variance of probes from an agent vs. a more typical sequential brute forcing from non-agent scanners. The point being that both scenarios might operate at a "machine pace", but they look different in execution. That difference doesn't imply agents will be more successful, but it does help clarify what agents do that looks different. After all, a bunch of noisy probes from an agent are likely to be no less stealthy than an old-school scanner, which points to a useful defense of observability and monitoring.
