# mitbbs.ai php2shell Patch Case Study

By PHP Patch Assurance · Last updated: 2026-10-25

On October 21, 2026, the bilingual news portal mitbbs.ai ran the highest-risk php2shell configuration: PHP 8.3.35 under Apache mod_php. That evening it was patched to 8.3.36 with about 10 seconds of downtime, verified live across its key pages, with no signs of compromise in the pre-patch logs. It became the reference case for the patch service built that same night.

## The starting point

mitbbs.ai — a New York-based bilingual news portal and forum — ran PHP 8.3.35 under Apache mod_php, the highest-risk arrangement for php2shell: PHP inside the web server's own processes. Before patching, the pre-patch logs were checked for compromise signs: no segfaults, no out-of-memory fatals, no www-data shell children. Nothing found.

## The patch

The Dockerfile was pinned to `php:8.3.36-apache` and the new image was built while the old container kept serving. The swap took about 10 seconds, and the site answered 200 again about 4 seconds after the new container started. The same pin, build, verify and swap path later became the product's Docker patch flow.

## Verification

After the swap: PHP 8.3.36 running, mod_php loaded, and the home page, the English edition, mail and the health endpoint all returning 200, with webmail reaching the mail server. Verification is not a courtesy step — it is what turns a patch into a finished job.

## The work report

A five-page work report was delivered the same evening: the CVE mechanisms, the server inventory, the compromise assessment, step-by-step remediation with times, the post-patch verification table, the downtime, and the follow-ups. Every patch the service does now ends with a report in that same shape, because protection you cannot verify is not protection.

## What it proved

- Speed with a gate, not speed instead of one: the backup gate and the rollback came before the patch button.
- Proof before product: the site was patched and verified before a single line of product code was sold.
- Honest verdicts: a scanner that says INDETERMINATE when it cannot see the version protects more than one that guesses.

## From patch to product in one night

At about 23:08 the same evening, the site's owner commissioned a product from the evening's playbook: detect, one-click patch, verify, work report. Version 1.0 was committed at 23:30, and phpatch.com went live at 00:35 — 15 hours and 5 minutes after the php2shell disclosure at 09:30.

## Frequently asked questions

### Was mitbbs.ai compromised?

No signs of compromise were found in the pre-patch logs: no segfaults, no out-of-memory fatals, no www-data shell children. The check happened before the patch, not after.

### Why was mod_php the highest risk?

Because PHP runs inside Apache's own processes, with no process boundary between the web server and PHP. See the <a href='/guides/mod-php-vs-php-fpm'>SAPI guide</a> for the full comparison.

### Is the same patch available to me?

For Docker hosts, yes: the <a href='/patch'>patch service</a> follows this same path — snapshot and restore-test first, patch, live verification, work report — for $49, or $99 with rollback.