The critical PHP vulnerabilities, and why they stop short of your website
On 21 October 2026 the PHP project released emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619. They let an attacker run code on any web server that executes PHP. The websites Webcoda builds, hosts and manages run on Microsoft .NET or on HubSpot's managed platform, and neither uses PHP.
Which platform is your website on?
Choose your platform to see the detail that applies to you. The page starts with all three.
Not sure which one you are on? It is listed in your Client Portal, or ask your account manager.
Your website is built on Kentico, which runs on Microsoft .NET. It does not use PHP, and no PHP runtime is enabled on the Azure hosting we manage for you. These vulnerabilities target the PHP engine on the web server. There is no PHP engine in your environment, so there is nothing for them to reach, nothing to patch and nothing to switch off.
Your website is built on Umbraco, which runs on Microsoft .NET. It does not use PHP, and no PHP runtime is enabled on the Azure hosting we manage for you. These vulnerabilities target the PHP engine on the web server. There is no PHP engine in your environment, so there is nothing for them to reach, nothing to patch and nothing to switch off. Umbraco HQ says the same: "Umbraco runs on .NET: not affected by PHP issues".
Your website runs on HubSpot, a fully managed platform that HubSpot hosts and operates. HubSpot confirmed on 22 October that "PHP is not part of HubSpot's infrastructure, and we are not aware of any impact to our platform or customers". The templates, modules and integrations Webcoda built for you run inside that platform and do not introduce PHP.
Two bugs in the engine that runs PHP websites
PHP is a programming language that runs on the web server behind a large share of the internet, including most WordPress, Drupal, Joomla and Magento sites. The two flaws, nicknamed PHP2Shell by the security community, are not in any one of those products. They are in the PHP engine itself, so every website served by an unpatched copy of PHP is exposed.
An attacker sends a specially crafted request to a server running PHP and can then run their own code on that server, without logging in. From there, everything on the server is within reach: the database, uploaded files, configuration and credentials, and any customer data stored there. The PHP project says there are no complete workarounds; updating PHP is the only safe fix. Exploitation attempts were seen four days before the fix was public, and attempts are now widespread.
- 17 Oct 2026First exploit attempt caught by Amazon's honeypots, before anyone outside the embargo knew
- 20 OctDetails leak on Hacker News ahead of the planned release; the PHP project posts an early warning
- 21 OctFixes released in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a security advisory; proof-of-concept exploits follow within hours
- 22 OctHubSpot and Umbraco HQ publish their positions: neither platform runs PHP
- 23 OctWebcoda confirms every client environment it builds, hosts or manages is free of PHP (this page)
- 27 OctUnrelated Umbraco CMS and Forms security patches due, evening AEDT. Not PHP; Webcoda applies them under maintenance for Umbraco clients
| PHP line | Fixed in | Status | Relevance to your site |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | Supported | None. Your site runs no PHP of any version. |
| PHP 8.4 | 8.4.27 | Supported | |
| PHP 8.3 | 8.3.36 | Supported | |
| PHP 8.2 | 8.2.35 | Supported until 31 Dec 2026 | |
| PHP 8.1, 8.0, 7.4 and older | No release | End of life; minimal source patches only |
The same request, two very different outcomes
The attack only works if the request reaches a PHP engine. Here is how a PHP website is layered, next to how yours is.
For example WordPress on a shared or managed PHP host
- Visitor's browser
- Web server (Apache, Nginx or LiteSpeed)
- PHP engine VulnerableCVE-2026-109618 and CVE-2026-109619 live here. The attacker's code runs as the web user.
- WordPress, Drupal, Joomla or Magento Bypassed
- Database, uploads, configuration Exposed
Outcome: the attacker runs code on the server before the website's own code is even involved. Everything on that server is at risk until PHP is updated.
Kentico or Umbraco on Microsoft .NET, or HubSpot's managed platform
- Visitor's browser
- Azure App Service managed by Webcoda, or HubSpot's edge and firewall
- Microsoft .NET runtime, or HubSpot's platform No PHP engineThe request is handled as ordinary web traffic. There is nothing here for the exploit to trigger.
- Kentico, Umbraco or HubSpot Content Hub, built by Webcoda
- Your database and files Not reachable
Outcome: nothing happens. No code runs, no data is exposed, and there is nothing to patch. Scanning traffic may show up in logs; it is harmless here.
Our review of your environment
- Website and CMS code Kentico UmbracoC# on Microsoft .NET. No PHP code and no PHP dependencies anywhere in the solution.
- Hosting we manage for you Kentico UmbracoMicrosoft Azure App Service configured for .NET only. No PHP runtime is enabled or in use.
- HubSpot platform HubSpotHosted and operated by HubSpot behind its own web application firewall. HubSpot has confirmed PHP is not part of its infrastructure and reports no impact to its platform or customers.
- Templates and modules we built HubSpotHubL templates, custom modules and any HubSpot functions run inside HubSpot's platform and introduce no PHP.
- Integrations we built for youForm handlers, data feeds, portals and API connections written by Webcoda are .NET or API-based. Our side of every connection is PHP-free; see the scope note below for the other side.
- Availability, security and functionalityNo impact identified. Scanning for these CVEs reaches every public website, but without a PHP engine the payload does nothing, and we have seen no change in the behaviour, performance or integrity of client sites.
What this confirmation covers, and what it cannot
We can only vouch for what we built, host or manage. Other systems in your organisation may well run PHP, and their providers need to confirm their own position.
Covered by this notice
- Your Kentico, Umbraco or HubSpot website or web application itself
- Hosting Webcoda manages on your behalf (Azure App Service and the services around it)
- Integrations, feeds, portals and form handlers Webcoda wrote, on our side of the connection
- Webcoda's own systems and tooling
Ask the provider directly
- Platforms you subscribe to directly: payment gateways, booking systems, marketing tools, analytics
- Websites or microsites on other hosts, including any WordPress blog or landing page we did not build
- The far side of an integration run by another vendor (their CRM, ERP, portal or API)
- Your internal IT systems, intranets and vendor tools
If any of these run on PHP, they need PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a version the vendor has patched. We are happy to help you word the question.
What the platform vendors have said
Built on .NET; no PHP2Shell statement yet
"Built on modern .NET and React."
Kentico has not published a PHP2Shell notice as at 23 October 2026. Its security page confirms the platform's stack, and its security team can be reached through the vulnerability disclosure program.
Not affected by PHP issues
"Umbraco runs on .NET: not affected by PHP issues."
Umbraco HQ's Trust Center carries that line, and its 22 October security heads-up repeats that Umbraco "depends on a different framework (.NET)". The patches it has announced for 27 October are unrelated to PHP.
PHP is not part of HubSpot's infrastructure
"PHP is not part of HubSpot's infrastructure, and we are not aware of any impact to our platform or customers. We will continue to watch the situation and provide an update if our assessment changes."
Published in the Announcements section of HubSpot's Trust Center on 22 October 2026.
Straight answers
Does either vulnerability apply to our website, its hosting or its integrations?
No. Your site is a .NET application on Azure hosting that runs no PHP. Both CVEs are flaws in the PHP engine, so with no PHP engine present there is no attack surface in the website, the hosting or the integrations we built.
No. Your site runs on HubSpot's managed platform, and HubSpot has confirmed PHP is not part of its infrastructure. The templates, modules and integrations we built for you run inside that platform and add no PHP.
Do we need to patch, upgrade or change any configuration?
No. There is nothing to patch because there is no PHP to update, and no configuration change makes a .NET or HubSpot site any safer against a PHP flaw. No downtime is involved.
What PHP version are we running?
None. Your environment has no PHP of any version.
Your stack is Kentico on Microsoft .NET, with Azure SQL Database, hosted on Azure App Service that Webcoda manages.
Your stack is Umbraco CMS on Microsoft .NET, with Azure SQL Database, hosted on Azure App Service that Webcoda manages.
Your stack is HubSpot Content Hub, hosted and operated by HubSpot, with templates and modules built by Webcoda.
Are the features and integrations you built for us affected?
No. Everything Webcoda wrote for you is .NET or API-based on our side of each connection. Where a feature connects to another system, for example a payment gateway, a CRM or a records system run by someone else, we can confirm our side is PHP-free but cannot speak for theirs. Ask that provider for its own confirmation; we will help you frame the question.
Has anyone tried to exploit this against our site?
Scanning for these CVEs is hitting public websites everywhere, so some of that traffic may reach your site. The payload needs a PHP engine to do anything, and there is none here, so it has no effect.
On the hosting we manage we have seen no change in the behaviour, performance or integrity of client sites. If you would like a log review for your environment specifically, ask your account manager and we will arrange it.
HubSpot reports no impact across its platform and runs its own web application firewall in front of every site. For the services behind your custom modules, there is no PHP to exploit.
We also have a WordPress blog or other systems with another provider. What should we do?
Ask that provider to confirm, in writing, the PHP version in use and that it is 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a vendor-patched build. PHP 8.1 and older no longer receive official releases, so a site on an old line needs a vendor backport or an upgrade. If you want a second opinion on their answer, send it to us.
Umbraco has announced security patches for 27 October. Is that related?
No. Those patches cover Umbraco CMS and Umbraco Forms issues that Umbraco HQ describes as unrelated to PHP. For Umbraco clients on a maintenance or retainer arrangement, Webcoda applies them as part of normal maintenance and confirms once done.
How will we hear if anything changes?
We are watching the PHP project's advisories and each vendor's trust and security pages. If our assessment changes for any reason, we notify affected clients within 48 hours.
Concerned about a system we didn't build?
Tell us what it is and who runs it. We will help you work out what to ask, and read the answer with you.
- PHP project, Security advisory: critical remote code execution vulnerabilities, update now, 21 October 2026
- PHP security advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- HubSpot Trust Center, HubSpot update on PHP vulnerability, 22 October 2026
- Umbraco HQ, Security and Umbraco, and Security heads-up for 27 October 2026
- Kentico, Security and Vulnerability disclosure program
- Amazon Threat Intelligence, PHP2Shell exploitation prior to public disclosure, 22 October 2026
- Decipher, Critical PHP flaws disclosed, patches out now, 20 to 21 October 2026
