PHP2Shell: what pharma and healthcare marketing teams need to check
In short. On 21 October 2026 the PHP project released updates for two critical flaws, CVE-2026-109618 and CVE-2026-109619. They can let an attacker without a login run code on a server that runs PHP. Only updating PHP on the server fully closes them. Marketing teams are affected wherever a website, microsite, portal or form runs on PHP, so each host and agency should now confirm in writing that PHP is updated and restarted.
Status on 24 October 2026
- Fixes: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October. PHP 8.1 and older no longer receive updates from the PHP project, which did publish minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves.
- Attacks: reports differ. The security firm watchTowr has observed exploitation since 21 October. The Canadian Cyber Centre’s alert, updated on 23 October, says no active exploitation was being identified at that point and that this can change quickly. It cites open-source reporting that a proof of concept is available. CISA’s catalogue of known exploited vulnerabilities lists neither flaw.
- Follow-up: on 23 October PHP published an informational advisory on a further route to code execution (CVE-2026-115560) that it calls unlikely in practice. It suggests switching off the session upload progress feature until the next regular bugfix release.
This page is written from the marketing side: what to ask for and whom to ask. The technical work belongs with IT, the hosting provider or the agency.
What happened
PHP is the programming language behind WordPress and many other content management systems and web shops. On 20 October the PHP project gave advance notice of a critical security release for 21 October and rated both flaws 9.2 out of 10 on the CVSS v4.0 scale. According to watchTowr, details of the flaws had leaked before the planned disclosure date. The updates came out on 21 October. Warnings followed from Health-ISAC, the information-sharing community of the health sector, from the UK National Cyber Security Centre and from the Canadian Cyber Centre. All three urge organisations to update quickly and to find out where they are exposed.
The PHP project says all installations that serve web requests are at risk until they are updated. It rates the risk highest for Apache with mod_php, where a demonstrated attack needs no login and runs before the site’s own code.
Why marketing teams are affected
Code that runs on a server can read what the server can read and change what it shows. On a marketing site that means form submissions, enquiry databases and the pages visitors see. In healthcare, enquiries and registrations can contain health information, which GDPR treats as a special category of personal data (Article 9). A site that goes offline for updating also affects every campaign that sends paid traffic to it.
In most companies marketing does not patch servers. It does own the websites, the agency relationships and the data they collect, so it has to ask for the answers.
Where PHP hides in marketing
These are the places where marketing teams usually find PHP, and what to ask for in each.
| Where PHP often sits | What to ask for |
|---|---|
| Company and country websites on WordPress, Drupal or another CMS | The PHP version or vendor build, the update date and whether PHP was restarted |
| Campaign microsites and landing pages built by agencies | Where each page is hosted, who updates it and whether it is still needed |
| Patient and HCP portals, registration and login areas | The same confirmation from the platform vendor, and the processing agreement that covers it |
| Contact, newsletter and download forms | Which script receives the data, where it is stored and who can see it |
| Online shops, booking tools and other systems hosted by vendors | A written statement from the vendor on its PHP use and patching status |
| Self-hosted marketing tools such as analytics, email or survey software | Whether it runs on PHP and who owns its updates |
| Old campaign sites and subdomains that are still online | Retire them, or move them to a host that is kept up to date |
What to check now
- List every website, microsite, portal, form and marketing tool, including agency-hosted and old campaign sites. Start with those reachable from the internet.
- Write down who hosts and who updates each one. A site without a named owner is a finding in itself.
- Ask each host or agency to confirm in writing the PHP version or vendor build, the date of the update and that PHP was restarted. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Hosting that installs PHP from distribution packages can keep the old version number, so ask for the package changelog or build date.
- Treat answers such as “we have a firewall” or “we changed some settings” as incomplete. The PHP project states that only an update is a complete solution and that the settings it lists reduce exposure without making an installation safe.
- For anything that cannot be updated now, agree with IT whether to take it offline or restrict access, and pause paid traffic to pages that will be unavailable.
- Ask IT or the host to check server logs from 20 October for signs of misuse. If something turns up, treat it as an incident and involve your security team and data protection officer.
- Plan the move for PHP 8.1 and older, which receive no updates from the PHP project, and for PHP 8.2, whose security support ends on 31 December 2026.
What the rules say
General information, not legal advice.
GDPR (Regulation (EU) 2016/679). Article 32 requires controllers and processors to apply security measures that fit the risk, including regular testing. Under Article 28 a controller may use only processors that give sufficient guarantees, and the processor has to assist with security and breach duties. If personal data is compromised, Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. A processor must tell the controller without undue delay. Article 34 adds a duty to inform the people concerned when the risk to them is high.
NIS2 (Directive (EU) 2022/2555). It covers medium-sized and larger organisations in listed sectors, among them healthcare providers, research and manufacture of medicines, and manufacture of medical devices. Article 21 requires risk management measures that include supply chain security and vulnerability handling. For a significant incident, Article 23 requires an early warning within 24 hours and a notification within 72 hours. National law sets the details.
HIPAA (United States). The Security Rule requires covered entities and their business associates to carry out a risk analysis and risk management for protected health information. After a breach of unsecured protected health information, covered entities must notify the individuals without unreasonable delay and no later than 60 calendar days after discovery (164.404). Business associates must notify the covered entity within the same limit (164.410).
Questions and answers
Is WordPress affected?
The flaws are in PHP, the language WordPress runs on, not in WordPress itself. A WordPress site is exposed when the PHP on its server is not updated, whatever the WordPress version. Updating WordPress or its plugins does not close the flaws, and Bitsight says a web application firewall does not either.
Does a firewall protect us?
The PHP project states that only an update is a complete solution and that other measures reduce exposure to specific attack paths without making an installation safe. A firewall can add a layer in front of the site, but it does not replace the update.
The server shows an old version number. Is it still unpatched?
Not necessarily. Servers that take PHP from Linux distribution packages can carry the fix without changing the version number, so ask for the package changelog or the vendor’s statement. Kaspersky makes the same point. A fix works only after PHP is restarted.
What if the site runs PHP 7.4 or 8.1?
These branches no longer receive updates from the PHP project. For 7.4, 8.0 and 8.1 it did publish minimal source backports, meant for people who build PHP themselves or have no long-term support vendor. Some distributions and long-term support vendors provide backported fixes too. Otherwise the site has to move to a supported version. Bitsight found that only about a third of the PHP instances whose version it could identify run a branch covered by the October update, and that 7.4 is the most common branch by far.
Do we have to report this?
Not for the vulnerability alone. A duty to notify arises if personal data was compromised or, under NIS2, if a significant incident occurred, and the periods start when you become aware of it. Involve your data protection officer and legal counsel early.
Sources
- PHP project: advance notice of 20 October 2026, security advisory of 21 October 2026 and informational advisory of 23 October 2026 on session upload progress
- GitHub advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- PHP project: supported versions
- UK National Cyber Security Centre: Critical security issue affecting PHP, 21 October 2026
- Canadian Centre for Cyber Security: alert AL26-026, updated 23 October 2026
- Health-ISAC: bulletin on the AHA site, updated 21 October 2026
- CISA: Known Exploited Vulnerabilities catalog, checked on 24 October 2026
- watchTowr: PHP2Shell FAQ: CVE-2026-109618 & CVE-2026-109619 Fixes, updated 23 October 2026
- Bitsight: CVE-2026-109618, CVE-2026-109619 PHP2Shell: Vuln Details, 21 October 2026
- Kaspersky: PHP2Shell: How to Protect Your Server, 21 October 2026
Update log
- 24 October 2026: first version, checked against the sources above.
I work with healthcare and pharma companies on digital marketing, CRM and AI adoption. See Working together on the home page.