The exploit came first
If you run anything on PHP, this hasn't been a quiet week. On 20 October, details of two critical PHP vulnerabilities leaked ahead of their planned disclosure. Together they're known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), and they allow remote code execution on a PHP server without any authentication. Since PHP sits underneath WordPress, Drupal, Joomla and a very large share of the web, the exposed surface is enormous. What followed was messy. The CVE identifiers leaked on forums, one of the research teams accidentally published a video of its exploit working, and a container vendor shipped patched images six hours before the coordinated release, arguing exploits were already in the wild. The PHP team brought the patches forward anyway. But the part worth reading twice is in the PHP Foundation's own postmortem. A PHP core developer first noticed signs of this memory problem in 2024, during a security audit. At that point exploitation was theoretical and remediation costs were high. The few developers who understand the engine deeply had other priorities, and the Foundation itself now calls the delay a structural failure, down to its decision process and its lack of resources. Then, in August this year, Calif reported a working remote code execution with that exact root cause. OpenAI reported the same thing, independently, the same day. Wiz added more attack vectors. And this week a third company said it found the flaw on its own in a matter of days, using a test harness and a frontier AI model. So here's the shape of it. A flaw sat in the open for two years because there weren't enough people who could fix it. Then, the moment AI made it cheap to look, three separate teams found it almost at once. Weird, right? That's the story of 2026 in one bug.
The numbers behind it
In 2024, around 40,000 CVEs were published. 2025 closed at a record 48,185. FIRST's mid-year forecast now projects somewhere around 66,000 for 2026. Obviously nobody patches 66,000 vulnerabilities a year, and the good news is that nobody has to: according to EPSS data, only about 5% of published CVEs are ever observed being exploited. The real job is figuring out which 5%, and doing it before someone else does it for you. With AI compressing the time between "theoretical flaw" and "working exploit", thatwindow keeps getting shorter.
What this means for hiring
For a long time, vulnerability management has been staffed like a production line: scan, triage, open a ticket, patch, repeat. It was already a stretch at 40,000 CVEs. At 66,000, with exploits arriving faster, it simply doesn't hold. At Hack in Hire we're seeing two profiles become critical in the teams we work with, and they are rarely the same person. The first one isn't new, but it's scarcer than it sounds: the vulnerability manager who prioritises by real exploitability and business context, not by CVSS score. The person who can look at 500 critical findings on a Monday morning and tell you which 10 actually matter this week, and why those and not the others. The second one is new: offensive researchers who work alongside AI. People who take the same kind of models that turned PHP2Shell from theory into a working chain, and point them at their own environment first. They don't wait for the advisory. They go looking for the chain before anyone publishes it. The uncomfortable part? The market still describes the first profile in the language of ten years ago, and barely has a name for the second.
See you at Slush
On 18 and 19 November we'll be in Helsinki for Slush. If you're going and you're building or hiring a security team, come and find us. We'd like to hear what you're struggling to hire for.
Where do you stand?
Upload your CV to create your profile on Hack in Hire. It takes a minute, and it works whether or not you're actively looking. When a role fits your profile, we'll invite you to a technical assessment, so you're matched on what you can actually do, not just on your keywords. Visit hackinhire.com
