Warning for website owners
PHP is under attack.
Your site could
be next.
If the security fixes have not been installed yet.
Two critical vulnerabilities could allow an attacker to run code on the server. An admin password may not be needed.
Cloudflare has already reported attack traffic. Waiting until your website stops loading means waiting for potential consequences.
Sources: PHP advisory and Cloudflare report.
What is already known
A snapshot of verified reports.
Each assessment links to its source.
CVE-2026-109618
CVE-2026-109619
AWS reports an attack attempt on 17 October; Cloudflare reports attack traffic.
AWS report ↗Fixes for the original two CVEs have been released. PHP’s new clarification on 23 October calls for a separate check of session settings.
Update information ↗Older websites without maintenance and custom PHP projects with an unknown update status deserve particular attention.
Which websites should check PHP first? ↓Attack attempts are not a count of successful breaches. This snapshot does not establish a global number of compromised websites. The figure ‘2 critical CVEs’ refers to the original PHP2Shell vulnerabilities; the additional clarification concerning CVE-2026-115560 is described separately.
Which websites should be checked first?
Risk depends on the PHP build, installed fixes and server configuration.
Built years ago — then forgotten
The developer no longer maintains the website, there is no system administrator, and nobody knows who updates PHP. Prioritise checking this website.
Custom-built PHP websites
Especially when old code depends on an older PHP version, the original developer is unavailable, and updates are delayed because of compatibility concerns.
Apache with mod_php
The PHP team identifies this mode as the highest risk: exploitation may begin before the website’s own code runs.
Details from the PHP developers ↗Unsupported PHP branches
Standard upstream support has ended for PHP 8.1 and older branches. Confirm any special vendor-provided security fixes separately.
VPS without administration
Renting a VPS or dedicated server without a management service? Find out who installs security patches: renting the server alone does not establish that they are installed.
WordPress, Magento and other PHP systems
The CMS and plugins may be up to date while PHP remains unchanged. The server runtime itself needs to be checked.
Even a new website or PHP-FPM setup needs a patch check. A WAF can reduce risk, but it does not replace updating PHP.
Sources: PHP advisory, supported versions, Cloudflare guidance. Missing maintenance and delayed updates are reasons to prioritise a check, not evidence of a breach.
PHP2Shell: key developments
Major developments first. Open a report or the history for details.
PHP warned of a rare risk in session handling
On 23 October, the PHP team clarified that a rare combination of session settings and application code can allow an attacker to execute code. Until the next scheduled fix, session.upload_progress.enabled=0 is recommended. Keep this measure in place if it has already been applied. Applications that do not change the session serialization handler at runtime may leave the feature enabled. A full advisory for CVE-2026-115560 is expected with the next release.
PHP clarification of 23 October ↗Cloudflare: protection against the new vulnerability depends on PHP configuration
Read more
In its October 23 update, Cloudflare stated that CVE-2026-115560 also affects PHP 8.5.12 with fixes for the original PHP2Shell vulnerabilities; a fix is expected in the next regular release. According to PHP’s clarification, the scenario is possible only with an unusual combination of configuration and application code. Cloudflare says it protects against known exploit attempts when the default upload progress field name is used. If session.upload_progress.name has been changed, this rule does not cover the attack. WAF does not replace fixes and configuration checks.
Cloudflare’s original report ↗Wikimedia partially restored Cloud VPS; PHP restrictions remain
Read more
According to Wikimedia’s status update of October 23 at 14:43 UTC, selected Cloud VPS projects are available again, but many remain offline. Toolforge offers non-PHP tools and pre-built images with patched PHP 8.4; PHP images from Build Service are still blocked. Tools using PHP 7.4 or older must move to a newer version. This is a phased recovery after precautionary shutdowns, not a report of a confirmed breach.
Wikimedia status report ↗CloudLinux updated ea-php; alt-php is also available for OS 7
Read more
In its October 23 update at 13:10 UTC, CloudLinux announced that ea-php packages for cPanel with PHP.net version numbers had reached stable repositories. Corresponding alt-php packages are now also available for CloudLinux OS 7. Previously installed packages with backported fixes already protect against the original two CVEs, even if the PHP version number is lower. This is a package update, not a new attack; ask your hosting provider to confirm the fixes for the exact build serving your website.
CloudLinux update status ↗Earlier reports4
AWS identified an attack attempt four days before PHP2Shell disclosure
Amazon Threat Intelligence reports a PHP2Shell exploitation attempt on 17 October in its MadPot honeypot network, four days before the vulnerabilities were disclosed. The company has not established whether these attempts would have succeeded on real-world systems and recommends investigating events from at least 17 October.
AWS research ↗Prowise: two services were still being restored after PHP2Shell
In its 22 October report, Prowise said work to restore Prowise Learn and Prowise Account was still ongoing. Their return was expected early the following week, after verification. The company said the shutdowns were precautionary and it had found no indications of compromise. This is the status described in the 22 October publication, not confirmation of a current outage.
Prowise report ↗PHP released emergency security fixes
Two CVEs could allow unauthenticated code execution. The PHP team urges users to install the fixes; Apache with mod_php is identified as the highest-risk setup.
Official PHP advisory ↗Older Ubuntu releases have fixes through support programmes
Advisory USN-8948-2 complements the fixes for newer Ubuntu releases with packages for Ubuntu 14.04, 16.04, 18.04 and 20.04. Availability depends on the support programme: Ubuntu Pro, with the Legacy Support add-on for some older releases. Verify protection using the vendor package, not just the PHP version number.
Ubuntu advisory USN-8948-2 ↗
Checked on October 23, 2026. Card dates refer to source publication or updates, not necessarily to the event date. AWS described the October 17 attack attempt on October 21. Wikimedia’s status follows its October 23 update at 14:43 UTC; CloudLinux follows the 13:10 UTC update; Prowise follows its October 22 notice. PHP’s clarification and Cloudflare’s October 23 update concern CVE-2026-115560 under an unusual combination of configuration and code; no severity score is established here.
The problem goes deeper
than a password
or a plugin.
PHP is the server runtime behind many web applications. The fix must reach the PHP installation that actually serves your website.
- Updating WordPress alone is not enough
Updating the CMS and plugins does not itself apply PHP security fixes.
- A firewall does not remove the need to update
A WAF reduces exposure to known attack methods. The PHP patch is still required.
- The risk may not be visible from outside
A website address alone often cannot reveal the PHP build or installed fixes. An undisclosed version does not mean the site is secure.
Share this information with your administrator or hosting provider
Who updates PHP?
Contact your administrator or hosting provider. Find out who is responsible for your website’s server runtime.
Are both CVEs fixed?
Ask for confirmation that the PHP build serving your website includes the fixes, taking vendor patches into account.
Have the fixes taken effect?
Ask the administrator to check the running PHP processes and the website’s main functions after installing the patches.
Ready-to-send message
Please check whether CVE-2026-109618 and CVE-2026-109619 are fixed in the PHP installation serving our website. Confirm the installed build, including vendor patches, and that the fixes have taken effect in the running PHP processes.
Patched releases listed in the PHP advisory of 21 October. For distribution packages, verify vendor patches; a version number alone is not conclusive.
Frequently asked questions
The website works. Does that mean it is secure?
No. A vulnerable website can load normally. The installed PHP build and applied security fixes need to be checked.
The browser shows an HTTPS padlock. Is that not enough?
HTTPS protects the connection to the website. It does not, by itself, confirm that the server software has been patched.
Can you assess the risk from a website address alone?
Sometimes there are useful clues, but a reliable assessment often needs information from the administrator or hosting provider. An undisclosed version is not evidence that there is no risk.
Does a service outage mean it was hacked?
Not necessarily. An operator may restrict a service as a precaution while installing fixes. A confirmed breach is a separate fact.
We can help establish
whether there is a risk.
We will review the available information about your website, clarify what to check with your hosting provider and help assess its PHP status. If a risk is confirmed, we can carry out remediation remotely. With your authorisation, we can contact your hosting provider, request patch information and help coordinate an update.
Risk assessment
Per website. We will check the available information and explain what we could confirm.
Remediation if a risk is found
Per website, remotely. We will agree the required work before starting.
If the website address does not provide enough information, details from the administrator or hosting provider will be needed. Payment arrangements are agreed before work starts.
Discuss a risk assessment
Risk assessment — 5 000 ₸ per website.
Send your website address and briefly describe the situation. With your authorisation, we can contact your hosting provider to clarify the PHP status.
Email: info@kogut.academy
Do not send passwords with your initial enquiry.
Contacts
Need help checking your website? Message us on WhatsApp or by email. For your initial enquiry, a website address and a description of the situation are enough.
Phone
+7 727 312 2808Kogut.academy’s general contact number.
+7 727 312 2808
Send a link to your website. Do not send passwords.
Email and address
info@kogut.academy50 Kazybek Bi Street, AlmatyVisits by appointment.
Kogut.academy contacts · contact page on the main website ↗