FrankenPHP: The modern PHP app server (11k stars)
What it does
All text below is quoted directly from the project README.
>FrankenPHP is a modern application server for PHP built on top of the Caddy web server.
FrankenPHP: modern app server for PHP:
- FrankenPHP gives superpowers to your PHP apps thanks to its stunning features: Early Hints, worker mode, real-time capabilities, hot reloading, automatic HTTPS, HTTP/2, and HTTP/3 support...
- FrankenPHP works with any PHP app and makes your Laravel and Symfony projects faster than ever thanks to their official integrations with the worker mode.
- FrankenPHP can also be used as a standalone Go library to embed PHP in any app using net/http.
- Linux binaries are statically linked, so they can be used on any Linux distribution without installing any dependency.
- macOS binaries are also self-contained.
- They contain most popular PHP extensions.
>curl https://frankenphp.dev/install.sh | sh
Repository
php/frankenphp
Repository stats
|Metric|Value|
|:-|:-|
|Stars|11,469|
|Forks|503|
|Last release|v1.13.4 (2026-10-26)|
|Languages|Go 76.4%, C 8.7%, Hack 8%|
|Contributors|172|
|AI contributor accounts (Claude / Codex / Cursor / Copilot)|None|
|AI co-authored commits|Claude: 7, Copilot: 18|
Main contributor
|Field|Value|
|:-|:-|
|Name|Kévin Dunglas|
|GitHub|@dunglas|
|Commits to this repo|708 (top contributor)|
|Bio|Founder of @coopTilleuls, a dev co-op. Creator of FrankenPHP, @api-platform, Mercure.rocks, and numerous other free/open-source software. @symfony Core Team.|
|Company / Location|Lille, France|
|X / Twitter|@dunglas|
|Followers|4.6k|
──────────────────────────────
📌 How many great GitHub repos have you discovered and completely forgotten about?
Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week.
📬 Never lose track of great repos again. Subscribe free.
7 points
GHSA's published for frankenphp:
low: github.com/php/frankenphp/security/advisories/GHS…
moderate: github.com/php/frankenphp/security/advisories/GHS…
1 like
PHP2Shell: how I patched my Symfony server
---
title: PHP2Shell: how I patched my Symfony server
published: true
date: 2026-10-22 00:00:00 UTC
tags: php, symfony, security, devops
canonical_url: apprendre.forelse.fr
---
On the evening of 20 October, two critical flaws were disclosed in PHP: CVE-2026-109618 and CVE-2026-109619, quickly nicknamed "PHP2Shell". They allow unauthenticated remote code execution on the server, and are rated 9.2 out of 10. By the next morning, real-world attacks were already being reported.
These flaws are not in Symfony or Laravel, but in the PHP interpreter. No composer update fixes them: you have to change PHP itself. Here is how I did it for apprendre.forelse.fr, which runs on Symfony and FrankenPHP in Docker.
1. Know which PHP actually runs
First question: which version of PHP is serving requests? Not the one on my laptop, nor the one written in composer.json, but the one in the production container.
docker compose exec app php -v
PHP 8.4.26 (cli) (built: Oct 6 2026 01:25:42) (ZTS)
PHP 8.4.26: the latest version published at that point, and yet vulnerable. The fix did not exist yet.
My Dockerfile starts from dunglas/frankenphp:1-php8.4. That tag follows new releases of PHP 8.4, which gives the impression of always being up to date. It is not: the image is frozen at the moment it is built. Mine dated from 16 October. Until I rebuild it, it keeps the PHP from that day, even after FrankenPHP publishes a fixed image.
> A floating tag (php8.4, latest) only gives you the latest version at the moment you rebuild the image.
2. A stopgap while waiting for the fix
The official fix was announced for 21 October at 14:00 UTC. In the meantime, I reduced the attack surface. Both flaws are memory issues. The first (CVE-2026-109618) is a memory corruption: a multipart request crafted to exhaust memory abruptly aborts request processing. The second (CVE-2026-109619) is a use-after-free between two requests served by the same worker. According to Rapid7's analysis, its first known trigger is upload progress tracking, session.upload_progress. It is enabled by default, and usable without even calling session_start().
My application does not use that tracking. So I turned it off in php.ini:
session.upload\_progress.enabled = Off
This file ships inside the image: the change only reaches production after a rebuild and a redeploy, like any other config. Then you check it was applied (in the FrankenPHP image, the CLI and the server read the same php.ini):
docker compose exec app php -i | grep upload_progress.enabled
This is not a fix. It closes the first known trigger of the second flaw, but not the memory corruption of the first. One unused option switched off is one less open door until the real fix is in.
3. Rebuild the image with the fixed PHP
The fix shipped on 21 October 2026: PHP 8.4.27 for my branch (and 8.2.35, 8.3.36, 8.5.12 for the others). FrankenPHP followed the same evening with its 1.13.2 release, whose images already bundle these fixed PHP versions.
My Dockerfile started from dunglas/frankenphp:1-php8.4, a floating tag. I took the opportunity to pin an exact version: dunglas/frankenphp:1.13.2-php8.5, which bundles PHP 8.5.12, fixed as well. To stay on PHP 8.4 without switching branches, 1.13.2-php8.4 gives you 8.4.27.
That leaves rebuilding the image. Since hosted CI runners are fresh every time, the FROM re-pulls the base image. But on a machine that already has an image cached, Docker would reuse it: to be safe, force a re-pull of the base image.
docker build --pull -t my-image .
In CI with docker/build-push-action, the equivalent is the pull: true option. The layer cache (cache-from) is not a problem here: its key depends on the base image's digest, which has changed, so every layer that builds on it is rebuilt.
Then redeploy, and check again:
docker compose exec app php -v
The version shown should now be 8.5.12. As long as it says 8.4.26, the old image is still running.
4. A safety net for next time
What bothered me most in this episode was not knowing right away that my production server was still running a vulnerable PHP. composer audit only looks at PHP dependencies, not the interpreter. So I added a safety net to my CI: when I cut a release (a tag), a job reads the PHP actually bundled in the image and compares it to the latest published version of its branch. If it is behind, the job raises a clearly visible warning on the release.
# PHP bundled in the image we are about to publish
installed=$(docker run --rm --entrypoint php "$IMAGE" -r 'echo PHP\_VERSION;')
branch=${installed%.\*} # 8.5.12 -> 8.5
# Latest published version of that branch, per php.net
latest=$(curl -fsS "https://www.php.net/releases/?json&version=${branch}&max=1" \
| jq -r 'keys\_unsorted[0]')
if dpkg --compare-versions "$installed" lt "$latest"; then
echo "::warning::PHP ${installed} is behind ${latest}, consider bumping the base image."
fi
I wired it so that it only runs when cutting a release, not on other builds. I chose a warning rather than a failure: being one patch behind should not stop me from shipping, but it must be visible. This is not protection against the flaws themselves: it is a reminder, at the right moment, that the base image has fallen behind. Paired with a tool that watches the base image (Renovate, Dependabot), the window between "a fixed PHP exists" and "my production runs it" closes on its own.
5. What I take away
- Watch PHP, not just Composer. composer audit does not see flaws in the interpreter. Hence the CI safety net from section 4, which compares the image's PHP to the latest published version.
- Rebuild regularly, and track the base image. An image you never rebuild quietly goes stale. And if you pin an exact base version, which is safer for reproducibility, you need a tool like Renovate or Dependabot to get notified of new versions.
- Turn off what you don't use. session.upload_progress is enabled by default, while few applications use it.
- Check inside the container. The only version that matters is the one php -v returns in production.
Sources
- Rapid7 analysis of both CVEs
- FrankenPHP v1.13.2 (release fixing both CVEs)
- Patchstack
- watchTowr
A brand new version of FrankenPHP is out, including all the vulnerability fixes. Update now!
Many thanks also to @ThePHPF and the @Docker team for their intensive work. If you need any assistance, we're here to help.
github.com/php/frankenphp/releases/tag/v1.13.2
11 likes · 504 views
The #php2shell patch for FrankenPHP is out now. Docker images available, binaries to follow in the next hour or so.
Upgrade and spread the news, thank you all for your patience!
github.com/php/frankenphp/releases/tag/v1.13.2
36 likes · 7 reposts · 1,579 views
PHP vulnerability:
The patched Linux and Windows FrankenPHP binaries are out! Still waiting on the macOS build and the official PHP Docker images to wrap up, though.
github.com/php/frankenphp/releases
53 likes · 9 reposts · 3,139 views
🚨 Critical PHP vulnerability update 🚨
Patched PHP versions have officially been released!
Here is the latest status on FrankenPHP:
⚙️ Binaries: FrankenPHP 1.13.1 binaries with patched PHP 8.5 are currently building: github.com/php/frankenphp/actions/runs/39621584304
🐳 Docker: Waiting on upstream patched Docker images before rebuilding ours
🏷️ Next Release: FrankenPHP 1.13.2 (including unrelated bug and security fixes) will be tagged as soon as 1.13.2 binaries and Docker images are ready
💙 Maintaining open-source projects takes serious effort. Consider supporting the work via GitHub Sponsors and donating to the PHP Foundation!
105 likes · 23 reposts · 8,292 views
FrankenPHP の会場はこちらです
frankenphp#2732
15 likes · 3 reposts · 1,691 views
Mentions
FrankenPHP: The modern PHP app server (11k stars) What it does All text below is quoted directly from the project README. >FrankenPHP is a modern application server for PHP built on top of the Caddy web server. FrankenPHP: modern app server for PHP: - FrankenPHP gives superpowers to your PHP apps thanks to its stunning features: Early Hints, worker mode, real-time capabilities, hot reloading, automatic HTTPS, HTTP/2, and HTTP/3 support... - FrankenPHP works with any PHP app and makes your Laravel and Symfony projects faster than ever thanks to their official integrations with the worker mode. - FrankenPHP can also be used as a standalone Go library to embed PHP in any app using net/http. - Linux binaries are statically linked, so they can be used on any Linux distribution without installing any dependency. - macOS binaries are also self-contained. - They contain most popular PHP extensions. >curl https://frankenphp.dev/install.sh | sh Repository php/frankenphp Repository stats |Metric|Value| |:-|:-| |Stars|11,469| |Forks|503| |Last release|v1.13.4 (2026-10-26)| |Languages|Go 76.4%, C 8.7%, Hack 8%| |Contributors|172| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|None| |AI co-authored commits|Claude: 7, Copilot: 18| Main contributor |Field|Value| |:-|:-| |Name|Kévin Dunglas| |GitHub|@dunglas| |Commits to this repo|708 (top contributor)| |Bio|Founder of @coopTilleuls, a dev co-op. Creator of FrankenPHP, @api-platform, Mercure.rocks, and numerous other free/open-source software. @symfony Core Team.| |Company / Location|Lille, France| |X / Twitter|@dunglas| |Followers|4.6k| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.
GHSA's published for frankenphp: low: github.com/php/frankenphp/security/advisories/GHS… moderate: github.com/php/frankenphp/security/advisories/GHS…
PHP2Shell: how I patched my Symfony server --- title: PHP2Shell: how I patched my Symfony server published: true date: 2026-10-22 00:00:00 UTC tags: php, symfony, security, devops canonical_url: apprendre.forelse.fr --- On the evening of 20 October, two critical flaws were disclosed in PHP: CVE-2026-109618 and CVE-2026-109619, quickly nicknamed "PHP2Shell". They allow unauthenticated remote code execution on the server, and are rated 9.2 out of 10. By the next morning, real-world attacks were already being reported. These flaws are not in Symfony or Laravel, but in the PHP interpreter. No composer update fixes them: you have to change PHP itself. Here is how I did it for apprendre.forelse.fr, which runs on Symfony and FrankenPHP in Docker. 1. Know which PHP actually runs First question: which version of PHP is serving requests? Not the one on my laptop, nor the one written in composer.json, but the one in the production container. docker compose exec app php -v PHP 8.4.26 (cli) (built: Oct 6 2026 01:25:42) (ZTS) PHP 8.4.26: the latest version published at that point, and yet vulnerable. The fix did not exist yet. My Dockerfile starts from dunglas/frankenphp:1-php8.4. That tag follows new releases of PHP 8.4, which gives the impression of always being up to date. It is not: the image is frozen at the moment it is built. Mine dated from 16 October. Until I rebuild it, it keeps the PHP from that day, even after FrankenPHP publishes a fixed image. > A floating tag (php8.4, latest) only gives you the latest version at the moment you rebuild the image. 2. A stopgap while waiting for the fix The official fix was announced for 21 October at 14:00 UTC. In the meantime, I reduced the attack surface. Both flaws are memory issues. The first (CVE-2026-109618) is a memory corruption: a multipart request crafted to exhaust memory abruptly aborts request processing. The second (CVE-2026-109619) is a use-after-free between two requests served by the same worker. According to Rapid7's analysis, its first known trigger is upload progress tracking, session.upload_progress. It is enabled by default, and usable without even calling session_start(). My application does not use that tracking. So I turned it off in php.ini: session.upload\_progress.enabled = Off This file ships inside the image: the change only reaches production after a rebuild and a redeploy, like any other config. Then you check it was applied (in the FrankenPHP image, the CLI and the server read the same php.ini): docker compose exec app php -i | grep upload_progress.enabled This is not a fix. It closes the first known trigger of the second flaw, but not the memory corruption of the first. One unused option switched off is one less open door until the real fix is in. 3. Rebuild the image with the fixed PHP The fix shipped on 21 October 2026: PHP 8.4.27 for my branch (and 8.2.35, 8.3.36, 8.5.12 for the others). FrankenPHP followed the same evening with its 1.13.2 release, whose images already bundle these fixed PHP versions. My Dockerfile started from dunglas/frankenphp:1-php8.4, a floating tag. I took the opportunity to pin an exact version: dunglas/frankenphp:1.13.2-php8.5, which bundles PHP 8.5.12, fixed as well. To stay on PHP 8.4 without switching branches, 1.13.2-php8.4 gives you 8.4.27. That leaves rebuilding the image. Since hosted CI runners are fresh every time, the FROM re-pulls the base image. But on a machine that already has an image cached, Docker would reuse it: to be safe, force a re-pull of the base image. docker build --pull -t my-image . In CI with docker/build-push-action, the equivalent is the pull: true option. The layer cache (cache-from) is not a problem here: its key depends on the base image's digest, which has changed, so every layer that builds on it is rebuilt. Then redeploy, and check again: docker compose exec app php -v The version shown should now be 8.5.12. As long as it says 8.4.26, the old image is still running. 4. A safety net for next time What bothered me most in this episode was not knowing right away that my production server was still running a vulnerable PHP. composer audit only looks at PHP dependencies, not the interpreter. So I added a safety net to my CI: when I cut a release (a tag), a job reads the PHP actually bundled in the image and compares it to the latest published version of its branch. If it is behind, the job raises a clearly visible warning on the release. # PHP bundled in the image we are about to publish installed=$(docker run --rm --entrypoint php "$IMAGE" -r 'echo PHP\_VERSION;') branch=${installed%.\*} # 8.5.12 -> 8.5 # Latest published version of that branch, per php.net latest=$(curl -fsS "https://www.php.net/releases/?json&version=${branch}&max=1" \ | jq -r 'keys\_unsorted[0]') if dpkg --compare-versions "$installed" lt "$latest"; then echo "::warning::PHP ${installed} is behind ${latest}, consider bumping the base image." fi I wired it so that it only runs when cutting a release, not on other builds. I chose a warning rather than a failure: being one patch behind should not stop me from shipping, but it must be visible. This is not protection against the flaws themselves: it is a reminder, at the right moment, that the base image has fallen behind. Paired with a tool that watches the base image (Renovate, Dependabot), the window between "a fixed PHP exists" and "my production runs it" closes on its own. 5. What I take away - Watch PHP, not just Composer. composer audit does not see flaws in the interpreter. Hence the CI safety net from section 4, which compares the image's PHP to the latest published version. - Rebuild regularly, and track the base image. An image you never rebuild quietly goes stale. And if you pin an exact base version, which is safer for reproducibility, you need a tool like Renovate or Dependabot to get notified of new versions. - Turn off what you don't use. session.upload_progress is enabled by default, while few applications use it. - Check inside the container. The only version that matters is the one php -v returns in production. Sources - Rapid7 analysis of both CVEs - FrankenPHP v1.13.2 (release fixing both CVEs) - Patchstack - watchTowr
A brand new version of FrankenPHP is out, including all the vulnerability fixes. Update now! Many thanks also to @ThePHPF and the @Docker team for their intensive work. If you need any assistance, we're here to help. github.com/php/frankenphp/releases/tag/v1.13.2
The #php2shell patch for FrankenPHP is out now. Docker images available, binaries to follow in the next hour or so. Upgrade and spread the news, thank you all for your patience! github.com/php/frankenphp/releases/tag/v1.13.2
PHP vulnerability: The patched Linux and Windows FrankenPHP binaries are out! Still waiting on the macOS build and the official PHP Docker images to wrap up, though. github.com/php/frankenphp/releases
🚨 Critical PHP vulnerability update 🚨 Patched PHP versions have officially been released! Here is the latest status on FrankenPHP: ⚙️ Binaries: FrankenPHP 1.13.1 binaries with patched PHP 8.5 are currently building: github.com/php/frankenphp/actions/runs/39621584304 🐳 Docker: Waiting on upstream patched Docker images before rebuilding ours 🏷️ Next Release: FrankenPHP 1.13.2 (including unrelated bug and security fixes) will be tagged as soon as 1.13.2 binaries and Docker images are ready 💙 Maintaining open-source projects takes serious effort. Consider supporting the work via GitHub Sponsors and donating to the PHP Foundation!
FrankenPHP の会場はこちらです frankenphp#2732