On 21 October, PHP disclosed two critical flaws, nicknamed PHP2Shell, that could let an attacker take over a web server running PHP. Paperform runs on PHP, so this one was ours to deal with. We had protections in place hours before the fix was published, started rolling out the patch 12 minutes after PHP released it, and didn't need any downtime. We've found no evidence that anyone exploited these flaws against Paperform.
What happened
Two memory-safety bugs in PHP itself let someone run their own code on a server just by sending it a carefully crafted request. Wiz Research found them and reported them to PHP in August, and PHP fixed them in a coordinated release on 21 October (PHP's advisory).
Because the bugs sit in PHP rather than in any one application, almost every PHP website was exposed, and there was nothing application code could do about it. The attack lands before the application even starts handling the request.
The hard part was timing. Details that the bugs existed (but not what they were) leaked online the day before the fix was due. So for about a day, the internet knew a serious PHP flaw existed, partial details and working demos were doing the rounds, and there was no patch available.
Before the fix
We didn't wait for the patch. As details came out, we started closing off the parts of PHP the attacks were rumoured to go through, beginning with the ones Paperform doesn't use at all.
| When (UTC) | What we did |
|---|---|
| 21 Oct, 02:48 | Switched off upload progress tracking, a little-used PHP feature the early reports pointed to. Paperform has never used it, so nothing changed for customers. |
| 21 Oct, 09:44 | Added a firewall rule in every region that turns away file-upload-format requests before they reach PHP. Every attack described publicly relied on that request format, and Paperform doesn't need it: file uploads go straight to secure storage, and our API only accepts JSON. |
We also prepared an emergency switch ready to take Paperform offline within a minute, in case PHP's advisory revealed an attack route we were not already prepared to block.
Patching
PHP published the fix at 13:34 UTC on 21 October (12:34am on 22 October in Sydney). Our patch release was underway 12 minutes later.
We were watching several independent sources for the release, because php.net was buckling under every PHP developer on the planet hitting refresh at once. When it landed, we read the advisory before doing anything else. Both attack routes PHP had confirmed for setups like ours were already blocked by the measures above, so we were able to keep Paperform online.
Updated server images usually follow a PHP release by a few hours. We didn't want to wait that long, so the team built the patched PHP 8.4.27 ourselves from PHP's official source and kicked off an emergency release at 13:46 UTC. It rolled out across our US, EU and Australian regions over the following 30 minutes, with no downtime.
What we saw
We've found no sign that anyone exploited these flaws against Paperform.
The requests the new firewall rule turned away in its first few hours came almost entirely from automated scanners sweeping the internet for older, unrelated weaknesses in other software. None came from customers or their integrations.
Until the patch was live everywhere, we also watched our servers for the side effects these attacks tend to leave behind: PHP processes crashing, unusual memory errors and bursts of failed requests. We saw none, and our logs from before the protections went in show the same.
What you need to do
Nothing. Your forms, submissions, payments and integrations kept working safely the whole time, and there's nothing to update on your end.
One small change if you call our API directly: it now turns away requests sent in file-upload (multipart/form-data) format. Our API has only ever been documented as JSON, and we haven't seen anyone affected. If you do hit a 415 error, send the same request as JSON, or email support@paperform.co and we'll sort it out.
What we're keeping
The emergency measures are staying, patch or no patch. PHP's own advisory recommends both: keep upload progress tracking off, and block file-upload-format requests at the edge if you don't need them. People will keep probing these rarely used corners of PHP, and for us the cheapest bug to defend against is one sitting in code we never run.
Thanks to Wiz Research for finding and responsibly reporting these flaws, and to the PHP security team for shipping a fast, well-documented fix under pretty difficult circumstances.
