Paul Schell – Blog https://paulschell.com/en/blog/ Articles on Symfony upgrades, PHP migrations and maintaining legacy projects: security updates, end-of-support dates and practical advice for existing projects. en Fri, 23 Oct 2026 08:00:00 +0000 Critical PHP vulnerability: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now https://paulschell.com/en/blog/php-security-vulnerability-october-2026/ https://paulschell.com/en/blog/php-security-vulnerability-october-2026/ Fri, 23 Oct 2026 08:00:00 +0000 Paul Schell Two critical PHP vulnerabilities allow unauthenticated remote code execution. Who is affected, which versions fix it and what to do on PHP 8.1 and older. On 21 October 2026 the PHP team released security updates for all supported versions. They fix two vulnerabilities that let attackers run code on the server without logging in. This update takes priority over everything else.

What happened

Both vulnerabilities (CVE-2026-109618 and CVE-2026-109619) are rated CVSS 9.2. They sit in PHP's own request handling, before any application code runs. A framework like Symfony or Laravel does not protect against them.

  • CVE-2026-109618: if PHP runs out of memory during a request, internal data can stay half initialized and later be treated as valid during cleanup.
  • CVE-2026-109619: internal state of a request can survive after its memory has been freed and be used by the next request on the same worker.

Who is affected

Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates the risk highest for mod_php, where an unauthenticated exploit has been demonstrated.

What to do now

  1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and LTS vendors received the patches in advance, so packages should be available.
  2. Restart every worker (PHP-FPM, Apache, FrankenPHP) so the new version actually runs. php -v on the command line only shows the CLI version, not necessarily the one behind the web server.
  3. Rebuild and redeploy container images, even if the code has not changed.
  4. If you use rpms.remirepo.net: the PHP team recommends switching to distribution packages or building from source, because the repository did not have the updates right away.

If you cannot update right away

The PHP team lists settings that block individual attack paths. They explicitly do not make an installation safe and only bridge the time until the update:

  • Set session.upload_progress.enabled=0 in php.ini or the FPM pool (not via ini_set() or .user.ini) and restart every worker.
  • On PHP 8.5, also set fatal_error_backtraces=0.
  • Keep post_max_size low (8M without file uploads, 32M otherwise) and limit request sizes at the web server or proxy.

PHP 8.1 and older

PHP 8.1 and older no longer receive updates from the PHP project. Given the severity, the PHP team still published minimal patches for 7.4, 8.0 and 8.1 this time, but only as source code to build yourself. Some distributions and LTS vendors ship backports.

That is an exception you cannot count on next time. Now is a good moment to plan the migration to a supported version. PHP 8.2 also reaches end of life on 31 December 2026. The supported versions are listed on php.net/supported-versions.php.

Sources

]]> PHP and Symfony in October 2026: security updates, end of support and what's coming in November https://paulschell.com/en/blog/php-symfony-october-2026/ https://paulschell.com/en/blog/php-symfony-october-2026/ Fri, 23 Oct 2026 08:00:00 +0000 Paul Schell The monthly roundup: three Symfony vulnerabilities, the end of PHP 8.2, PHP 8.6 and Symfony 8.2 in November and what it means for existing projects. A busy month: besides the critical PHP vulnerability there were security updates for Symfony, several end-of-support dates are getting close, and PHP 8.6 and Symfony 8.2 arrive in November. Here is the overview and what it means for existing projects.

Security: update PHP and Symfony

First things first: since 21 October there are PHP updates fixing two critical remote code execution vulnerabilities (8.5.12, 8.4.27, 8.3.36, 8.2.35). The details are in a separate post.

On 15 October Symfony published three vulnerabilities that let a single crafted request take down a process:

  • HttpFoundation (CVE-2026-108082): a crafted Cache-Control header costs almost a second of CPU per request. Affects every application that handles HTTP requests.
  • Yaml (CVE-2026-109413): deeply nested inline YAML crashes the process. This includes #[MapRequestPayload] when the Yaml component is installed and the format is not restricted.
  • ExpressionLanguage (CVE-2026-109449): deeply nested expressions crash the process, for example via #[Assert\ExpressionSyntax].

Everything is fixed in the current patch releases 5.4.54, 6.4.48, 7.4.21 and 8.1.9. A composer update symfony/* within your current version is enough.

End of support in the coming months

  • 30 November 2026: Symfony 6.4 moves to security fixes only (until November 2027).
  • 31 December 2026: PHP 8.2 stops receiving security fixes.
  • 31 December 2026: PHP 8.4 moves to security fixes only (until the end of 2028).
  • 31 January 2027: Symfony 8.1 reaches end of life. Symfony 8.0 has been unsupported since July 2026.

Current dates are listed on php.net/supported-versions.php and symfony.com/releases.

New in November: PHP 8.6 and Symfony 8.2

PHP 8.6 is scheduled for 19 November 2026 and is available as a release candidate for testing. Symfony 8.2 follows at the end of November and is maintained until July 2027. From the Symfony blog of the last weeks:

  • A new JsonSchema component
  • Signed Messenger transports with secret rotation
  • Support for HTTP trailers
  • Safer HTML in translations

What it means for existing projects

  • If your project runs on PHP 8.2, now is the time to move to 8.3 or 8.4. Symfony 6.4 and 7.4 run on both.
  • Symfony 8.0 and 8.1 are short-lived releases. If you are on one of them, move to 8.2 by the end of January or deliberately stay on 7.4 LTS, which gets security fixes until November 2029.
  • Symfony 6.4 is safe until November 2027, but now is a calm moment to plan the move to 7.4 LTS. Fixing deprecations while still on 6.4 makes that step much smaller.
  • Nobody needs PHP 8.6 right away. Adding an 8.6 job to your CI is worth it, though, to see deprecations early.

Sources

]]>