Web security
On 21 October 2026 the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on php.net. They close two critical flaws in the PHP core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2: under certain conditions they allow code to be run on the server without logging in. The US agency CISA has listed both as actively exploited since 26 October, and Germany’s BSI has issued a warning. Online shops on Shopware, Magento or WooCommerce, websites on TYPO3 or WordPress and web applications built on PHP, Symfony or Laminas are all affected, because the flaw sits in PHP itself, not in the shop. Sharpness Solutions GmbH in Oldenburg checks the patch level, updates PHP along with its extensions, hardens server and application and runs systems on its own servers in Germany.
A security release like October’s rarely meets a tidy situation. Usually one piece of information is missing: which version is running, who looks after the server, which extension is holding up the change. Six starting points come up again and again. What they have in common: the risk lies less in the flaw itself than in the question of who closes it.
An agency built the shop, the host provides the server, and the PHP version is not written down anywhere. On top of that, distributions often keep their version number even when the package has been patched. Looking only at the number easily leads to the wrong conclusion — in either direction.
Shopware, TYPO3 or WordPress are on the latest release, and the system is still vulnerable. The October flaws sit in the PHP runtime, not in the application. Updating the shop or CMS changes nothing about that; PHP itself has to be patched.
The PHP project provides security fixes for PHP 8.2 only until 31 December 2026. The October flaws were closed in 8.2.35; the next one will not be closed on this line. Many systems run on 8.2 because it is their minimum version.
These lines no longer receive support from the PHP project. This time, as an exception, the PHP security team provided source-code fixes; ready-made packages only come through distributions. Nobody should count on that exception; the system needs a plan for the version change.
A Shopware plugin, a TYPO3 extension or a WordPress theme is not cleared for the new PHP version, and with Magento the Magento version decides which PHP line is possible at all. A package update then turns into a small project with a test system and a defined order.
Unknown files, a new administrator account, redirects that only visitors from Google see, or an email from the host about spam being sent. At that point the patch is no longer the first step; securing the evidence is. There is a separate, fixed procedure for this case.
On 20 October 2026 the PHP project announced on php.net a security release for the following day, covering two critical vulnerabilities, both rated 9.2 under CVSS v4.0. On 21 October PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were published, pure security releases without new features. They fix CVE-2026-109618 and CVE-2026-109619, two bugs in the core of the PHP runtime. One concerns how PHP handles running out of memory during a request, the other internal state that can be left over after a request in the same process. In both cases, under certain conditions, this can lead to foreign code running with the privileges of the web server process. Neither a login nor any action by a user is needed; the rating classes the attack complexity as high.
According to the php.net security notice, every PHP installation that serves web requests is affected, whether through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed; the risk is highest with mod_php. All releases below the versions named are vulnerable, so 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. The PHP project states that there are no complete mitigations and that updating is the only safe choice. The interim settings it lists reduce the risk only in part and explicitly do not make an installation safe. The pre-release PHP 8.6.0 RC4 contains the fixes as well; for production use, 8.6 is not yet an option.
As for the timeline: Amazon Threat Intelligence observed a first exploitation attempt as early as 17 October, four days before publication; whether any attempts succeeded, the report left open. Germany’s Federal Office for Information Security (BSI) published cyber security warning 2026-297981-1032 and advises applying the patches without delay. On 26 October the US agency CISA added both vulnerabilities to its catalogue of known exploited vulnerabilities. On its situation page the BSI reports attack attempts in the tens of millions, but so far no large-scale exploitation in Germany and no successful attacks with data leaving the systems. That is the sober picture: a serious, well-documented risk with a clear answer. If you are on a patched version, this item is done. If you do not know, now is the time to check.
The PHP project supports each version actively for two years with bug and security fixes, followed by two more years of critical security fixes only, as needed. As of the end of October 2026 that means: PHP 8.5 and 8.4 are in active support — 8.4 actively until the end of 2026 and with security fixes until 31 December 2028, 8.5 actively until the end of 2027 and with security fixes until 31 December 2029. PHP 8.3 now receives security fixes only, until 31 December 2027. PHP 8.2 receives security fixes only until 31 December 2026; from 1 January 2027 the PHP project will provide none. PHP 8.1 reached its end of life on 31 December 2025, 8.0 in November 2023 and 7.4 in November 2022.
For the older lines, October is an exception: because of the severity of the flaws, the PHP security team provided minimal source-code fixes for 7.4, 8.0 and 8.1 — for operators who compile PHP themselves. Ready-made packages are only available through Linux distributions or long-term support vendors; Ubuntu, for example, also shipped an update for 22.04 with PHP 8.1, and for older LTS releases via ESM. Nobody should count on this exception being repeated. A shop or CMS on PHP 8.1 or older runs without support from the PHP project, and the next flaw may hit it without a fix. For systems like these, the task is not the next package update but the change of version.
What this means for the major systems: Shopware 6.7 requires PHP 8.2 or newer and recommends 8.4. TYPO3 v14 and v13 LTS run on PHP 8.2 to 8.5. WordPress recommends PHP 8.3 or newer; it still runs from 7.4, but that version is out of support. With Magento Open Source and Adobe Commerce, the PHP version depends on the Magento version: 2.4.9 only with PHP 8.5, 2.4.8 with 8.4 or 8.3, 2.4.7 with 8.3 or 8.2, 2.4.6 with 8.2 or 8.1. A minimum version is not a recommendation for operation. Anyone running PHP 8.2 today because the system allows it will be without security fixes in two months — and should plan the move to 8.3, 8.4 or 8.5 now, not in December.
The first step is an inventory, not a guess. Which PHP version runs for the web, which on the command line, which in cron jobs and workers? Where does PHP come from: the distribution’s packages, a third-party repository, a container image or a hosting provider’s offering? One point matters here: distributions often keep their old version number and are patched nonetheless. Ubuntu 24.04 still ships PHP as 8.3.6; the fix is in package release 8.3.6-0ubuntu0.24.04.13. Debian 12 provided php8.2 8.2.35-1~deb12u1, Debian 13 php8.4 8.4.27-1~deb13u1. The patch level is therefore read from the package, not from the PHP version number. In Docker environments this includes rebuilding the images and actually restarting the containers.
If only a package update within the same PHP line is due, that is usually a maintenance window: apply it, restart PHP-FPM or the web server, check that the new release is actually being served. Changing the line, for instance from 8.2 to 8.4, is a different matter. Then every component has to come along: Shopware plugins and apps, Magento modules, TYPO3 extensions, WordPress and WooCommerce plugins and themes, plus custom extensions and Composer dependencies. With Magento, the change may require an update of Magento itself, because each version supports only certain PHP lines. We check this beforehand against the vendors’ system requirements and the information for each extension, and we test on a staging system with a copy of the live data before switching live operation over.
For web applications and custom software on PHP, Symfony or Laminas, the same principle applies with different tools. We read composer.json and composer.lock, check the dependencies for known vulnerabilities and for support of the target PHP version, and look through the code for outdated language constructs or removed functions. Automated tests help here; where there are none, we write some for the most important processes before the version changes. Tools alongside the shop are part of this too: the makers of Matomo point out explicitly that a Matomo update does not fix the PHP flaws. The result is a plan with an order of steps and the effort for each, not a gut feeling.
A patched PHP closes this flaw, not the next one. Hardening reduces the attack surface so that a future vulnerability has less to hit. At server level that means: a current operating system, only the services that are needed, administrative access by key and not reachable for everyone. The web server delivers only what is meant to be public; configuration files, backup copies and version control sit outside the web root or are blocked. PHP runs with a configuration that suits the system: no error output to visitors, limits on execution time, uploads and request size as required, and no PHP extensions that nobody uses. Each application gets its own process and user, so that a fault in one system does not reach the next.
Permissions decide how far a fault can reach. The web server process may write where the application has to write — cache, uploads, logs — and nowhere else. Database users have only the rights of their application, interfaces their own narrowly scoped credentials. Administrative logins in the shop and CMS back end get a second factor, and orphaned accounts are removed. Add to that updates at fixed intervals for operating system, PHP, database, shop or CMS core and extensions, tested and with a way back. Backups are kept separate from the production system, in several versions, and restores are rehearsed. Monitoring reports outages, unusual error rates and unexpected changes to files before customers do.
A web application firewall can sit in front of the server, with us usually Cloudflare. It filters known attack patterns, slows down automated traffic, protects admin areas and logins and absorbs mass traffic before it reaches the server. For Shopware and TYPO3, separate pages describe how cache rules, exceptions for payment providers and interfaces and the shielding of the server fit together. A WAF is an additional line of defence, not a substitute for patches: the PHP project has named no complete mitigation for the flaws in the PHP runtime, and a firewall rule can only catch what it recognises as a pattern. The order therefore stays the same: patched versions first, then hardening, then the firewall in front.
If there are signs that a system has already been compromised — unfamiliar redirects, unknown files or accounts, spam being sent, a block by the host — an update alone is no longer the answer. What counts then is the order: secure, understand, restore, close. Our page on emergency help for hacked websites describes how we go about it. For the October flaws there is one more point: an attack would run with the privileges of the web server process. That is why, for systems that were reachable unpatched during the period in question, we examine access logs, files and accounts specifically rather than just applying the patch afterwards. If personal data may be affected, we supply the technical basis for assessing the notification duty under Article 33 GDPR; the legal assessment remains with you.
With us, ongoing protection is part of operation and maintenance under a service level agreement. The BASIC, STANDARD and ADVANCED tiers stand for 24, 8 or 4 hours’ response time, each booked for a year. We bill the work by effort or within the agreed scope of hours; the hourly rate is tiered by time — weekdays within working hours, weekdays outside them, weekends and public holidays. On-call cover outside business hours is available only with an SLA. Without an agreement we deal with requests within 48 hours during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). With an SLA, a security release like October’s is no longer a question of who feels responsible, but a scheduled appointment.
You have the most control when the system runs on our own servers: Proxmox VE clusters in the Hetzner data centre in Falkenstein, Germany, with Docker, monitoring, backups and staging. The patch level of operating system and PHP is then in our hands, and nobody has to ask a host first which packages are installed. We run shops such as the B2B shop of M&S Armaturen on these servers. If your system runs with another provider, we check the patch level there, implement what the environment allows and say clearly where it does not. Sharpness has existed since 1999, with more than 250 projects since then and IT liability insurance in place. The domain is always registered in your name, and the code sits in a Git repository that belongs to you.
Process
Send us your system, the PHP version if you know it, and who runs the server. You get an initial assessment with no obligation: whether your system is affected by the October flaws, whether a package update is enough or a version change is due, and what to do first. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). We work remotely across Germany, with meetings in Oldenburg and the north-west by arrangement.
You tell us what you know: shop, CMS or application, PHP version, who runs the server, whether anything looks odd. We tell you what comes first and whether this is a package update, a version change or an incident — with no obligation.
We read PHP version and package release for web, command line and workers and check shop or CMS core, extensions, dependencies, access, permissions and backups. The result is a prioritised list: what is due now, what in the coming weeks and what can wait.
Where the PHP line can stay, we apply the security release or the patched distribution package, restart the services and check that the new release is actually being served. If there are signs of an incident, we first secure files, database and logs.
If a change of PHP line is due, for instance away from 8.2, we test shop, CMS or application with all extensions on a staging system with a copy of the live data. The switch happens in the agreed maintenance window, with a backup beforehand and a way back.
Server, web server and PHP configuration, file permissions, database and administrative access with a second factor, backups with rehearsed restores and monitoring. On request, a firewall in front with Cloudflare, tuned to payment providers and interfaces.
After that, maintenance under a service level agreement: security releases and updates at fixed intervals, monitoring, backup checks and a clear procedure for emergencies — on our own servers in Germany, with the patch level in our hands.
Projects on this system
A selection — not the full client list.
Two critical flaws in the PHP core: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0. Under certain conditions they allow code to be run with the privileges of the web server process, without logging in and without any action by a user. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published on 21 October 2026 on php.net. The PHP project states that there are no complete mitigations and that updating is the only safe choice. The US agency CISA has listed both flaws as actively exploited since 26 October, and the German BSI has issued cyber security warning 2026-297981-1032.
Yes, if PHP serves web requests there and has not yet been brought to a patched release. According to php.net, every PHP installation that serves web requests is affected — through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. Vulnerable are 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12, and older lines in any case unless they have received a fix through the distribution. This applies to Shopware, Magento and WooCommerce just as much as to TYPO3, WordPress and custom applications, because the flaw sits in the runtime. Whether your system is patched can usually be established quickly from version and package release.
No. The October flaws sit in the PHP runtime, not in Shopware, Magento, TYPO3 or WordPress. Updating the shop or CMS changes nothing about PHP; PHP itself has to be patched, meaning the version the server executes. php.net, the BSI and also the makers of Matomo, for example, point this out explicitly. The reverse is true as well: a current PHP does not replace updates of the shop or CMS core and its extensions, which have flaws and fixes of their own. Both belong together in a fixed maintenance rhythm. We therefore check and update both levels and make sure every extension fits the chosen PHP version.
From the package release, not from the version number alone. If you use PHP as released by the PHP project, you need at least 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions, by contrast, often keep their version number and ship the fix as a new package release: Ubuntu 24.04, for example, still as PHP 8.3.6, patched from package 8.3.6-0ubuntu0.24.04.13; Debian 12 with php8.2 8.2.35-1~deb12u1, Debian 13 with php8.4 8.4.27-1~deb13u1. On shared hosting the host decides, so a specific question about the patch level helps. It also matters that PHP-FPM or the web server was restarted after the update — otherwise the old release keeps running.
From 1 January 2027 the PHP project will no longer provide security fixes for 8.2. The October flaws were still closed with 8.2.35; the next flaw will not be closed on this line. Many systems are on 8.2 because it is their minimum version: Shopware 6.7, TYPO3 v13 and v14 and Magento 2.4.6 and 2.4.7 allow it. A minimum version does not mean that the system can be run securely on it in the long term, though. Moving to 8.3, 8.4 or 8.5 requires testing every extension and sometimes an update of the shop or CMS. Two months is tight for that, but enough if planning starts now.
Plan the version change and, until then, close the October flaws by whatever route exists for your environment. PHP 8.1 has been without support from the PHP project since 31 December 2025, 8.0 since November 2023 and 7.4 since November 2022. As an exception, the PHP security team provided minimal source-code fixes for 7.4, 8.0 and 8.1 this time; ready-made packages only come through distributions or long-term support vendors. With the next flaw, that exception may not be made. A system at this level therefore needs a plan for PHP 8.3 or newer, usually together with an update of the shop, CMS or framework.
The newest line that your system and all its extensions support — today usually PHP 8.4 or 8.5. Shopware 6.7 requires at least 8.2 and recommends 8.4. TYPO3 v14 and v13 LTS run on 8.2 to 8.5. WordPress recommends 8.3 or newer. With Magento Open Source and Adobe Commerce, the version determines the PHP line: 2.4.9 only with 8.5, 2.4.8 with 8.4 or 8.3, 2.4.7 with 8.3 or 8.2. Because support ends at the close of 2026, we no longer recommend 8.2 as a target. In the end the extensions decide: a plugin that does not support the target version sets the timetable.
An inventory of runtime, application and operation, with a prioritised list of measures as the result. We check PHP version and patch level, operating system and services, web server and PHP configuration, shop or CMS core, extensions and Composer dependencies for known vulnerabilities, plus file permissions, access and the rights attached to it, backups and monitoring. For online shops the payment path is included: card data should never touch the server but go straight to the payment service provider. The list says what is due now, what in the coming weeks and what can wait, each with the effort per measure. You decide what gets implemented.
Partly, but it does not replace the update. A web application firewall in front of the server filters known attack patterns, slows down automated traffic and absorbs mass traffic before it reaches the server. Against a flaw in the PHP runtime it helps only as far as it recognises the attack as a pattern. The PHP project names no complete mitigation for the October flaws; even the interim settings it describes explicitly do not make an installation safe. Cloudflare makes sense as an additional line after patching and hardening. Separate pages describe how we set it up for Shopware and TYPO3 without locking out payment providers and interfaces.
Delete nothing, preserve the evidence and call us. Put the site into maintenance mode or have the host take it offline temporarily, and from a clean device change the passwords for your email account and your hosting customer account. Removing suspicious files destroys evidence and usually does not close the door. With the October flaws, an attack would run with the privileges of the web server process; patching PHP afterwards is then not enough. Our page on emergency help for hacked websites describes the full procedure. Phone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET); outside these hours via the form.
Yes. We check the patch level on third-party hosting and servers as well, implement what the environment allows and say clearly where it sets limits. On shared hosting, the host decides on PHP version and patch level; there we clarify with the host whether the October fixes have been applied and set the appropriate PHP line in the control panel, as far as the host permits. On your own servers or VMs we take care of package updates, configuration and hardening ourselves. You have the most control when the system runs on our own servers in Germany: patch level, backups and monitoring are then in one hand, and a security release is applied without detours.
Ongoing protection is part of our maintenance under a service level agreement: BASIC with 24, STANDARD with 8 and ADVANCED with 4 hours’ response time, each booked for a year. We bill the work by effort or within the agreed scope of hours; on-call cover outside business hours is available only with an SLA. Without an agreement we deal with requests within 48 hours during our business hours of Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET). The scope includes security releases and updates at fixed intervals, backup checks and monitoring. The code is yours: it sits in a Git repository that belongs to you, and the domain is always registered in your name.
Enquiry
A few details are enough: which system, which PHP version, where it runs and what you have noticed. We come back with questions and an initial assessment — with no obligation. Please do not send passwords or access credentials through this form.