On 21 October 2026 the PHP project closed two critical security vulnerabilities. They allow attackers to execute their own program code on a web server without logging in. Many real-estate providers’ websites run on WordPress, Joomla, TYPO3 or Contao, and all of these systems need PHP. Here you can find out what happened, how to determine whether your site is affected, and what you should do now.
What happened
PHP is the programming language that runs a large portion of all websites on the server. On 20 October 2026 the PHP security team announced an urgent update. It rated both vulnerabilities 9,2 out of 10 points (CVSS 4.0) [S2]. The updates were released on 21 October together with a security advisory [S1]:
- CVE-2026-109618: If PHP runs out of memory, it can abort a request while it is still being processed. During the subsequent cleanup, half-finished data can be treated as valid [S1][S6].
- CVE-2026-109619: Data from a previous request can remain in memory after the memory has already been freed. A later request to the same server process can reuse it [S1][S3].
In the worst case an attacker can execute their own code with the rights of the webserver. Via one of the two vulnerabilities they can also read memory contents [S3]. Anyone who gains such access to a server can, for example, alter content or place malware (editorial explanation).
All common ways of integrating PHP on the server are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed [S1]. Which type runs for you is known by your host. According to the PHP project the greatest danger is with Apache using mod_php. There a single request without authentication is enough and the attack succeeds before the actual website is even loaded [S1].
The two vulnerabilities are also called “PHP2Shell”. Amazon detected an initial attack attempt against one of its honeypots on 17 October, i.e. before disclosure. According to Amazon the vulnerabilities have been widely exploited since the day of the updates [S5][S9]. The PHP project itself did not provide details on this [S3]. The UK cybersecurity authority NCSC advises: if you cannot update immediately and cannot set any interim mitigations, consider taking the system offline until you can do so [S4].
What happened in Austria and Germany
In Austria CERT.at disseminated the warning, coordinated with the new Federal Office for Cybersecurity [S3][S8]. The websites of the University of Vienna, TU Wien and the NÖN were temporarily unavailable [S8]. The Austrian cloud provider Anexia confirmed attack attempts on websites hosted with them [S8]. According to Cloudflare the number of attack attempts rose from a few thousand to millions after disclosure [S8].
In Germany the Federal Office for Information Security (BSI) issued a cybersecurity warning [S10]. Several municipalities, authorities, universities and hospitals took their websites offline as a precaution, including the city of Mainz and Berlin’s Charité [S11][S12].
Which versions are secure
The vulnerabilities are fixed in these versions [S1][S3]:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
- PHP 8.1 and older (also 8.0 and 7.x): no more official updates
PHP 8.1 and older versions no longer receive updates from the PHP project. For 7.4, 8.0 and 8.1 there are only minimal emergency fixes for specialists who build PHP themselves from source. Some Linux distributions supply their own fixes for older versions [S1][S3]. If your site still runs on PHP 8.1 or older, moving to a supported version is the safe course of action [S3]. PHP 8.2 will only receive security updates until 31 December 2026 [S1][S3].
Important: Linux distributions and long-term vendors received the fixes in advance and are applying them in some cases without changing the version number [S1][S3]. A lower version number therefore does not automatically mean that your site is unprotected. You can only be sure once your host confirms the update.
Am I affected? How to find out
You can be affected if your website runs on PHP. It is protected if one of the versions listed above is in use or your host confirms that the patch has been applied. Who checks this depends on who operates your site (editorial recommendation):
- Hosted complete solution (site builder or a provider website of your real-estate software vendor): the operator is responsible for the server here. Ask whether the update has been applied.
- Own webhosting with WordPress, Joomla, TYPO3 or Contao: You can usually see the PHP version in your hoster’s customer area, often under “PHP-Version” or “PHP-Einstellungen”.
- With WordPress the PHP version is also shown in the dashboard under Tools → Site Health → Report, in the Server section [S7]. On the same page WordPress also warns about very old PHP versions [S7]. Whether the October update has been applied cannot be determined from that warning.
- Web agency or own server: Ask in writing which PHP version is running and when the update was applied.
Because distributions and long-term providers received the fixes in advance [S1], many hosters were able to update quickly. Whether this has happened on your server, however, you only know after asking.
What you should do now
- Have the update applied. Only an update to one of the versions named above fully fixes both vulnerabilities [S1][S3]. Hosters usually apply the security update within a version series. You can usually only change the version series yourself in the customer area, for example from 8.1 to 8.3 (editorial recommendation).
- Replace old PHP versions. Move from PHP 8.1 or older to a supported version. Check with your agency beforehand whether theme and extensions work with it, and make a backup (editorial recommendation).
- If it cannot be done immediately: The PHP project names transitional settings for the server, such as `session.upload_progress.enabled=0` and adjustments to memory and upload settings. They do not replace the update and should explicitly be handled by your hoster or agency [S1][S3]. If that is also not possible, consider taking the site offline until the update [S4].
- Have logs checked for intrusion traces. Since the vulnerabilities were already exploited before 21 October, your hoster or agency should check logs and files from 17 October for unusual changes [S4][S5].
- Don’t forget further updates. Keep your content-management system, themes and extensions up to date as well, preferably with automatic updates (editorial recommendation, cf. [S3]).
Typical mistakes (editorial recommendation)
- “My WordPress is up to date, so I’m safe.” WordPress updates do not update PHP. PHP runs on the server and is updated there.
- “The site is small, no one will attack it.” Such attacks are automated and scan the whole internet. Amazon saw first attacks on its bait systems a few hours after the updates (cf. [S5]).
- “I’ll just hide the error messages.” That does not protect you. Hiding errors is explicitly not sufficient according to the PHP project [S1][S3].
Template for the request to hoster or agency
Fictitious example for a short email:
Subject: PHP security update of 21.10.2026 for [Domain]
Hello, which PHP version is running on our website [Domain]? Has the security update of 21.10.2026 been applied, i.e. PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or the fix via your Linux distribution’s package? If PHP 8.1 or older is still running: by when can the site be switched to a supported version? Please also check whether there are any indications of an intrusion since 17.10.2026. Thank you!