Kernels have been upgraded and VMs rebooted in order to remove live-patched delta against:
CVE-2026-99999 & CVE-2026-98432 & CVE-2026-72389 & CVE-2026-53266 & ZDI-CAN-33367.

• M-VPS Primary: 4.18.0-553.180.1.lve.1.el8.x86_64
• M-VPS Fallback: 4.18.0-553.177.1.lve.1.el8.x86_64
• M-DNS Primary: 4.18.0-553.183.1.el8_10.x86_64
• M-DNS Fallback: 4.18.0-553.177.1.el8_10.x86_64

“Infinity Core” vulnerabilities do not impact CloudLinux v8 (only v9/10) so do not impact Merlot.
CVE-2026-98260 & CVE-2026-98256 & CVE-2026-89754 & CVE-2026-80775 all relate to same.
Note: We follow the lifecycle, which supports CL8 until 31st May 2029, then CL9 until 31st May 2032.

WordPress has a new RCE vulnerability, during upgrades only. Please ensure you patch WP.
CVE-2026-119977 is the during-upgrade RCE. It’s separate to CVE-2026-63030/60137 before.
Note: We forced updates for 63030/60137, though we won’t for 119977 due to upgrade-only scope.

Firewall Policies on Hypervisors are scheduled to be deployed before next weekend is out.
Two clients have opted to be early to go-live with these (thank you!) - they will proceed firstly.

We’ve kept upload_progress disabled, and PHP.net have again confirmed this as being wise.
CVE-2026-115560 will be patched in an upcoming release, and for now keeping it disabled mitigates it.

Google patched a flaw in Brotli on the 28th of Feb yet didn’t release it as a patch until the 22nd of Oct.
CVE-2026-111497 is mitigated: we upgraded to brotli-1.0.6-5 which addresses the out-of-bounds write.

It’s good to see eMudhra exiting the SSL/TLS market after their CA Private Key blunder, including “4”…
CVE-2026-114406 is mitigated: we upgraded to ca-certificates-2026.2.92 which fully distrusts eMudhra.

We’re not affected by the PXE booting vulnerability in TianoCore EDK II (PXE Driver), due to not using PXE.
CVE-2026-97631 had embargo violated by mistake, resulting in the vulnerability being exposed months early.

Hypervisor-level Firewall and Security Group configurations are scheduled to go-live this week.
We don’t expect interruptions to service though do be aware of the possibility of very brief fluctuations.

A user on The Hacker News laid a bounty if someone could successfully achieve RCE, which they did.
https://github.com/KillaBoi/StealMyBitcoin-PoC shows how they ran the binary on https://stealmybitcoin.com

Thank you for your continued patience throughout. We expect to close this out in the next week or so.

Minor kernel updates have been brought into run-time, with the versions (pre-live-patches) being:

• M-VPS: 4.18.0-553.171.1.lve.el8.x86_64 (built: 7th October 2026)
• DNS: 4.18.0-553.177.1.el8_10.x86_64 (built: 21st October 2026)

Final testing of new hypervisor Security Group and Firewall Policy configurations are now underway.
These will allow stacked application to VMs, for instance: DirectAdmin + Web + Mail + FTP security groups.

We’ll continue to update this advisory as we progress through further and final security works.
Thank you for your continued patience throughout. We’re glad to report zero issues found so far.

PHP version upgrades to sync numbering with PHP.net releases were all completed yesterday.
Note: This still carries no further protection, as the previously-applied backported patches carry over.

Removal of CSF & expansion of Imunify360 features has been completed as of this advisory update.
We’ve confirmed that Imunify360 has picked up the extra workload successfully across all Managed VMs.

Note: Managed Server reboots (including DNS reboots) will be undertaken ahead of 9pm this evening.
This brings newer kernels into run-time (removing live-patched delta) & validates firewall table persistence.

From there, we’ll be proceeding with hypervisor-level network policy configuration & deployments.
Outside emergencies, this will primarily handle port-level blocking outside of regular/used ports/ranges.

We’re upgrading PHP packages purely to increment version numbers to align with PHP.net releases.
This does not change the patch status, of which backported patches have been live since early yesterday.

Deep Scanning is now complete on all except 2x Servers across all of Merlot Digital’s infrastructure.
There have been zero detected incidents, yet we continue to work through additional checks just in case.

Preparation works with regard to CSF removal are largely complete - removal should be done today.
Removing CSF will improve Imunify360’s scope and allow us to expand our orchestration tooling’s coverage.

Policy amendments at hypervisor-level remain in-planning, with the goal of taking loading off VMs.
This means that more network policy decisions will be enforced before the traffic reaches Virtual Machines.

Preparation is underway to remove CSF entirely and enable more functionality within Imunify360.
This is being done in consultation with CloudLinux’s Security team to ensure the change goes smoothly.

Just eight servers are still scanning, with the bulk now completed and having returned no anomalies.
Further checks and balances are continuing to ensure that we and specialist forensic analysts are happy.

Thank you again for your on-going patience during this series of events. It’s very much appreciated.
We’ll continue to provide updates here until we’re comfortable. System policy changes are in-planning.

Deeper scans are progressing at the moment, so far revealing nothing untoward across our fleet.

This follows a range of checks, pattern analysis and change reviews to sanity-check adjustments across every Managed Server to ensure there is nothing untoward. The current scans are automated & penetrate deeper.

CloudLinux have now accepted 3x fault reports across their software as part of our investigations.

Refs: DEF-58434 via 297233 (misleading GUI status regarding WAF), DEF-58431 via 297238 (compatibility problem between web stack and Imunify360 WAF, dating back to 2020 - including the 6~ years of history) and DEF-58674 via 297882 (auth.admin file not honoured, and missing grant_reseller_admin_ui on DA).

We’re continuing to progress security works from a proactive perspective, and will update further.

Thank you for your continued patience throughout this series of events. It is very much appreciated.

The PHP Foundation has confirmed that Chainguard broke embargo, causing a lot of undue chaos.

Read here for more information about that, and the Foundation’s efforts: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

“On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.”

It seems that Chainguard released their binaries 55 minutes before public exploitation was seen online, making it very hard to see past the probable causation that Chainguard caused the early exploitations to commence, which made this incident far worse than it had to be - as PHP say, undoing weeks of coordinated, careful work.

The PHP Foundation have detailed how the OOM problems were almost discovered back in 2024.

“In 2024, PHP underwent its first external security audit in years. The PHP Foundation secured funding from the Sovereign Tech Agency to organise this audit through OSTIF, and it was carried out by Quarkslab. While fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs of the OOM problem behind CVE-2026-109618. In 2024, a potential exploit for the OOM problem was theorised, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns.

To fix the OOM problem, the PHP security team developed several competing approaches, but each came with its own trade-offs: backward compatibility breaks, new denial-of-service potential, or requiring changes to many third-party extensions which seemed impossible to coordinate. The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice. Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months.”

Part of our escalation with CloudLinux is seeking for them to become a trusted party by PHP, to reduce delays in the future when vulnerabilities are published - as if they had that status before today, it should’ve been fast.

We’ll continue to share further updates, and are providing this to give context around the vulnerabilities.

Updates are now available via regular channels. We will keep upload_progress permanently disabled.

The updates to PHP will not be applied until later today/tonight, to reduce inside-business-hours impact now that we’re running secure binaries across the board.

We have a case with CloudLinux Management where we’re working with them to get a thorough explanation of their internal failings, learnings and beyond - to ensure what happened throughout this incident is not repeated in their future handling of incidents.

PHP’s official advice is to keep upload_progress disabled permanently, as they say it is hardly used and hardly tested, despite being a default-enabled feature of the PHP language. We’re following that advice.

Further security-based works remain underway with regard to bolstering protections, as we’re observing a marked increase in malicious traffic as is to be expected with vulnerabilities of this scale. This is proactive to ensure that we’re covering all bases.

Again, this advisory won’t be closed until we’re 100% satisfied. Thank you.

Backported updates have been applied to DirectAdmin servers, and reboots are now underway.
Please note: Due to the fixes being backported, versions are not yet advanced to the latest available.

Instead, the fixes have been cherry-picked and added into the prior (last faulty) versions - example:

$ /opt/alt/php84/usr/bin/php -v
PHP 8.4.26 (cli) (built: Oct 21 2026 13:31:54) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.26, Copyright (c) Zend Technologies
$ rpm -q alt-php84 --changelog | grep -E "CVE-2026-(109618|109619)"
- CVE-2026-109618: do not bail out from inside the memory manager; allocation
- CVE-2026-109619: clear stale request globals at shutdown so a bailout cannot

As the normal release procedures occur in coming days/weeks, you will see the versions graduate as normal.

CloudLinux have now properly released alt-php## updates through their ELS repository.
We’re proceeding with deploying these updates, after having completed further mitigation deployments.

Please be aware that we’ll be power-cycling DirectAdmin servers for the avoidance of doubt re: workers.
We’re part-way through the update process which we’re delivering to VMs through our orchestration tooling.

CloudLinux have now publicly confirmed their release blunder which we initially reported to them.

No updates have been published for CloudLinux 8 alt-php## packages at this time, as a result of their error.
We’re now starting to deploy more aggressive mitigations, largely due to their chaotic response to this today.

We’ve identified major problems with CloudLinux’s release procedure & have escalated to them.

There are now 3x active tickets between us and them, working in parallel to progress everything.
Many thanks for your patience. This incident has highlighted room for improvement on their side.

Thank you for your patience. Key updates so far today are as follows:

• cPanel PHP by CloudLinux (ea-PHP via CL) has been upgraded on the small number of servers.
• CloudLinux alt-PHP release progress has been speeding up with them introducing more build farm.
• Further protections are coming online, and we expect to have full coverage by 9am - same as last night.
• CloudLinux have only just committed to public updates every 30 minutes until they are finished publishing.

Imunify360 WAF Rules v8.83 & v8.84 expand coverage against attacks leveraging these exploits.
You can read the changelogs here, sometimes with a delay: https://changelog.imunify.com/waf-rules

cPanel have listed EasyApache4 v25.91 in their changelog, yet still are not making it available.
Relevant changelog is here: https://docs.cpanel.net/changelogs/easyapache-4-change-log-25

CloudLinux continue to slowly publish further distributions and releases of their patches.
It is expected that their pace will increase as stability of versions released proves to be OK.

Media Control Panel has been upgraded to v2.15.7 which bundles patched PHP v8.3.36.
That caused a liquidsoap problem which they’ve resolving by installing missing ffmpeg packages.

DirectAdmin’s bundled PHP has had the patches passed through, which we’ve already deployed.
However, that doesn’t cover alt-PHP from CloudLinux which is what DA clients actually operate on.
Importantly, LiteSpeed is far more limited in scope than Apache’s mod_php, which is good news.

cPanel are releasing updates through EasyApache (v25.91) and WHM itself (v138.0.18) slowly.
We’ll start to roll-back mitigations on those machines to allow websites return to normal service.

CloudLinux are slowly releasing patched versions of alt-PHP group packages to their repos.
They are progressing slowly on the release of those due to the scope of their global impact.

The vulnerabilities have been released, with patches available from PHP for:

• CVE-2026-109618 RCE via OOM corruption: out-of-memory handling can interrupt PHP while internal request data is only partially initialised. Request cleanup may then treat the invalid data as valid.
• Summarised: Memory corruption when PHP runs out of memory while handling specially crafted multipart (form or upload) requests.
• CVE-2026-109619 RCE via stale global state: request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialisation resets it.
• Summarised: Internal data left over from an earlier request can be reused after its memory is freed, for example through session upload progress handling.

Patched versions of PHP are: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (with back-ports to 8.1, 8.0 and 7.4)

DirectAdmin have passed it on, however we run alt-PHP from CloudLinux, of whom are yet to publish.
Quoting the releases from PHP: “There are no complete mitigations, updating is the only safe choice.”

A PHP Core Developer (Gina Peter Banyard) advised that won’t be enough to fully mitigate.

We’re still working internally on protections and thank you for your patience throughout this.
Our goal is to do the best thing by our clients, and right now that is to be very cautious.

We’re proceeding with upload_progress disablement as partial mitigation of these vulnerabilities.

Thank you for your patience and understanding. We expect to roll-back any restrictions by 9am tomorrow. At this time, security is at the fore-front and we’re acting on credible intelligence from the Security community.

Please note: DirectAdmin have escalated their response, saying their re-packaging will be immediate.

Providing some brief updates with regard to the 3x main upstreams of concern with regard to this.

CloudLinux are publicly sharing updates with regard to these vulnerabilities and patches via:
https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5

Media Control Panel was made aware of the issues by Merlot Digital, and has published this:
https://www.mediacp.net/news/critical-security-advisory-php2shell

DirectAdmin have confirmed they will be processing this from 1am onwards - forum musings:
https://forum.directadmin.com/threads/critical-php-updates.82726

There is somewhat credible information that it may explicitly relate to upload_progress functionality.
Based on that, although not officially verified, we are proceeding with removing it for the time being.