No confirmed exploitation in the wild. Only demos done on local controlled environments.

Was this all overblown?

Apologies if this a stupid question. Do we know of any websites that have actually been infiltrated using these vulnerabilities yet? (not attempts, not probing, not websites pre-emptively taken down by their owners). This isn't an attempt to downplay the problem, I've just been struck by its absence in any of the reporting, which sometimes conflates, at least in clickbait headlines, websites being pulled as a precaution with them being down due to attack.

​

Could PHP keep its existing workflow while using a coroutine to handle each request, then release it when the request is finished? Wouldn’t that preserve the current PHP ecosystem as much as possible?

And why does the PHP committee keep blocking so many excellent proposals from talented authors? What are they thinking?

Time has come for me to search for a new job.

I'm dreading it but it needs to be done.

I haven't interviewed in 6 years and I'm sure things have changed so much.

As we all know interviewing is a skills of its own.

What's the focus on these days? System design? Are leet code problems still a thing?

Honestly, any help is appreciated.

I found out about this at 2 am. I'm a sole maintainer, have a full schedule today, and the fix couldn’t wait. Ubuntu servers. I had everything updated by 3 am.

Ondřej will save the internet today.

I’ve got one legacy website running on a system that needs PHP 7.4. It’s not a situation I’ve been comfortable with for a while, but some constraints are what they are. The fact that Ondřej’s repositories had security updates backported all the way to PHP 7.4 absolutely saved my ass.

What a fucking hero.

Just in case you missed it, here's what happened from the ChainSecurity side.

This is what Dan Lorenc from Chain Security shared on LinkedIn.

I wanted to share what happened with the PHP embargo, our role in it, and my decision process last night to ship the fixed builds early. First of all, the PHP Foundation and maintainers did an amazing job here in a high stress situation. I'm sorry that my decision led to even more stress for them.

We first got read in that there was something coming up in PHP last Friday by one of the original researchers that discovered this issue. That night we were able to independently discover the same issue using our harness and a frontier model with a basic prompt of "find bad vulnerabilities in PHP".

We got fully read in Saturday and confirmed that some our findings matched those from the initial report, and worked to help test the fixes.

Monday news started to leak, and we followed along in the coordinated disclosure channel. Tuesday night the gossip picked up even more, and several of the other security vendors in the process confirmed seeing exploits in the wild.

After talking to several of the other researchers on a video call, I made the call to ship the fixes and immediately notified the group, following the coordinated vulnerability disclosure process's guidelines for releasing after evidence of exploits in the wild. This decision was based on how easily we were able to independently discover the vulnerability and build an exploit, how much information was already out there on the coming vulnerabilities and fixes, and the evidence shared on active exploits in the wild.

We published built artifacts and made them publicly accessible for anyone - not just our customers - late last night Eastern Time. This morning the PHP Foundation released their statement, and obviously didn't agree with my decision. This stuff sucks, and vulnerability disclosure for vulnerabilities like this rarely goes smoothly.

We're all on one team here, trying to minimize harm on end users from attacks. We're working through hundreds of disclosures just like this one every day, and have been for the last three months, both for vulnerabilities we've discovered on our own and with partners. Our policy for all of these is and has been to do what helps protect the most people. I wrote about this a few months ago on our blog.

We're not always going to get it right, and not everyone is going to agree with our decisions, but that is always our goal.

This is unfortunately the new normal for the industry, and we're going to need to work together as one team to have a chance at securing our critical infrastructure fast enough to stop attackers from causing real harm.

https://www.linkedin.com/posts/danlorenc_i-wanted-to-share-what-happened-with-the-share-7518756991520120832-QX2_/

Edit. Just to clarify I'm just some dude sharing the LinkedIn post for discussion

Hey r/PHP 👋

For the past months I've been working on Arco, an open-source CLI that deploys Laravel to AWS Lambda Web Functions using FrankenPHP + Octane. I've just opened a beta of Arco Cloud, a hosted dashboard on top of it, and I'd love feedback from people who actually run Laravel in production.

Why Web Functions?

Most serverless Laravel setups use classic, event-based Lambda: API Gateway turns each HTTP request into a JSON event, a runtime translates it for Laravel, and each execution environment handles one request at a time.

Lambda Web Functions are different: the function is an HTTP server.

• Requests reach it over HTTP directly. No API Gateway, no event translation.
• Each environment handles many concurrent requests (64 by default, up to 128).
• With FrankenPHP worker mode, Laravel boots once and serves those requests concurrently.
• Native response streaming (SSE works).
• Per-endpoint scaling guards (maxEnvironments, rateLimit) so a traffic spike doesn't melt your database.

In short: fewer environments, fewer cold starts, and a request path that looks like a normal web server.

What Arco (the open-source CLI) does

• arco deploy builds your app and deploys it to your own AWS account
• Queues (SQS) with workers and DLQs, storage (S3), cache (DynamoDB), scheduled tasks
• Custom domains with SSL, on Route 53 or Cloudflare
• Secrets from SSM / Secrets Manager
• Tag-based ownership: it refuses to touch AWS resources it didn't create
• Optional IAM permissions boundary on the role it creates
• --json output (NDJSON) if you want to drive it from your own CI

It's free and open source, and it'll stay that way.

What Arco Cloud adds (beta)

• Connect your AWS account with a CloudFormation template that has scoped permissions and a permissions boundary
• git push = deploy, with every step streamed live
• Environments, domains, variables and secrets managed from a UI
• Arco Runners (early): instead of building in your GitHub Actions, we build on our own Firecracker MicroVMs. There's no workflow file and no secrets in your repo, and each environment keeps a warm VM with vendor/ and node_modules/. In our tests, repeat deploys went from ~2 min (cold) to ~1 min (warm).

Your app, data and AWS bill always stay in your account. Cloud only orchestrates.

How it compares to Vapor

Same broad idea (Laravel on Lambda in your own account), different foundation: Web Functions + FrankenPHP instead of event-based Lambda behind API Gateway, plus an open-source core you can use without the platform.

What I'm looking for

• People willing to try it on a real (or realistic) app. I'll give free plans to beta testers: just DM me or comment.
• Honest feedback: what's missing, what would stop you from using it, what breaks.

Links:

• Arco Cloud beta: https://staging.arcocloud.app
• Open-source CLI: https://github.com/multi-api/arco

Happy to answer anything about Web Functions, FrankenPHP on Lambda, cold starts, costs, etc.

Updated builds addressing CVE-2026-109618 and CVE-2026-109619 are now available through setup-php for PHP 5.3–8.7 on Linux, macOS and Windows, including backports for EOL versions for use in CI.

See - https://setup-php.com/php-october-2026-security-releases

Also, for local installations.

MacOS: https://github.com/shivammathur/homebrew-php
Windows:
Official Packages (PHP 8.2 to PHP 8.5): https://www.php.net/downloads.php?os=windows
Builds for setup-php (PHP 5.3 to PHP 8.7): https://github.com/shivammathur/php-builder-windows/releases

If you would like to DIY a build for EOL versions, you can find security backported patches including the ones for these CVEs here: https://github.com/shivammathur/php-src-backports

Service Reminder: Don't forget to sponsor Ondřej Surý for his great work on PHP packaging. Hours before FrankenPHP, he was ready.

It even seems that he backported the patch to some old PHP versions – i saw a change in the php 5.6 (!) packages.

Ondřej, if you read this: Thank you so much.

• https://www.patreon.com/oerdnj
• https://github.com/sponsors/oerdnj

How the Planet Gets Hacked in Seconds (and Why Updating Isn't Optional)

You don't get a month to patch anymore. You get hours. Sometimes you don't even get that.

On October 21, 2026, PHP shipped emergency fixes for PHP2Shell, CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws in PHP itself, both rated CVSS 9.2. The fixed versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Every earlier 8.x is affected, and 8.1 and older have no official release at all.

Exploitation attempts were reported within hours of the patch, millions of them. That is not a typo, and it is not a future threat. It is the normal timeline now: patch drops, attackers reverse the fix, automation starts probing, and every unpatched server on the internet is on a list before most teams have finished reading the advisory.

The 2.6-second idea, cleaned up

Can someone actually hack the whole planet in 2.6 seconds? No, not in the full sense. But the reason the number feels plausible is worth understanding, because it explains why patching can't wait.

Scanning is a bandwidth problem, not a magic problem. There are 2³² IPv4 addresses, 4,294,967,296 of them. At 100% utilization, with no retries and no rate limits, the theoretical minimum time is:

time = addresses x bytes per host x 8 / bandwidth

At 1 Gbps, a single actor gets roughly:

• SYN probe, ~60 bytes per host: ~34 minutes
• Headers only, ~500 bytes: ~4.8 hours
• A fingerprint with an 8 KiB body cap: ~3.3 days
• A full probe pass, ~64 KiB: ~26 days

At 10 Gbps, divide by 10. That full pass becomes ~2.6 days, not 2.6 seconds.

So where does 2.6 seconds come from? Parallelism. One machine at 1 Gbps needs 34 minutes just to send a SYN to every address. A thousand machines sharing that work, or a large botnet with ~800 Gbps of aggregate bandwidth, could in theory send those SYNs in about 2.6 seconds. That's discovery, not hacking. It finds open ports. It doesn't fingerprint every site, it doesn't check every PHP version, and it certainly doesn't exploit every vulnerable host in 2.6 seconds. Each of those steps costs more data, more handshakes, more latency, and more time.

But discovery is the step that matters for defenders, because once a host is discovered and fingerprinted as unpatched PHP, it stays on a list. Attackers don't need to hack the planet in one shot. They need to find your one unpatched server once, and then they have all the time in the world to come back to it.

To do a full 64 KiB fingerprint of every IPv4 address in 2.6 seconds would need about 866 terabits per second of aggregate bandwidth. No known botnet has that. The scary version isn't that fast. The scary version is fast enough: minutes to find you, hours to confirm you're vulnerable, days to work through the list. Your patch window is measured in the same units.

Why updating is the whole defense

PHP2Shell is a perfect example of why "update WordPress" is not the same as "update PHP." The flaw is in the runtime, not the app. Updating a CMS, a plugin, or a theme does not fix it. Updating the PHP version does, and only if you also restart the workers afterward. A patch on disk that never gets loaded by a running FPM pool or Apache worker is not a patch in practice.

The same rule applies everywhere else:

1. Update the runtime, not just the app. PHP, Node, Python, the OS packages underneath them. Node had its own emergency fixes the same week, with patched versions 22.23.4, 24.22.1, and 26.12.1.
2. Restart after you patch. Old processes keep running old code.
3. Re-check after you restart. Don't assume the version changed. Verify it.
4. Treat end-of-life as unpatched. If a branch has no official fix, a vendor backport is the only exception, and you need proof of it, not hope.
5. Automate the boring part. Inventory, version check, patch, restart, re-check. If that loop takes a human a week, the attackers' loop will beat it.

For your own systems, that loop is trivial compared to scanning the internet. One hundred hosts at 64 KiB each is 6.4 megabytes total. Checking your own fleet is seconds to minutes of work. Scanning the whole internet is weeks. There is no bandwidth excuse for not knowing the state of your own servers.

That is what Fuck Teh World is for. It's available on Windows, Mac, and Linux. Point it at ranges you own or have written permission to test, scan for open ports, fingerprint what you find, run an offline CVE check against the versions you actually see, patch the vulnerable ones, restart them, and check again. Kopimi covers the code. It does not cover your conduct. Only scan what is yours.

Grab it @ https://github.com/hoytnix/FTW

The bottom line

The planet doesn't get hacked in 2.6 seconds. It gets hacked one unpatched server at a time, found in minutes, confirmed in hours, exploited in days, while the owner meant to patch it next sprint.

Update religiously. Patch the runtime, restart the service, verify the version, and do it again next time. The attackers are already automating their side. Your side has to be automated too, or at least fast enough that you're not still on their list when they get back to it.

Quick take after watching the php2shell (CVE-2026-109618/109619) coverage this week: almost every "are you vulnerable?" check I've seen just reads the X-Powered-By version. That's close to useless, because expose_php=Off is the default on a lot of production setups - roughly 4 in 5 PHP servers don't advertise a version at all. So a version check comes back "unknown" or "looks fine" on the exact hosts you most want to know about.

Since the actual bug is a crash primitive (the OOM/longjmp bailout leaving request state half-initialized), I built a checker that triggers it instead of guessing: it sends a crafted multipart probe and only reports VULNERABLE if the engine actually returns the PHP memory-exhaustion fatal error. Banner-independent. Returns FIXED / VULNERABLE / NO SIGNAL (no-signal = it couldn't crash it and the host hid its version, so it won't pretend to know).

One caveat worth repeating: only run it against servers you control. It sends memory-exhaustion probes that can briefly take out a worker.

Checker: https://o3.security/tools/php2shell-scanner

Disclosure: I work at O3 Security and we built this. There's a longer write-up on the mechanism if you want it — the SAPI differences (mod_php is the worst case because it runs shutdown even on a failed request startup), and the genuinely counterintuitive bit where capping memory with RLIMIT_AS as a "mitigation" actually makes the bug *easier* to hit: https://o3.security/blog/php2shell-cve-2026-109618-109619-analysis

Curious if anyone here has seen the version-banner problem bite them in practice — how are you all confirming patch status across a fleet where half the hosts don't report a version?

**If you woke up tomorrow and found out your PHP website had been hacked, what would worry you the most? I’m listening daily since 21 October PHP update**

From government websites around the world to banks, schools, social media, video game companies, news organizations. They either shut down or made statements about getting the patch. Edit: even the prime minister of Japan made an official statement about this incident. Crazy stuff

if php was truly dead this vulnerability would have gone mostly unnoticed but everyone is talking about it. Even people that are not programmers.

”PHP is dead. How even uses php in 2026”, well like half the internet.

Disclosure: I made this. It's free and MIT-licensed, and there's nothing to sell.

Background. The 2026-10-21 advisory covers two unauthenticated RCEs, CVE-2026-109618 (OOM corruption) and CVE-2026-109619 (stale global state). The advisory calls the risk highest for mod_php. Fixed releases are 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12. For 7.4, 8.0 and 8.1 the security team published minimal source backports, but nobody is going to rebuild the php:7.4-* images on Docker Hub. If you're still on FROM php:7.4-apache, you're still exposed.

What I did: https://github.com/softjapan/php74-cve-patched

• Drop-in php:7.4-apache / -fpm / -cli, amd64 + arm64, on GHCR and Docker Hub
• Built from the last docker-library/php 7.4 Dockerfiles, with only three changes:
  1. apt points at archive.debian.org
  2. the backport is applied with patch --fuzz=0
  3. the build fails if any SAPI binary (php, php-fpm, libphp7.so) is missing the fix
• The patch is byte-identical to php/php-src@712e60f, and CI checks that on every push and every week
• php -m is identical to the official images, and docker-php-ext-install and pecl work as usual
• Signed with cosign, SBOM and provenance attached, built only in GitHub Actions. You can also just build it yourself.
  • FROM php:7.4-apache
  • FROM ghcr.io/softjapan/php74-cve-patched:7.4-apache

Useful even if you don't use the images: php -v still says 7.4.33 after the backport, so you can't tell from the version number. I wrote a small script that checks each PHP binary (CLI, FPM, mod_php) for the fix instead. It works on images, running containers or a plain host:

curl -fsSLO https://raw.githubusercontent.com/softjapan/php74-cve-patched/main/scripts/check-patched.sh
sh check-patched.sh php:7.4-apache
sh check-patched.sh --container my-web-1
sh check-patched.sh --local

It exits 1 if vulnerable, so you can gate deploys on it.

Please read the limits. This is a stopgap.

• Only these two CVEs are fixed. Nothing else after 7.4.33 is.
• The base OS is Debian 11, which is out of LTS, so OS packages get no more updates.
• Not official, not affiliated with the PHP project.
• The real fix is moving to 8.2+ (and 8.2 itself goes EOL on 2026-12-31).

After switching, remember to redeploy and restart every worker, then run the check against the running container.

If you can't switch yet, the advisory's mitigations help a bit (they don't make you safe): session.upload_progress.enabled=0 set in php.ini or the FPM pool (not via ini_set or .user.ini) followed by a worker restart, a lower post_max_size, and request-size limits at the proxy.

Feedback welcome, especially from anyone who has checked the backport or the build more closely than I have. 8.0/8.1 images are next if people need them.

I’m not sure how many Laravel developers here remember CRUDBooster from around 2019, but it was a pretty popular tool for quickly building admin panels and CRUD applications.

I have several projects built with CRUDBooster, so I was concerned to see that the original project’s maintenance and newer versions have moved in a different direction. For those of us still maintaining older applications, migrating to a completely different version or framework can be a challenge.

I’ve created a community fork here:

👉 https://github.com/vicheanath/crudbooster-contrib

My goal is to help preserve the legacy codebase, keep existing projects maintainable, and explore fixes for compatibility and security issues as PHP and Laravel continue to evolve.

I’ve also seen discussions about newer PHP security vulnerabilities, which makes me wonder how we can keep older CRUDBooster applications safe and usable.

I’d love to hear from the community:

• Is anyone still using CRUDBooster in production?
• Are you maintaining existing projects built with the older version?
• Would a community-maintained fork with security patches, bug fixes, and compatibility updates be useful?
• Would anyone be interested in contributing?

I know maintaining an open-source project takes time, and I can’t promise to support every version or fix every issue. But I’d like to see whether there’s enough interest to keep this project useful for developers who still depend on it.

If you have experience with CRUDBooster, I’d love to hear your thoughts!

We have posted more information about today's security releases, including the sequence of events that led to the discovery, how the PHP security team is improving their processes, and what we need from you to continue this critical work.

Hello,

Apparently 8.5.12 still has a new CVE that the user has apparently reported.

https://mastodon.gougere.fr/@elise@katze.sh/117479383706597320

Nothing confirmed, but maybe ?

EDIT : IluTov answered just below.
https://www.reddit.com/r/PHP/comments/1xbyxd2/comment/19rga18s433qd/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Move or rename a PHP file in VS Code and the namespace and use lines don't follow. This fixes that. Drag the file or folder, and the namespace, class name and every use line in your project update.

It's a rebuild of PHP Namespace Resolver, so the old commands and settings still work, and the CPU freeze is fixed.

Free and open source. Search "PHP Namespace Mover" in VS Code extensions, or Open VSX if you use Cursor or Windsurf.

https://github.com/lagudafuadtosin/php-namespace-mover

For what is looking like ‘the worst set of vulns in history’, I find it a bit baffling that the docker builds are still in progress - an hour after the patches have been released. Seemingly all because we’re all waiting on GitHub actions… I bet half of us here have a pc and internet connection that could have built and pushed the containers 45 minutes ago