Coder Legion - Recent posts tagged php2shell

Developer Weekly Briefing — October 23, 2026

Fri, 23 Oct 2026 12:49:47 +0000

Three threads defined this week. Security researchers — now routinely assisted by AI — found critical bugs faster than maintainers could coordinate patches. Agentic AI standards solidified in meaningful ways, with the Agentic AI Foundation adding four new projects and a candid CTO willing to name the gaps. And on the infrastructure side, the tools for keeping developer pipelines safe from compromised packages got sharper. Here's what mattered.

PHP2Shell: AI turned a theoretical bug into an exploit in days

PHP shipped emergency patches on October 21 for PHP2Shell — two critical flaws, both rated 9.2 under CVSS v4.0, that let an unauthenticated attacker run code on your server. The fixes are in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If you run a supported branch, the path is simple: patch and restart your PHP workers.

The harder story is what's underneath. These flaws trace back to the PHP 5 series — CVE-2026-109618 corrupts memory during out-of-memory errors, CVE-2026-109619 involves stale global state from freed request memory. Security researchers had spotted the vectors more than a year ago but couldn't find a practical way to trigger them. They stayed in the "theoretical" pile. Then two independent researchers, each using a frontier AI model, found working exploits within days of each other this past August. Cloudflare logged attacks hours before patches shipped on October 21.

Matthew Weier O'Phinney, PHP Foundation board member and principal product manager at Perforce OpenLogic and Zend, was direct: "These vulnerabilities affect every single Server API provided by the language, because their roots are deep within how the engine manages memory." That includes PHP-FPM behind Nginx — not just mod_php. Workarounds like disabling session upload progress buy time; they don't fix the underlying problem.

The real exposure is PHP past community support. Every version before 8.2 is EOL, and 8.2 itself ends community support at year's end. If you're on an older version, your options are a commercial LTS provider — several shipped patches for PHP 7.2–8.1 in coordination with the PHP Security team — or a migration to a supported branch. His broader point: AI is accelerating discovery faster than patches reach unsupported software. That gap is a business risk, not just an engineering footnote.

AAIF now has 10 projects — its CTO on what to adopt and where security falls short

The Agentic AI Foundation started December 2025 with three projects. It hit ten this week at AGNTCon + MCPCon North America in San Jose, adding contributions from Anthropic (Agent Skills), OpenAI (Open Responses), Hugging Face (OpenEnv), and Alibaba (OpenSandbox). The foundation passed 300 member organizations.

I asked Manik Surtani, AAIF's CTO and co-founder, what that means for teams building on these standards. His answers were practical.

On what to use now: MCP and A2A are the most mature. Open Responses has reached solid maturity. OpenSandbox is early but worth watching — and you need a sandbox somewhere. "Running without any sandbox is dangerous, and you shouldn't do it." Put a gateway in the middle so you can migrate models and tools later.

On the reference stack question everyone keeps asking: don't expect one. "The more I think about it, the more I believe any reference stack we build today will be out of date tomorrow." Production deployments are the reference.

On the two biggest security gaps in the agentic stack today: agent identity and authentication, and attestation — proof that an agent did what you asked and didn't go sideways. No AAIF project covers either one yet. There are working groups, but no adopted standards. If your agents operate on real systems, those are the areas where your own controls need to be strongest.

GitHub puts a firewall between npm and your CI runners

Install time is where npm attackers have focused all year. Preinstall and postinstall scripts can run before tests or scanners get a look — the compromised Axios release in March, the @redhat-cloud-services attack in June, and a worm that touched more than 400 packages in August all exploited that window. GitHub's answer is a package firewall, now in public preview for Enterprise Cloud customers.

The firewall sits between endpoints — CI runners, AI coding agents, developer workstations — and the upstream npm registry. Five policy controls ship out of the box: blocking known malware from the GitHub Advisory Database, blocking versions with known vulnerabilities above a configurable severity, blocking attestation downgrades (a package that stops shipping provenance after earlier versions carried it), blocking newly introduced install scripts, and a minimum package age cooldown from 1 to 365 days, defaulting to one day.

The cooldown is the simplest and may be the most useful. Most malicious npm versions are pulled within hours of discovery. A one-day hold would have stopped the compromised Axios versions, which were live for about three hours. The attestation check has a known gap: it won't catch a hijacked pipeline that signs malicious code honestly, as happened in the AsyncAPI attack in July.

Mitch Ashley of The Futurum Group noted the core constraint: "The firewall only protects traffic routed through it, so teams should block direct access to the public registry at the network layer." Watch the metered pricing at general availability too — a usage-based bill gives teams a reason to route less through the firewall.

For Enterprise Cloud customers, the free preview is worth running. Find out what a one-day cooldown would actually catch in your environment before you have to find out the hard way.

Anthropic used Claude to formally verify 123 open source libraries — and found bugs fuzzing had missed

Formal verification has always been expensive. Two person-years to build the seL4 microkernel. Twenty person-years to verify it. That math is why it has mostly lived in avionics and cryptography. Anthropic's Frontier Red Team, working with formal methods company Theorem, ran the largest AI-assisted formal verification effort yet: 123 open source libraries from Google's OSS-Fuzz project, 239 fuzzing entry points, proofs operating on RISC-V assembly, not source code.

The approach was clever. Instead of writing new specs from scratch — historically the hardest part — the team converted existing fuzz tests into formal specs. Each fuzz entry point became a proof statement: this program never crashes on any input under 64 MB. Theorem supplied formal models of RISC-V and Linux process behavior. Claude wrote the proofs. The Rocq proof checker validated them.

Over a few weeks, Claude produced about 180 million lines of Rocq proof. Typical proofs ran around 600,000 lines for a binary with a median of 18,000 instructions. Claude was allowed to patch bugs it hit and keep going, and it found hundreds. Several are notable: a counter underflow in a decompressor that only triggered on inputs around 20 MB with one specific layout; an out-of-bounds read in an image decoder needing a 64 MB input and more than 2 GB of memory; a logic bug in file-loading restrictions that wasn't always enforced. None of these would have surfaced from typical fuzzing, which usually caps inputs at 1 MB.

Cost is real — proofs can consume hundreds of millions of tokens — but Anthropic points to two trends: Claude Opus 5.5 used 40% fewer tokens than Opus 5 on 36 small verification tasks, and agents sharing a workspace and reusing proofs needed 17% fewer tokens. The reuse point matters more than token savings. Much of any proof covers code every C program shares, so proofs transfer well. Verify a small set of widely used libraries once, and much of the stack downstream gets easier.

Anthropic has released a subset of proofs and the RISC-V and OS semantics on GitHub. Theorem is offering to run the pipeline for other open source projects and has published a Claude skill for teams that want to start. The near-term takeaway for DevOps teams: don't drop fuzzing. Do start watching whether formal verification moves into your pipeline the way fuzzing did — Anthropic predicts it will become roughly as practical as fuzzing is today.

GitHub adds AI-powered security scanning to pull requests. GitHub's new code scanning feature runs directly on PRs, flagging security issues before merge rather than after. It uses AI to surface findings in context with the diff. Worth watching if your team uses GitHub Enterprise. Read more
AI agents can now decompile software — here's what that means for security. Researchers demonstrated that frontier AI models can decompile binaries and reconstruct meaningful source-level understanding of proprietary software. The implications run in both directions: useful for security audits, dangerous in the wrong hands. Read more
HiddenLayer puts a security layer between external LLMs and your internal systems. LLM gateway hijacking — where an attacker manipulates prompts to redirect agent calls to a malicious model — is an emerging attack class. HiddenLayer's approach sits in the request path between your application and external model APIs, inspecting and filtering what goes through. Read more
CyberCartel used Claude and Grok to automate banking attacks. A threat actor group documented using frontier AI models to automate credential-harvesting campaigns targeting banking customers. The research maps how they used AI to generate phishing lures, adapt to defenses, and scale operations that would previously have required more manual effort. Read more
Microsoft Foundry agents can now run on a schedule. Scheduled execution is a basic building block for autonomous agents — run a report, check a system, trigger a workflow at a set time without a human in the loop. Microsoft Foundry now supports it natively. Read more
Google launches Harness² for AI agent testing. Google's new testing framework is designed for multi-step agent workflows, where individual unit tests don't capture enough of the failure surface. It's aimed at teams building production agents who need confidence that the full chain — not just each step — behaves as expected. Read more
OpenAI lands a COBOL modernization deal with a Fortune 500 bank. Enterprise AI is starting to move into legacy modernization, one of the largest untapped engineering markets. OpenAI will use its models to translate COBOL systems for a major bank — a deal that signals how AI-assisted migration may finally make the COBOL mountain climbable. Read more
Mod42 is building data centers for organizations that can't afford hyperscale. The hyperscale economics of AI infrastructure don't reach everyone. Mod42's approach targets mid-market enterprise and public-sector workloads that need dedicated capacity without signing a hyperscaler contract. Read more

Developer Spotlight this week

Dean Hall is best known for creating DayZ, one of the most influential survival games of the past decade. He's back with a new project, Brutal, and he rebuilt his game engine from scratch to make it. The conversation covers what drove that decision, where AI fits in his development process, and where it doesn't. His take on what AI still can't do is worth hearing from someone who has shipped at scale.

Watch the conversation

The through-line this week: AI is accelerating both sides of the security equation. PHP2Shell shows how quickly a theoretical bug becomes a working exploit once researchers have capable models to help. The CyberCartel and HiddenLayer stories show the same dynamic at the application layer. And Anthropic's formal verification work shows that AI can also scale up the defenses — producing more proof and catching more bugs than human teams could afford to write by hand. The tools are neutral. The race is real.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

PHP2Shell: Two 9.2-Rated Flaws Reach Back to PHP 5. Here's the Plan for EOL Teams

Thu, 22 Oct 2026 13:00:00 +0000

PHP shipped emergency patches on October 21 for two critical flaws now known as PHP2Shell. Both are rated 9.2 under CVSS v4.0. Both can let an unauthenticated attacker run code on your server.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run a supported branch, update and restart your PHP workers. That part is simple.

The harder question is what to do if you run a version that no longer gets community patches. A lot of teams are in that spot.

I asked Matthew Weier O'Phinney about it. He's principal product manager for Perforce OpenLogic and Zend, and he sits on the PHP Foundation board. Perforce sells extended support for end-of-life (EOL) open source software, so keep that in mind when he talks about extended support. But he also had a close view of how this disclosure played out.

What the flaws do

CVE-2026-109618 corrupts memory when PHP hits an out-of-memory error in the middle of a request. CVE-2026-109619 involves stale global state. PHP keeps pointers to request data after that memory has been freed.

Weier O'Phinney put it in plain terms. "An attacker can create one or more payloads that simulate large file uploads, or multi-file uploads, that hit configured memory limits for the PHP application," he said. Because of how PHP handled memory and errors at that moment, the attacker could end up running system commands on the server.

The attack doesn't need a vulnerable application or a public upload form. And the timeline was tight. Details leaked on October 20, a day before the coordinated release. Security firm Sansec reports that Cloudflare saw attacks hours before the patches shipped.

It's not just mod_php

PHP's advisory named Apache's mod_php as the highest-risk configuration. Some early coverage stopped there. Weier O'Phinney says that's too narrow.

"These vulnerabilities affect every single Server API (SAPI) provided by the language, because their roots are deep within how the engine manages memory and handles errors," he said. "If you run PHP, your application is affected, plain and simple."

mod_php may be the easiest path in. But PHP has also confirmed remote code execution against PHP-FPM under the right application conditions. If you run FPM behind Nginx, you're not off the hook.

Workarounds buy time. They don't fix the problem.

The early advice was to turn off session upload progress and remove memory limits. Weier O'Phinney says those steps help, but only so much. "They just change the size of the file upload payloads the attacker needs to use to exploit the system," he said.

He's more positive about two other measures:

A web application firewall (WAF) that limits which paths accept uploads, or any user submission
AppArmor or SELinux to restrict PHP's access to system binaries

Both are good defense-in-depth. But he warns that creative attackers can still find ways around them if the PHP runtime underneath is vulnerable.

PHP says the same thing. Updating is the only complete fix. If you removed the memory limit as a stopgap, put a container or cgroup limit in place, and restore a finite limit once you've patched.

The end-of-life problem

Here's where it gets uncomfortable. According to Weier O'Phinney, every PHP version before 8.2 is past community support. And 8.2 reaches end of life at the end of this year.

These flaws trace back to the PHP 5 series. "If you're running PHP 5, PHP 7, or early PHP 8 versions, you will need to audit your applications and deployments," he said.

He sees two paths:

Use a commercial long-term support (LTS) provider. Several have patched EOL versions. Perforce Zend patched PHP 7.2, 7.3, 7.4 and 8.1 in coordination with the PHP Security team. If you already have a provider, confirm it shipped patches for your version.
Start migrating to a community-supported version. That means 8.2 or later. Since 8.2 is nearly at end of life itself, a migration that stops there only buys you a couple of months.

If you have neither, his advice is to pick one today.

AI changed the clock

The backstory matters here. A security audit sponsored by the Sovereign Tech Agency and the PHP Foundation found these attack vectors last year. But the security team couldn't find a practical way to trigger them. They treated the flaws as largely theoretical and kept working on them off and on.

Then, this past August, two independent researchers found the same issues within days of each other. Each was using a frontier AI model. Each built a way to exploit them. The PHP Security team had to move them to the top of the list.

That's the real shift. A bug that sat in the "theoretical" pile for a year became practical in a matter of days.

Weier O'Phinney sees the same pattern across open source. The cURL project has been handling a flood of AI-discovered reports for two years. Spring has seen a big jump in reports this year. And those reports still need people to review them. Maintainers have to confirm that each patch works, doesn't break existing behavior and doesn't add new flaws. Many AI-generated reports also overstate severity, which takes more time to sort out.

For EOL software, this is the core risk. Discovery is speeding up. Patches for unsupported versions aren't.

Migration or extended support?

Weier O'Phinney is clear that migration is the goal. Current versions get new features and security fixes first, and the rest of the ecosystem tends to follow the latest releases.

But he's also realistic. Continuous upgrades take discipline, solid testing and QA, and a DevOps team that can roll releases out and roll them back. Some companies also face regulatory reviews every time they move to a new feature release. That costs time and money, so migration gets pushed back.

"So adopt those new versions if you can, but have a plan for when you cannot," he said.

That's fair advice, and it's worth taking at face value. Extended support is a bridge, not a destination. If you're evaluating a provider, ask one simple question: how fast did it ship PHP2Shell patches for your version? The answer tells you a lot.

How the disclosure worked

Weier O'Phinney knew for a couple of months that big security patches were coming. He didn't know the details. "That's a good thing," he said. Fewer people in the loop means less chance of a leak.

The PHP Foundation now employs a small team that coordinates security work between researchers and the PHP project. One of them contacted Weier O'Phinney in his role at a commercial LTS provider to line up releases. In more than 20 years at Zend, that was a first for him. The PHP Security team worked with Zend's packaging team and reviewed its patches so both were ready on release day.

His bigger concern is capacity. The PHP Security team is small, and the volume of incoming reports keeps growing. He'd like to see it staffed well enough to coordinate like this more often. His ask: if your company depends on PHP, consider donating to the PHP Foundation.

What to do this week

Find every PHP runtime you have. Check servers, containers, base images and hosting accounts. Trust php -v, not your documentation.
Patch supported branches now. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart PHP workers so the new code is actually running.
Check EOL versions separately. If you use an LTS provider, confirm it has shipped fixes. If you don't, choose between getting one and starting a migration.
Treat workarounds as temporary. Undo emergency config changes once you've patched.
Keep the extra layers. A WAF and AppArmor or SELinux are worth having after the patch, too.
Plan for more of this. AI-assisted discovery isn't slowing down. Budget time for triage and upgrades, not just for incidents.

PHP2Shell will get patched on most supported systems this week. The teams still exposed next month will be the ones running PHP that nobody owns. Now is a good time to find out if that's you.