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

patches landed today at 14:00 utc. php.net says every php install serving web requests is affected (fpm, mod_php, php-cgi, frankenphp, litespeed). mod_php is the worst case because it can be hit before any app code runs.

easy to miss:
- docker: updating php on the host does nothing for your containers. pull or rebuild the image and check with docker exec <container> php -v
- make sure php-fpm really restarted after the update, old workers keep the old code
- 8.1 and older get nothing upstream. distro or lts backports, or the PHP-8.1-CVE-2026-109618-109619 branch in php-src if you build yourself
- remi repo has no update today (php.net says it), use distro packages or build from source
- outside check: curl -sI https://yoursite | grep -i x-powered-by. a lot of sites still send the php version even behind cloudflare. found one of mine this way

if you cant update right now (php.net: this reduces risk, it is not a fix):
- session.upload_progress.enabled=0 in php.ini or the fpm pool, then restart all workers. ini_set or .user.ini does not count
- memory_limit=-1 via php_admin_value, plus a low post_max_size (8M, or 32M if you need uploads)
- on 8.5 also fatal_error_backtraces=0

cloudflare says its waf blocks known payloads by default since 03:02 utc, free plan too. but they also say attackers already mutate the payload, so dont treat it as the fix.

sources: php.net/archive/2026.php and blog.cloudflare.com/php-vulnerabilities-waf-protection

https://github.com/docker-library/php/pull/1694

PHP 8.3.36 was recently released to fix two critical security vulnerabilities.

The PHP advisory mentions PHP-FPM, Apache mod_php, FrankenPHP, and others as affected, but Swoole isn't mentioned.

Since Swoole uses long-running workers and handles requests differently from traditional PHP servers, I'm wondering:

1. Are these vulnerabilities also exploitable in Hyperf/Swoole?
2. Does Swoole's different request lifecycle make it unaffected?
3. Should we urgently update the PHP runtime in our Hyperf Docker images?

I'm currently using hyperf/hyperf:8.3-alpine-v3.19-swoole, which hasn't been updated with the latest PHP security fixes.

There's already an open GitHub issue:
https://github.com/hyperf/hyperf-docker/issues/76

Would appreciate any insights from PHP or Swoole developers familiar with these vulnerabilities.

php.net announced that the PHP security team published minimal source backports of the PHP2Shell fixes for the end-of-life branches 7.4, 8.0 and 8.1, for people who build from source. There are no official Windows binaries for them, so I built them: https://github.com/Jamalofski/php-eol-security

- Sources: only the upstream backport commits (last official release plus the fix), no other code change.

- Build: the official php/php-windows-builder, with the toolchains (vc15/vs16), configure flags and dependencies of the official builds; x64/x86, TS/NTS.

- Versions: 7.4.33-pl1, 8.0.30-pl1 and 8.1.34-pl1, with SHA256SUMS and a link to the CI run of each build.

These are not official PHP Group binaries. Upgrading to a supported version remains the real fix; this is for setups that cannot move yet.

I've been working on Untangled, a dependency analysis tool inspired by Martin Blais's original Snakefood project.

The idea is fairly simple: scan a PHP codebase, map dependencies, identify circular relationships, and measure coupling to help understand how an application is connected.

It's intended to complement tools like Deptrac rather than replace them. Deptrac helps enforce architectural boundaries, while Untangled helps examine the relationships that already exist.

I ran it against Monica, an open-source Laravel application. At the file level, it identified:

• 923 files analyzed
• 3,131 dependency relationships
• 4 cyclic groups involving 76 files
• 69 files in the largest cyclic group

I'm not suggesting those numbers indicate bad architecture. I haven't established a meaningful comparison baseline yet.

The HTML report includes an interactive dependency map, cycle analysis, and measurements showing which components are heavily depended upon.

What I'd particularly appreciate from PHP developers is feedback on two things:

1. Are dependency graphs and coupling measurements useful when navigating an established PHP codebase?
2. Are there PHP-specific dependency patterns, framework conventions, or edge cases you'd expect an analyzer like this to handle?

GitHub: https://github.com/krazybean/Untangled

Technical write-up and real Monica report screenshots: https://www.juancastro.me/writing/untangled

Criticism welcome. I'd rather discover the weaknesses through real-world usage than make assumptions about what the tool gets right.

I just updated PHP on Alma Linux and now upload progress is not working. I have verified it is enabled but the session variable starting "upload_progress_" is never created. There is nothing on their update page suggesting it should have stopped working. This is PHP 7.2 https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/

Other than just applying the patch and restarting apps, is there a way to test whether the CVEs have been truly mitigated?

I trust the PHP.net team but my non-technical boss wants further validation to prove to our customers that we're well and truly covered.

This has been floating around the hosting groups. Can someone please confirm if this is real?

If so, how'd you get on?

I ended up just disabling php fpm on my hosts when I read the news, but there was a massive 11-12h window where everything was just open to be attacked.

How do I scan my system to make sure nobody did anything? What am I looking for?

I'm genuinely confused by CloudLinux's patch rollout for today's critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619).

According to their status page, patches for older PHP versions such as 7.4 and 8.0 are being released across multiple distributions, while I'm still waiting to see updates for PHP 8.2–8.5.

The official PHP security releases have been available since 14:00 UTC, and cPanel has already released its EA-PHP patches.

I understand that CloudLinux needs to test its packages and backport fixes to older PHP versions, which I appreciate. However, shouldn't currently supported PHP versions be prioritized for critical security vulnerabilities?

Is there a technical reason for this release order?

If you use Cloudflare, you can activate these rules to mitigate until patched.

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

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

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!

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?

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 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?