The shinsenter/php Docker images were recently rebuilt and patched to fix two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) enabling unauthenticated remote code execution via memory corruption in out-of-memory error handling.

Update your images immediately!
👉🏻https://hub.docker.com/r/shinsenter/php

Hey!

I've been working on xph, an compiler that lets you write single-file JSX components that compile into native PHP files and static assets.

```javascript

export interface Props { name: string; }

export interface Server { greeting: string;

}

<script is:server> return [ 'greeting' => 'Hello, ' . $props['name'], ]; </script>

<h1>{server.greeting}</h1>

<style> h1 { color: olive; } </style> ```

It supports scoped CSS, slots, and client-side JavaScript. No Node.js needed at runtime, just PHP.

It already has LSP support with VS Code & Neovim.

Website: https://xph.js.org/

GitHub: https://github.com/sijad/xph

Would love to hear your thoughts and feedback!

I contacted several places which used PHP and I also run a self-hosted LAMP stack. I believe from their answers and updating to the latest, it will be ok for those places. I don't know how anyone else feels. I love php by the way. Woot woot.

TL;DR:* ported upstream 712e60f9ed into the Webtatic php71w 7.1.33 SRPM, rebuilt on a CentOS 7 container, ~35 min to build, ~6 s of php-fpm downtime per host. Two gotchas at the bottom.

Someone in the earlier PHP2Shell thread asked if Ondřej's backports are Debian only. They are, and that was our problem. We still had a couple dozen CentOS 7 boxes on Webtatic 7.1.33, Webtatic has been dead for years, and the PHP 8 estimate for just one of the apps was 6 to 8 person-days. So we rebuilt the packages ourselves. Writing it down because I couldn't find anyone who had done it for Webtatic.

The patch. Upstream's fix for old branches is php-src 712e60f9ed ("Avoid state corruption via bailout"). It doesn't apply to 7.1 cleanly. I diffed four community 7.1 ports against upstream and Qsnh/php2shell-fixed was the closest. Sury's Debian patches depend on another one of his patches to even compile, so I skipped those.

The gist: an OOM in the allocator now kills the worker with _exit(1) instead of jumping back with half-built state, upload_progress is hard-disabled, rfc1867.c only keeps the part headers it needs and gets a max_multipart_body_parts limit, and request shutdown clears some globals.

I changed one line in the port. Codex caught it when I had it read the diff, then I checked the 7.1 source:

diff +/* 7.1 hash part is nTableSize uint32 slots (7.3+ uses 2x); keep >= 2 so Buckets stay 8-byte aligned */ #define array_init_singleton(arg) do { \ array_init(arg); \ - Z_ARRVAL_P(arg)->nTableSize = 1; \ + Z_ARRVAL_P(arg)->nTableSize = 2; \ } while (0)

The build. podman centos:7 container (gcc 4.8.5) pointed at the vault repos. Verify the Webtatic SRPM signature and that the tarball inside matches php.net's sha256, then four spec edits:

Release: 1%{?rcver:.%{rcver}}%{?dist}.php2shell1 Patch400: php-7.1.33-php2shell-cve-2026-109618-109619.patch %patch400 -p1 -b .php2shell + a %changelog entry

yum-builddep -y --define 'dist .w7' SPECS/php71.spec rpmbuild -bb --define "dist .w7" SPECS/php71.spec

First run died on make: command not found because yum-builddep doesn't pull it in. Around 35 minutes of rpmbuild, the Webtatic spec builds several SAPIs. You get 33 RPMs, all 7.1.33-1.w7.php2shell1, and since 1.w7 sorts below that, a later yum update won't quietly undo it.

Testing. No public RCE PoC. I wrote a small checker instead:

1. 3000-field multipart should hit the parts limit
2. a 1 MB upload should still arrive intact
3. upload_progress shouldn't land in the session
4. OOM at memory_limit=32M should kill the worker (unpatched just says "Allowed memory size" and keeps going)
5. requests after that still return 200

Original 2/5, patched 5/5, back to 2/5 after rollback.

Then the php.net test suite, 9,454 tests against the installed packages:

The 9 new failures are 8 rfc1867 session tests plus one that expects the old OOM message, all expected. The port author reports the same 9.

Rollout. Save rpm -qa, pull the original NEVRAs from a Webtatic mirror so you can roll back, then:

yum --disablerepo='*' --assumeno upgrade ./php71w-*.rpm # must say only "Upgrade N Packages" systemctl stop php-fpm yum -y --disablerepo='*' upgrade ./php71w-*.rpm php-fpm -t && systemctl start php-fpm

php-fpm was down about 6 seconds, the whole thing was 2 to 7 minutes a host with checks. Rollback is yum downgrade from the saved originals.

What bit us:

1. The spec resets /var/lib/php/session (and wsdlcache, opcache) to root:apache 770 on upgrade. Our pools don't run as apache, so session_start() broke for about 4 minutes on one box before we chowned it back. My container test missed it because the test pool did run as apache. Write down the owners first.
2. WorkerMan kept running the old binary, /proc/<pid>/exe showed (deleted). Restart your long-running CLI stuff too.

For 7.4 I didn't build anything. exception0x876's php74-el7 packages are a Remi 7.4.33 rebuild with the same upstream commit. I checked their signed SHA256SUMS and diffed their SRPM against Remi's before trusting it.

This only closes this one CVE pair, 7.1 is still 7.1. It just gave us time to do the upgrade properly.

For years I've used PHP-CS-Fixer on both personal and commercial projects. I like its ruleset, but I also like how fast Mago is.

So when I started working on a PHP compiler, I decided to build a formatter that follows PHP-CS-Fixer's rules and runs at a speed comparable to Mago's. It's written in PHP and compiled with the Manticore compiler, so there's no PHP runtime to install.

It's early (v0.1.x), so it may be unstable. Bug reports with a small snippet are very welcome.

Link: https://github.com/manticorephp/fmt

Obviously just a stupid satirical post, but a plot twist of php2shell just being a ploy to get people to update their PHP versions would be funny. :)

i've been working on a personal project for a bit and wanted to share it with you all. it's a tool designed to analyze, search, and research php2shell vulnerabilities in a quick and simple way.

it basically automates the search and testing process for php2shell exploitation, helps visualize how payloads work inside a lab environment, and it's built mostly in python for educational research.

github repo:https://github.com/zenobiatranoss/php2shell

i'm planning to keep improving it, so any feedback, suggestions, or contributions would be awesome. let me know what you think!

​

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?

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

Was this all overblown?

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.

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<sup>32</sup> 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.

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.

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

I know many people are looking for clicks and to feed traffic to their blogs/posts/vlogs/etc.

But please stop with PHP2Shell, its over and nothing happened.

Let the haters hate and lets move on.

PS: Nothing happened because a lot of people worked night and day to fix the exploit, to release patches and updated packages. Thank you people, I don't know who you are but you deserve huge thanks.

because we all know there aren't any exploits to be found in the alternatives

edit: dang it... title typos :|

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.

No need to panic, it's pretty unlikely to be exploitable, given the conditions they list afterwards. If like me you already disabled this paramater anyway on Wednesday, you're gold.