How enable.services responded to the PHP2Shell vulnerabilities
On 20 October 2026, two critical vulnerabilities were disclosed in PHP, the programming language that powers a significant proportion of the web. Rated 9.2 out of 10 for severity, the flaws could allow attackers to execute code on a server without logging in, potentially putting systems and customer data at risk.
As we host SugarAI (SugarCRM), Mautic and EspoCRM, all of which rely on PHP, the vulnerabilities posed a potential risk to our hosted environments and the business information our customers rely on. Although the flaws weren’t within these applications themselves, any system running a vulnerable version of PHP could be exposed.
With details leaking before the official fix was released and reports of a working exploit circulating, we began assessing our hosted systems immediately and took protective action before the patches became available.
By the time active exploitation was reported, our hosted systems were already offline or protected. We patched every server within 15 minutes of the fixed PHP packages becoming available, checked every system for signs of compromise and found none.
Here’s what happened, how we responded and what it means for our customers.
What was PHP2Shell?
PHP2Shell is the name given to two critical vulnerabilities in PHP, identified as CVE-2026-109618 and CVE-2026-109619. Both were rated 9.2 out of 10 for severity.
The vulnerabilities could allow an attacker to execute their own code on a server without needing to log in first. This is particularly serious because it potentially gives an attacker a way into the server itself, rather than requiring them to compromise an individual user account.
PHP is used by a huge number of websites and applications, including SugarCRM, Mautic and EspoCRM. The vulnerabilities were in PHP itself, rather than in these applications.
This distinction matters. Even when an application is properly configured and up to date, a vulnerability in the underlying technology it relies on can still put the wider system at risk.
An attacker able to execute code on a vulnerable server could potentially interfere with applications, access data or make unauthorised changes, depending on the server’s configuration and permissions. That meant the potential consequences extended beyond website availability to the security of customer systems and information.
Why was the timing so important?
On 20 October, PHP announced an emergency release, with fixes scheduled for 15:00 UK time on 21 October. Details of the vulnerabilities leaked the same day, and a working exploit was reported to be circulating before the patches were available.
PHP confirmed there was no workaround and that updating was the only safe option.
This created a narrow window in which organisations needed to protect vulnerable systems without yet having the permanent fix. Waiting until the patches were released would have left systems exposed during a period when attacks were anticipated.
We therefore prepared to take protective action before the release, rather than waiting for the vulnerability to be actively exploited.
How we responded to PHP2Shell
1. We protected systems before the fix was available
We began assessing our hosted infrastructure as soon as the vulnerabilities were announced.
On the morning of 21 October, we told customers that their hosted systems would be taken offline at 15:00, when the PHP fixes were expected to become available. For customers using SugarAI and EspoCRM who needed continued access, we offered an IP allowlist option to restrict access to approved addresses.
At approximately 14:10, Cloudflare reported early attack attempts. In response, we brought the planned shutdown forward to 14:30.
At that time, we took all hosted SugarAI, Mautic and EspoCRM systems offline or placed them behind IP allowlists.
This was a deliberate precaution. With the potential for attackers to execute code remotely, we prioritised reducing exposure over keeping every system publicly accessible while we waited for the fix.
2. We patched every server within 15 minutes
The fixed PHP packages became available at approximately 14:50 on 21 October.
Our servers obtain PHP updates through a repository that published the fixed versions within minutes of PHP’s release. This meant we could move quickly without waiting for slower distribution channels.
We patched every server within 15 minutes of the updated packages becoming available. We also fully restarted PHP services to ensure systems were no longer running the previous, vulnerable code in memory.
Once patching was complete, we restored services.
The fixed versions were:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
By acting before the patches were released and applying them as soon as they became available, we reduced the window in which our hosted systems could be exposed.
3. We checked every system for signs of compromise
Installing a security patch closes the vulnerability, but it does not necessarily remove anything an attacker might have done before the fix was applied.
For that reason, our work did not stop when the servers were patched. Across 21 and 22 October, we investigated every hosted system for signs of compromise, covering the period since details of the vulnerabilities first leaked on 20 October.
Our checks included looking for:
- Files that had been unexpectedly created or changed.
- Unexpected code in upload and cache areas.
- New user accounts, particularly administrator accounts, and records of who had created them.
We reviewed the results across our hosted estate. No signs of compromise were found, and every new account identified during our checks was traced to a legitimate user.
This distinction is important. Patching addresses the vulnerability; investigating the systems helps establish whether there is evidence that the vulnerability was exploited before the patch was applied.
Both steps were necessary to give our customers a clearer picture of their systems’ security.
4. We kept customers informed throughout the incident
A security incident is not just a technical problem. Customers need to understand what is happening, how it affects their access and what action they need to take.
We sent three updates to customers on 21 October.
The first explained the planned shutdown and the option of using IP allowlists to retain restricted access to SugarAI and EspoCRM. The second informed customers that we were bringing the shutdown forward in response to reports of early attack attempts. The third confirmed that systems had been patched and services restored.
We focused on communicating what we knew, what we were doing and what each development meant for customers. We also took care not to overstate or downplay the risk before the facts were established.
Our aim was to give customers timely, straightforward information throughout the process, rather than leave them wondering why their systems were unavailable or whether their data had been affected.
PHP2Shell: incident timeline
The following timeline shows how events unfolded. All times are UK time (BST).
20 October: PHP announced an emergency release for the following afternoon. Details of the vulnerabilities leaked, and we began assessing our hosted systems.
21 October, morning: We notified customers that systems would be taken offline at 15:00, with an IP allowlist option for SugarCRM and EspoCRM.
Approximately 14:10: Cloudflare reported early attack attempts. We brought the planned shutdown forward by 30 minutes.
14:30: We took hosted SugarCRM, Mautic and EspoCRM systems offline or placed them behind IP allowlists.
Approximately 14:50: PHP published the fixed versions. We began applying the updates.
Within 15 minutes of the fixed packages becoming available: Every server had been patched. We fully restarted PHP services and restored access.
15:19: watchTowr reported active exploitation attempts. Our systems were already offline or patched.
21–22 October: We checked every hosted system for signs of compromise. No signs were found.
What does this mean for our customers?
If enable.services hosts your SugarAI, Mautic or EspoCRM system, it was patched on 21 October and checked for signs of compromise. Our investigation found no evidence of compromise, and you do not need to take any action in response to this incident.
PHP2Shell also demonstrates why the way your systems are hosted matters.
The importance of specialist hosting
PHP2Shell was a vulnerability in the underlying technology, not a flaw specific to SugarAI, Mautic or EspoCRM. It demonstrated how a weakness in a widely used component can create risk across many different applications.
For us, the response was straightforward in principle, even if the work itself was time-critical: assess the threat, protect systems before the fix, patch as soon as possible, investigate for signs of compromise and keep customers informed.
We patched every server within 15 minutes of the fixed packages becoming available, restored services and completed checks across our hosted systems without finding evidence of compromise.
That is what we believe customers should expect from a specialist hosting partner: not a promise that vulnerabilities will never emerge, but a team with the expertise to respond decisively when they do.
If you’d like to know more about how we protect hosted systems, or you’re considering hosting your SugarAI, Mautic or EspoCRM environment with enable.services, contact our team to discuss your requirements.
