For a CMO or head of marketing operations the question is which campaigns and journeys depend on that wiring, and whether they can keep running.
CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October, with a 29 October deadline for US federal agencies. The first successful exploitation in the wild was recorded on a honeypot running Apache with mod_php on PHP 8.4.26, one release below the fix and the configuration PHP rated highest risk (BleepingComputer). No compromise of a production system has been confirmed in the sources checked, and Palo Alto Networks Unit 42 withdrew an early claim linking an attack on a European government entity to PHP2Shell (The Hacker News). The Dutch NCSC, which had reported "first signals" of successful exploitation on 22 October, said a day later that exploitation is complicated and large-scale abuse less likely than first estimated (ANP). The residual vector CVE-2026-115560 still waits for PHP's next regular release; until then, keep session.upload_progress.enabled=0 (php.net). Managed hosts rolled out the fixed builds from 21 October, and at least one built the fix into the version its customers already run (more on that below). HubSpot and Adobe have published nothing, and no compromise of HubSpot, Marketo Engage or Adobe Journey Optimizer through this route has been reported. The scenarios below are possible consequences in customer implementations, and are labelled as such.
- 28 October 2026 CISA lists both CVEs as known exploited (26 October). First confirmed successful exploitation in the wild, on a honeypot (mod_php, PHP 8.4.26). No confirmed production compromise; Unit 42 withdrew its early claim. The Dutch NCSC lowered its estimate of large-scale abuse on 23 October. Status box rewritten. No confirmed platform compromise
- 23 October 2026 PHP's informational advisory for a residual vector, CVE-2026-115560: ini stopgap now, fix in the next regular release, no new version numbers. Wordfence: 74,000+ blocked attempts on WordPress sites, no confirmed compromise in its telemetry. CISA alert of 21 October noted; KEV still lists neither CVE. Status box and the closing paragraph of the PHP2Shell section updated. No confirmed platform compromise
- 22 October 2026, evening The Dutch NCSC reports the first signals of successful exploitation of PHP systems, organisations unnamed (NOS, 17:52 CEST). No marketing platform appears in any report seen. UK: 32 government services offline as a precaution, no confirmed compromise. Status box updated; nothing else changed. No confirmed platform compromise
- 22 October 2026, second update Corrections after review. Suspect credentials are revoked at once and reissued after the patch; the earlier wording could be read as waiting for the host. The NIS2 early warning is tied to the significant-incident threshold. The Journey Optimizer passage now covers what a custom action actually sends. Mautic is the best-known PHP marketing automation platform rather than the only one. Status and platform statements are bounded to the sources checked and the time of checking; neither CVE is in CISA's KEV catalogue. The Adobe Commerce paragraph stays, sourced to Adobe's own system requirements. No confirmed platform compromise
- 22 October 2026 Status after the hosting rollout. Added how to verify a fix that leaves the version number unchanged, what a supplier's "not vulnerable" means, the 17 October exploitation attempt reported by Amazon (the log-review window now starts there), a middle option between online and offline, a first-hand note and two new questions in the FAQ. Corrected the WAF answer: hosting platforms applied server-side protection. No confirmed platform compromise
- 21 October 2026 Initial publication, hours after PHP released the fixed versions. Exploitation attempts reported by Cloudflare and Patchstack; none observed by the Dutch NCSC or Huntress at the time of writing. No statement from HubSpot or Adobe. No confirmed platform compromise
What is the impact of PHP2Shell on marketing campaigns?
The impact depends on where PHP sits in the customer journey, and in a typical B2B journey that is the page the click lands on, the form, and whatever carries the submission into the platform. PHP runs almost 70% of websites (Cloudflare), so on most of the web that wiring is PHP. PHP's advisory describes a demonstrated exploit in which "an unauthenticated request can trigger the attack before any application code runs" (php.net). A landing page on a vulnerable host can be altered or taken offline however well its CMS is maintained.
| Where the problem sits | What marketing experiences | The immediate decision |
|---|---|---|
| Website or campaign landing page | Paid clicks and email clicks arrive at a page that is down or altered | Pause or redirect traffic to that destination |
| Form handler or CRM connector | Missing leads, delayed routing, submissions you cannot trust | Verify capture and routing before sending more traffic |
| Preference centre or consent sync | Customer choices never reach the sending platform, or arrive altered | Confirm affected programmes can still honour preferences |
| External API called by a journey | Failed calls, missing enrichment, responses a journey acts on blindly | Check the error handling, isolate the affected paths |
| PHP service holding integration credentials | Access to the platform within whatever the credential was allowed to do | Contain, then investigate platform-side activity |
| Editorial reading | The exposure is the wiring between platform and website, and the wiring rarely has an owner. | |
A site that is dark for an afternoon wastes paid clicks and nothing else. A compromised connector carries the problem into the contact database while email delivery continues as normal. Establish which rows apply before deciding how much to stop.
Is HubSpot affected by PHP2Shell?
HubSpot has published nothing on PHP2Shell, and nothing in the sources checked points at the hosted platform itself. For HubSpot customers the exposure is the external website that receives campaign traffic, the plugin or custom code holding a HubSpot token, and anything that relays form submissions server-side.
HubSpot's own developer documentation carries the detail that matters. Private app tokens "work similarly to OAuth access tokens, but they don't expire" (HubSpot Developers), and authenticated calls from the browser mean "exposing your credentials to anyone who views the page" (HubSpot CMS docs). So the token lives on the server. On a WordPress site the server is PHP, the process this bug reads from.
A token that never expires is revoked only when somebody revokes it. Check the pages linked from live campaigns, the path from a form submission to the contact record and the sales notification, and the private apps and their scopes under Settings > Integrations. The decision is specific: can the site still capture leads reliably, and can its token still be trusted?
Is Marketo Engage affected by PHP2Shell?
Adobe has published nothing on PHP2Shell for Marketo Engage, and nothing in the sources checked points at the hosted platform itself. For Marketo customers the exposure sits in external landing pages carrying Munchkin and form embeds, in PHP preference centres and form handlers, and in any server holding a REST client secret.
A Munchkin ID on a page is a public identifier. A REST integration is a different object. Marketo documents that the client ID and secret live in a LaunchPoint custom service under Admin > Integration > LaunchPoint, that "access tokens belong to custom services, not users", and that the API-only user's roles and permissions decide what the service may do (Marketo REST authentication). A custom service whose user may read leads and run bulk extracts is a database export waiting for a stolen secret.
Check which external systems can write the fields that feed scoring and routing. If a source is suspect, review the records it touched since 17 October before treating that activity as buying intent. The audit trail is under Admin > Integration > Web Services (API usage), LaunchPoint services and API-only users.
On Adobe's Experience League community a Marketo customer asked on 21 October: "Is anyone aware of Adobe or Marketo Engage patching their product?" (Experience League). The only reply came from a user group leader, and Adobe has not answered there. Customers look for the patch at the vendor they pay, while the exposure sits in the pages their Marketo forms are embedded in.
Is Adobe Journey Optimizer affected by PHP2Shell?
Journey Optimizer is a hosted service on Adobe Experience Platform; its customers apply no PHP patch there. The exposure is in what live journeys call: custom actions and external data sources pointed at a PHP endpoint, and the inputs journeys receive from affected websites.
Adobe documents custom actions and custom data sources as connections to external systems, with a global timeout of 30 seconds by default and up to three retries per call (Journey Optimizer external systems). The fields in a custom action response can be used "in conditions, other actions and message personalization" (custom action responses).
A compromised endpoint can therefore do worse than fail. It receives whatever profile data the journey sends, and it returns data the journey acts on. Ask which live journeys use each external endpoint, what they send, and what happens when the call times out or comes back wrong. Assess what the custom action actually sends: the profile fields in the payload and whatever authentication the call carries. That, together with the journey logic that trusts the response, is what a compromised endpoint sees.
Should you pause campaigns or customer journeys?
Pause or redirect the activity that depends on an unavailable or untrusted component. PHP2Shell on its own is no reason to stop every campaign.
An email can be deliverable while its call to action leads to a site somebody switched off at lunchtime. A nurture can keep sending while its preference centre is down and unsubscribes pile up unprocessed. A journey can run while its external call fails three times and times out. Assess the complete path before leaving the activity live.
The recovery test follows the same path: destination, form, preference handling, record update, automation, follow-up. A homepage that is back is one of those six.
Could customer data or API credentials be exposed?
Yes, where an affected PHP system holds them or can reach them. A vulnerable PHP version proves exposure and nothing more; whether anything was taken is a separate question for the logs.
Wiz Research, which found the bugs, demonstrated remote disclosure of PHP worker memory without code execution, and that memory "can expose passwords, tokens, and API keys" (Wiz Research). The memory of a worker serving a marketing site can contain, depending on how the integration runs, the HubSpot private app token, the Marketo client secret, or the key of whatever relays forms.
Revoke now, reissue after the patch. If exposure is suspected, disable the suspect token or client secret at once, from a machine you trust, and contain the integration it served; the replacement secret goes onto the host only once the host is patched and checked, because a new secret on an unpatched host is stolen again. The patch closes the door and removes nothing that came through it earlier, so a host that was exposed before patching still needs the compromise check below. Preserve evidence before anyone cleans up, then read the platform-side logs from 17 October onwards, the date of the first exploitation attempt Amazon reported, and earlier if your own web logs give a reason: API usage, new private apps or LaunchPoint services, exports, new users. Scopes and roles decide the blast radius, so review what each credential was allowed to do.
A compromise check needs something to compare against. The quickest one I know lists every file on the server and compares it with a known-good copy of the site, and on most agency-built marketing sites that copy sits with the agency, if it exists at all. Expect the comparison to turn up files nobody remembers deploying, and budget the time to establish which of them are harmless.
On notification: the 72-hour clock in GDPR Article 33 starts when you become aware of a personal data breach (GDPR). A server that was vulnerable, patched, and clean on the compromise check is a near miss to document; same-day patching on its own settles nothing, because the first attempts predate the fix by four days. A server that was compromised while it held form submissions or consent records is a breach assessment with a deadline, unless the risk to the people involved is unlikely. For organisations in scope of NIS2 a second clock can start: Article 23 requires an early warning within 24 hours of becoming aware of a significant incident, and a vulnerable server on its own does not meet that threshold (NIS2). One incident can start two clocks (the Cyberbeveiligingswet piece).
Revoke now, reissue after the patch. A new secret on an unpatched host is stolen again.
What should a CMO or head of marketing operations ask today?
Three answers, tied to live activity.
- Which campaigns and journeys depend on PHP systems? External destinations, form handlers, preference centres, connectors, journey endpoints.
- What stops working, and what may have leaked? Interrupted acquisition, missing leads, unreliable buying signals, possible credential or data access. Named per programme.
- What evidence supports keeping them live or restarting them? Confirmation of the fixed PHP build (on managed hosting the build date, since the version number may not change), a compromise check wherever patching came late, and a successful end-to-end test of the journey.
Then ask who owns the answers. Marketing owns the site, an agency owns the plugins, IT owns the server, a hoster owns the PHP binary, and the credentials joining all of it to the platform live in a plugin configuration nobody has opened since go-live. The Dutch NCSC's advice to assess every internet-facing PHP system assumes somebody holds that inventory (NCSC). In most marketing estates it lives in an agency's head.
I went through this on 21 October for a site of my own: static pages on shared hosting, with only minor PHP. Owning the site end to end did not let me patch it, because the hoster owns the PHP binary. The one lever I had was a webserver rule that refused every PHP request, and the pages stayed up. The next morning the control panel still showed the old version, and it kept showing it after the fix had landed; the proof was the build date in phpinfo, which I found when the hoster's status page pointed to it. If the person who owns a site needs a night and a status page to establish that it is patched, an estate where the plugins sit with an agency and the server with a hoster will not have that answer by lunchtime.
Assign one person to pull the hosting, agency, security and marketing-ops findings into a single view. Each supplier can close its own ticket while the customer journey stays broken between them.
The vendors are instructive. The Dutch NCSC answered the question "is my site vulnerable" by switching its own website off, which is at least consistent. Mautic, the best-known PHP-based marketing automation platform, published its guidance at 10:03 UTC and removed its trial signup form while it patched (Mautic), the only vendor I have seen take a form offline over this. The vendors whose platforms are built on other stacks said nothing. Correct, for their layer. In my reading, a vendor with nothing to say about PHP2Shell is telling you where its responsibility ends.
In Value Gravity™ terms this is a foundation-layer event. The AI features at the top of the stack are irrelevant to the exploit; what is in question is the trust placed in customer data and in the systems allowed to change it, and automation carries that uncertainty straight into scoring, personalisation and customer contact.
What is PHP2Shell, and which PHP versions fix it?
PHP2Shell is the name given to CVE-2026-109618 and CVE-2026-109619, two memory-safety bugs in how PHP handles fatal errors. Both are rated 9.2 on CVSS v4.0 and both allow unauthenticated remote code execution. PHP rates the risk highest for Apache with mod_php, and lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as affected (PHP security advisory). In the news it goes by other names: the PHP hack, the critical PHP vulnerability, the PHP RCE flaws, the emergency PHP patch of October 2026. They all refer to the same two CVEs.
The PHP patch is a set of fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026 at 14:00 UTC, a day earlier than planned after an anonymous post on 20 October and an exploit video overnight. PHP 8.1 and older receive no updates from the project; minimal source backports exist for 7.4, 8.0 and 8.1, and Linux distributions had the patches in advance. PHP's own view of its temporary mitigations: they "do not make an installation safe". PHP 8.2 is patched today and reaches end of life on 31 December 2026.
On managed hosting the fix may not show up as a version number. At least one large shared host built it into the versions its customers already run and told them the number would not change; there the evidence is the build date in phpinfo, 21 October 2026 or later. Linux distributions have worked this way for years. Debian backports security fixes "to the version that was shipped in the stable release" (Debian security FAQ). A control panel that still says 8.3.35 can be patched, and a team that checks the number against PHP's list will report a patched site as exposed. An agency that answers "we are on PHP 8.3" has answered a different question.
Read supplier updates with the same care. A host that calls its platform "not vulnerable" while its PHP upgrade is still rolling out is describing a mitigation, and PHP's advisory says mitigations "do not make an installation safe". Ask which of the two you are being told.
Wiz Research found the bugs on 19 August with frontier models in the loop, reported them on 24 August, and PHP shipped the fix on 21 October. The class of bug goes back to PHP 5.4, released in 2012. The models that write marketing copy at the top of the stack found the hole in the runtime at the bottom.
Adobe Commerce runs on PHP by Adobe's own system requirements, PHP 8.5 for 2.4.9 and 8.4 or 8.3 for 2.4.8 (Adobe), and it already had a priority-2 bulletin on 13 October with a CVSS 10.0 unauthenticated template injection (APSB26-153). Two critical patches in eight days, on two layers, for the same shop, and the second one is nowhere in Adobe's bulletin. A commerce team that applied the October bulletin and stopped there has patched the application and left the runtime.
Updating a CMS or a plugin does nothing for the runtime underneath it. The hoster or platform team applies the PHP build, marketing establishes what depends on it, and the incident is over when those two views agree on what may run. One thread stays open on purpose: first fixes for a runtime bug of this class are sometimes followed by second ones, which is why this page carries a date. On 23 October that thread moved. PHP published an informational advisory for a residual upload-progress vector, CVE-2026-115560, with the ini setting as the stopgap and the fix due in the next regular release. Ask your hoster whether the setting is off; on managed hosting it usually is.
Frequently asked questions
Is PHP2Shell the same as the PHP hack in the news?
Yes. PHP2Shell is the name researchers gave to the two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, patched on 21 October 2026. PHP hack is loose language: the vulnerability exists on every unpatched PHP server, and a site is hacked only once somebody exploits it there. Check the PHP build first, then look for signs of compromise on anything that was exposed before the patch.
Which marketing tools run on PHP?
WordPress, Drupal, TYPO3, Joomla and Craft CMS; Adobe Commerce and Magento Open Source, WooCommerce, Shopware and PrestaShop; Mautic; Matomo; and most Laravel or Symfony middleware and custom form relays. HubSpot, Marketo Engage, Adobe Journey Optimizer, Salesforce Marketing Cloud and Braze run on other stacks. For those platforms the exposure is the PHP wiring around them.
Does PHP2Shell affect Adobe Commerce?
Yes. Adobe Commerce and Magento Open Source run on PHP, so every store needs the fixed PHP build (8.2.35, 8.3.36, 8.4.27 or 8.5.12) on top of the APSB26-153 application patches of 13 October 2026. Adobe's bulletin does not mention PHP2Shell; the runtime is the hoster's or platform team's responsibility, and on Adobe Commerce on cloud infrastructure that question belongs with Adobe.
Is a WAF enough until PHP is patched?
No. Cloudflare had rules live from 03:02 UTC on 21 October, about nine hours before disclosure, and still tells customers to patch. A WAF covers only traffic routed through it. Hosting platforms added server-side protection of their own, and Pantheon for one reported blocking more than 60,000 suspicious requests (The Hacker News), but the customer can neither see nor test that protection. PHP's advisory says such measures "do not make an installation safe".
Should we take marketing websites offline?
Consider it wherever patching cannot happen within hours, which is the advice of both the Dutch NCSC and the UK NCSC. The Dutch NCSC took its own site offline. Where PHP only runs a form relay or a tracker next to static pages, there is a middle option: a webserver rule that refuses every .php request keeps the pages up and takes PHP off the internet. On shared hosting that rule is the one lever the customer holds. It does nothing for a WordPress site, where every page is PHP. A dark landing page for an afternoon costs paid clicks; a compromised one can cost the lead database and the credentials behind it.
Is blocking POST requests enough to stop PHP2Shell?
No. It blocks the multipart route PHP demonstrated for the first bug, and PHP recommends exactly that where an application has no use for multipart form data (GHSA-w8hw-w9fx-j79w). The second bug has paths that need no request body: a fatal error or timeout in one request leaves state behind that a later request on the same worker uses, and PHP states there is "no complete generic configuration mitigation" (GHSA-6wmf-4rv5-p3rp). Allowing only GET and HEAD buys time for a read-only site. Patching ends the question.
How do I check whether my hosting provider has patched PHP?
Ask for the evidence and read it yourself. On a host that ships PHP's own releases, the fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Where the host or Linux distribution backports the fix, the version stays the same and the evidence is the supplier's own marker, such as the build date in phpinfo or the package version in a distribution's security advisory. Remove any public phpinfo page once you have read it.
Do I need to rotate HubSpot or Marketo API keys after PHP2Shell?
If the secret lived on a PHP host that was exposed before patching, yes: revoke it at once and issue the replacement once the host is patched and checked. HubSpot private app tokens do not expire on their own, so revoke and reissue them under Settings > Integrations > Private apps. Marketo client secrets belong to the LaunchPoint custom service and are reset there; review the API-only user's roles while you are in Admin.
Is a PHP2Shell compromise a reportable data breach under GDPR?
A vulnerable server that was patched and shows no sign of compromise is a near miss, and worth documenting; same-day patching alone does not settle it, because the first exploitation attempts predate the fix. A compromised server that held or could reach personal data, such as form submissions, consent records or a CRM token, is a personal data breach to assess under Article 33, with 72 hours from awareness to notify the supervisory authority unless the risk to individuals is unlikely. Organisations in scope of NIS2 add the 24-hour early warning of Article 23 where the incident meets the significant-incident threshold.
Vulnerability facts as published by PHP, Wiz Research, Cloudflare, the Dutch NCSC and the UK NCSC on 21 October 2026, updated on 22, 23 and 28 October with the later reporting linked in the text; platform behaviour as documented by HubSpot and Adobe on the linked pages, which can change. The platform scenarios describe possible consequences in customer implementations, not confirmed incidents at the vendors. This is analysis for marketing and technology leaders; confirm your exposure with your own security team and counsel.