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.
Fixed PHP builds have been available since 14:00 UTC: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Cloudflare and Patchstack report exploitation attempts; the Dutch NCSC and Huntress had observed none when they published. Mautic published guidance for its users. I found nothing from HubSpot or Adobe, consistent with their platforms running on other stacks. No compromise of a marketing platform through this route has been confirmed anywhere. The scenarios below are possible consequences in customer implementations, and are labelled as such.
- 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. Exploitation unconfirmed
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'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 reported no impact from the PHP vulnerability, and its platform does not run PHP. 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?
Marketo Engage runs on Adobe infrastructure and Adobe has reported no impact from the PHP vulnerability. 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 20 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.
Is Adobe Journey Optimizer affected by PHP2Shell?
Journey Optimizer runs on Adobe Experience Platform, with no PHP in the service and nothing there for the PHP patch to fix. 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. Credentials stored inside Adobe's platform are out of reach for a bug on the other side of a custom action; the data in flight and the journey logic that trusts the response are what is exposed.
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 contains, at various moments, the HubSpot private app token, the Marketo client secret, or the key of whatever relays forms.
Rotate after patching; a secret rotated on an unpatched host is stolen again. The order is contain, preserve evidence, patch, rotate from a trusted machine, then read the platform-side logs for the window since 20 October: 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.
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 and patched the same day is a near miss to document. A server that was compromised while it held form submissions or consent records is a breach assessment with a deadline, and for organisations in scope of NIS2 a second clock of 24 hours for the early warning. One incident can start two clocks (the Cyberbeveiligingswet piece).
Rotate after patching; a secret rotated 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, 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.
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 one PHP-based marketing automation platform, published its guidance at 10:03 UTC and removed its trial signup form while it patched (Mautic), the only marketing automation vendor to take a form offline over this. The vendors whose platforms run on other stacks said nothing. Correct, for their layer. 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.
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 and 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. A commerce team that applied the October bulletin and stopped there is still exposed.
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.
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 version 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; a site on shared hosting with its origin reachable directly had no stopgap at all.
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. A dark landing page for an afternoon costs paid clicks; a compromised one can cost the lead database and the credentials behind 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, once the host is patched. 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 before any compromise is a near miss, and worth documenting. 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.
Vulnerability facts as published by PHP, Wiz Research, Cloudflare, the Dutch NCSC and the UK NCSC on 21 October 2026; 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.