Fuzzy Friends and “Black October”

A lot of people are just starting to pay attention to cybersecurity, and that is a wonderful thing, but we should be honest about what is new versus what is only now being discovered by those who have just started paying attention.

I took a biology class in high school where we had a module on germs. The teacher gave everyone a cotton swab and petri dish to hunt down and swab 1 disgusting place and 1 clean place. After a weekend, we returned amazed that every petri dish had fuzzy little friends growing, even the ones from the “clean” places.

I keep thinking about those petri dishes when I hear people talk about “Black October”, a term being used to describe all the vulnerabilities reported this month (October 2026). For the first time, a lot of people outside of security are seeing what happens when you look closely at software. Finding germs on a surface is easy when you have a swab and a petri dish, but figuring out if they can make you sick is quite hard. The same goes for software. AI can help find a lot of bugs, but finding a bug is not the same as:

• Understanding the conditions required to exploit it
• Showing which real systems meet those conditions.
• Demonstrating that it can be exploited in those systems.
• Showing that other defenses don’t stop the attack.
• Demonstrating that the attack gives someone access or capabilities they didn’t already have.

Last week when the whole world started trying to get a reliable exploit for php2shell, it was fascinating to see the number of very smart people claim they had a working exploit, only to find out that their exploit relied on a vulnerable lab setup. If you don’t have a background in this type of work, it is very easy to overlook this and make grandiose and incorrect claims about security.

There is another reason the focus on newly discovered bugs feels wrong to me. Finding a vulnerability in code is only one way to break into a company. This is surprising to people, but in my own red team work I rarely need to rely on vulnerabilities. More often than not, I’m using features that work exactly as designed. Phishing doesn’t require a zero-day vulnerability in email infrastructure, email is supposed to deliver messages. A malicious software package doesn’t require a zero-day vulnerability, the package manager is supposed to install software.

This is not new or novel in any way. The security industry knows this. We even have a fancy lexicon for classifying attack techniques (which I have contributed to) called MITRE ATT&CK. The majority of those techniques don’t require a software vulnerability.

The hard part of offensive security has always been showing that an attacker can exploit a bug against a real system, get past the defenses in place, and gain information or a capability they couldn’t otherwise. Without doing that work or understanding the processes in place for properly finding, validating, and disclosing issues, it’s easy to mistake an interesting bug for a fully exploitable vulnerability. When that claim is made publicly, it spreads very fast. News organizations request for comment, Incident response teams are paged, maintainers have to respond, and offensive security teams start digging. If that claim turns out to be overblown or incorrect, you’ve wasted a massive amount of resources and rebuilding that trust will be difficult.