Ten days between PHP2Shell's discovery and a patch. Attackers had four.
Issue #065 · 4 min read
Ten days between PHP2Shell's discovery and a patch. Attackers had four.
A widely used PHP bug got exploited before defenders even knew it existed. Plus: OpenAI ships a Decisions API, GitLab wires agents into review.
The big story
PHP2Shell is a bug in a programming language that still runs a huge share of the web.
Hackers were probing it before anyone who could fix it knew it existed — that's Ars Technica.
Four days passed between attackers finding the hole and defenders learning about it.
Four days is a long head start. It's enough time to scan the internet for every exposed server, pick the easy targets, and get in before a patch exists.
The exploit also bypasses protections that were specifically built to stop this exact kind of attack, remote code execution.
GitLab moved fast to say it isn't affected — the product isn't written in PHP and doesn't run it to serve requests — and published a guide to help other teams find and fix the flaw.
That's useful, but it's also a tell. When a vendor's first move is a public statement about what it doesn't run, you know the bug is bad enough that customers are already asking.
If your product touches PHP anywhere in the stack — a plugin, a legacy service, a vendor's backend you don't control — this is the week to ask your engineering lead a direct question: are we exposed, and did we know before or after the attackers did.
What shipped
OpenAI launched a Decisions API, built for "fast, focused, low-cost decisions for any application" rather than long conversational replies — see OpenAI's post.
Separately, OpenAI made its Jev-competing decision model widely available, aiming it squarely at a category that already has an incumbent.
This matters if your product makes a lot of small automated calls — routing a ticket, scoring a lead, approving a transaction — where you don't need an essay back, you need a fast yes or no. If you're paying for full chat completions to do that today, it's worth pricing this against what you're running now.
GitLab is rethinking code review for a world where agents write a lot of the code. Its argument: a coding assistant speeds up writing, but says nothing about whether review, security checks, and release approvals can keep up with the extra volume hitting the queue — see GitLab's post.
If your engineering org has let agents loose on pull requests without touching the review process around them, this is the gap they're describing. Worth forwarding to whoever owns your release pipeline.
1Password shipped a way for AI agents to log into your accounts without ever seeing your password, letting an agent act on your behalf while the actual credential stays hidden — reported by TechCrunch.
Agents logging into real accounts is becoming a normal ask from customers. Keeping the password out of the agent's hands is the right default, and it's notable that a password manager, not an AI vendor, is the one shipping it.
What I'd actually do this week
- Ask engineering directly whether any part of your stack runs PHP, and whether PHP2Shell has been checked against it — don't wait for a vendor email to tell you.
- If you're running high-volume, low-complexity model calls in production, price OpenAI's new Decisions API against your current setup. A few cents per call adds up fast at scale.
- If agents are already opening pull requests on your codebase, ask whether review and approval steps were redesigned for that volume, or just inherited from the human-paced process. GitLab's post is a good prompt to send along.
Tell me what's breaking in your review queue — replies go straight to me.