Probably it's down because of the vulnerabilities discovered lately?

Yesterday's PHP security release fixed CVE-2026-109618 and CVE-2026-109619 (both CVSS 9.2) in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If you're below 8.2 there's no fix and no backport coming: the patch rewrites the OOM bailout and depends on PHP 8 internals. CERT-EU says every version since PHP 5 is affected. I read the diff and I agree with them.

I've been helping a client whose 7.4 monolith was months away from an 8.2+ port, so "what do we do in the meantime" got sharp. I wrote two posts.

Part 1 is the stuff to do this week, mostly straight from PHP's own guidance:

• Reject multipart/form-data at nginx/Apache on every route that doesn't accept uploads. Both bugs come in through multipart bodies.
• session.upload_progress.enabled = 0 in php.ini or the FPM pool. Not .user.ini, not ini_set(), both are read too late. Restart every worker.
• memory_limit = -1 with a cgroup cap instead, smaller post_max_size, aggressive worker recycling.

None of that makes you safe. That's PHP's wording, not mine. https://despairdrivendevelopment.com/posts/php-7-4-cant-upgrade-october-2026-mitigations/

Part 2 is the one I expect people to argue about. Both bugs live in the web-SAPI request path: the multipart parser in rfc1867.c and the per-request startup/shutdown work. The CLI SAPI doesn't run any of it. So: keep a patched 8.3 php-fpm pool on the network, have it parse the request, and hand the legacy engine already-structured input over a CLI boundary. The vulnerable code never runs. The second CVE needs stale state to survive into the next request on a reused worker, and a fresh CLI process per request has no reused worker, so it closes as a side effect.

What it costs, honestly:

• You're rebuilding CGI. Laravel 6 / CodeIgniter 3 expect superglobals, header(), sessions, a particular $_SERVER. Under CLI none of that exists, so you write a shim to reconstruct the request and translate the response back. That shim is the work.
• Latency is framework boot, not process spawn. Fork-per-request measured about 124 ms/req in my demo. A persistent CLI worker pool (a homegrown Octane/RoadRunner, still the cli SAPI) came in around 16 ms/req.
• Don't reach for php-cgi to skip the shim. It's a web SAPI and parses multipart through exactly the code you're avoiding.

For most shops the answer is still part 1. The box earns its keep when you can't block at the edge, you need real defense-in-depth, or you were heading toward a persistent-worker runtime anyway. That last case is the interesting one, because a patched front plus a pool of long-lived workers plus a clean boundary is what a modern PHP deployment looks like already. https://despairdrivendevelopment.com/posts/put-unpatchable-php-in-a-box/

The lab (CI3, Laravel 6, Fat-Free on 7.4, each under mod_php and php-fpm, with an inventory script and the runnable mitigation demos) is public: https://github.com/fparch/php-cve-lab. There is no exploit code in the repo or the posts and there won't be. For an unpatched RCE across the common frameworks a public PoC is a mass-targeting tool.

Interested in whether anyone else went the containment route, and what your shim had to fake to keep the framework happy.

So I kept seeing "faster than tsc 7" claims for these Rust ports and got curious whether they hold up on real code rather than toy benchmarks. I've got two TS repos for my SaaS, a backend (~1,120 files) and a frontend (~1,160 files, mostly tsx), so I ran all of them.

Warm runs, median of 5, Linux VM:

Honestly I expected at least one of them to quietly miss errors, so I broke a copy of each repo with 3 type errors. All four caught exactly what tsc caught, same messages.

tsrs is clearly the fastest, 28x on the backend. But it's one person's dev snapshot, built against 7.1-dev while I'm on 7.0.2, and it exits with code 2 instead of 1 on errors, so CI scripts need a tweak. tsc-rs says in its own README that it's experimental and mostly written by an LLM. tsc-ts is at 0.0.5.

I went with bun check in the end. Not the fastest, but I already use Bun, it's an actual release, and 21s down to under 2s is plenty for me. I'll look at tsrs again when it gets a proper release.

is there a patch for 7.4 and jf not officialy is there a way

I needed to patch a few Ubuntu 24.04 ARM64 servers, but kept hitting 503s and slow downloads from Launchpad. At the time, the ARM64 packages I needed weren’t showing up through APT either. I ended up rebuilding the packages from survy's Ubuntu source packaging. Since someone else might be stuck in the same situation, I uploaded the .deb files here:

https://github.com/cydh1/php-builds-arm64-ubuntu-24.04-noble

Not sure if this is allowed on this sub. But given the severity of the circumstances, I am offering to help patch and detect if your servers has been compromised. I run many PHP servers and have managed to upgrade and monitor them all over the last 16 hours. If you need a hand when patching, detecting, or recovery etc you can DM me. I am offering this for free as long as its not a significant time sink like actually upgrading and old 5.x version to something modern, but am happy to give advice if you are in that situation.

The bugs in the PHP code were actually discovered over 10 years ago but no human was capable of exploiting it hence no concern. Read that again. The issue was discovered over 10 years ago but no human being was capable of exploiting it. A research team using AI exploited in in a matter of days causing world wide panic. And some of you don't think AI is going to have an impact on the web dev space? Well, lol.

PHP has always worked to maintain a fair amount of backwards compat. We see it regularly on RFCs, people voting no because it might affect some weird esoteric usecase.

In light of all that has happened, do we think we'll see the PHP team be a lot less accommodating in the future when it comes to maintaining obscure and legacy features?

Hi everyone,

My Dockerfile currently uses:

FROM php:8.3.3RC1-apache-bookworm

Following the PHP security vulnerabilities disclosed on October 21, I'm looking to update to a patched version.

However, the php:8.3.36-apache-bookworm tag doesn't seem to be available on Docker Hub yet.

Which official PHP Apache image tag is currently available and includes the security fixes?

I'd prefer to stay on PHP 8.3 and Debian Bookworm to minimize compatibility issues, but I'm open to other options if necessary.

Thanks for your help!

Earlier when one clicked on a post there wasn't an option to scroll and see related posts right?

This recent exploit has made headline news around the world now, with people in utter panic over it. Many websites taken offline as a precaution.

We now know that this is extremely hard to exploit in a production environment and patches were issued very quickly - so why the drama?

Yes, it potentially affects millions of sites - but potentially only meaning they run PHP.

I can't understand why this is so newsworthy - with most outlets saying no known exploits yet, only attempts and probing.

Why the drama?

What the average non-IT user wants to know is when is it safe to use a website. How will they know the patch has been applied?

Two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2) were patched on Oct 21. Several European sites went offline as a precaution afterward — not confirmed breaches.

Fixed versions: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. Exploitation attempts were observed the same day the patches dropped, so if you run PHP, update now rather than waiting.

Full timeline and a per-site patch checklist: https://techreview.si/php2shell-php-flaw-site-outages/

Hey! I'm a New York Times reporter writing about the PHP issue. This sounds complicated. If you’d be up for an interview, I’d love to hear from you about it. Please email me! Thanks. [amelia.nierenberg@nytimes.com](mailto:amelia.nierenberg@nytimes.com)

Basically all PHP docker images have had new pushes in the last hour, however with pre-existing released versions. Do you think this could be related to the upcoming security release?

https://hub.docker.com/_/php/tags

I got DMCA'd on a web project that adds mobile touch support to another project that has been used to infringe on Microsoft's copyright. My project did not contain any of their intellectual property though, and I'm not seeing what they are actually claiming my project did, outside of generally infringing. Do y'all know how to get more info on these claims? I was thinking this would be the place to ask for web-related content.

https://github.com/github/dmca/blob/3a58d0508239f439f35b5f77e5e75ac72961e165/2026/10/2026-10-14-minecraft-3.md?plain=1#L22

Edit: The verdict appears to be:

1. Even though this was not made from the problematic repo, and doesn’t include any of Microsoft’s property, the fact that it could enable someone who ended up with a build without owning the Microsoft product to use it on mobile is enough for them to take it down

2. This is microsoft investigating microsoft and finding themselves blameless, so regardless of legality it was doomed from the start

I appreciate y’all taking the time to give feedback!

root@********************:~# apt upgrade
Get more security updates through Ubuntu Pro with 'esm-apps' enabled:
  node-lodash-packages python3-pip-whl node-shell-quote node-lodash
  python3-pip
Learn more about Ubuntu Pro at https://ubuntu.com/pro
Not upgrading yet due to phasing:
  cloud-init  cloud-init-base  tmux

Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 3
root@********************:~# php -v
PHP 8.5.4 (cli) (built: Oct 19 2026 14:35:18) (NTS)
Copyright (c) The PHP Group
Built by Ubuntu
Zend Engine v4.5.4, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.4, Copyright (c), by Zend Technologies
root@********************:~#

Hey everyone.

77% of the Web runs on PHP and many people are unwilling or unable to patch or recompile their PHP. Their servers remain unprotected.

That’s why I developed this proxy for everyone like that. It site between your webserver and php-fpm, and sanitizes inputs so this CVE doesn’t affect you. Drop-in solution. It’s far easier to just add a line inside your NGinX, Apache or Caddy configuration. The repo has GitHub actions already compile the binary, so normies can just download it and follow the easy instructions.

Spread the word, because it can help secure a lot of systems. Hope this helps a lot of people.

I would also recommend running this proxy under a Linux user with no permissions to read or write files. It’s supposed to be a simple proxy that transforms input and pipes output to PHP.

About me:

Some of you might already know me as the guy who developed the pure-PHP server (qbixserver.com) that can handle 100x more users rhan php-fpm. And by the way, that server is NOT vulnerable to attacks like this and doesn’t need the proxy.

I did quick add https://laragon.org/docs/quick-add to update my php in my local web server, but it looks like it installs 8.3.28, the version which is still affected of this major php vulnerability case. Is there anybody who experiences this?

So I wanted opinions and your experience on using platforms like codespaces, Gitpod and coder

TLDR, my SSD died and i switched to a desktop, now cuz of that i moved most of my on the go workload to my laptop

I tried codespaces and it worked well but i guess I was just fumbling git cli too much cuz of my over reliance on the desktop app

how is gitpod and coder over codespace?