Major security alert: PHP vulnerable to critical RCE, attacks ongoing. Published October 21, 2026 Mart Virkus Head of Marketing Table of contents PHP has released the fix. Update now. PHP has released security updates for two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs. Sites built on WordPress, Drupal, Magento, Joomla, Laravel and other PHP applications are exposed if they run a vulnerable PHP version. PHP updates are out. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. If you rely on the volunteer-maintained rpms.remirepo.net, PHP says it will not have updates today and urges switching to distribution packages or building from source. PHP 8.1 and older no longer receive updates from the PHP project, but several maintainers have backported the fix. Status as of 22 October. Check your vendor for updates. * Debian and Ubuntu: Ondřej Surý's packages (packages.sury.org and ppa:ondrej/php) have the fix for every end-of-life branch from PHP 5.6 to 8.1. Ubuntu 22.04's own PHP 8.1 is also patched (php8.1 8.1.2-1ubuntu2.28). * Older Ubuntu: Ubuntu Pro covers 14.04 to 20.04. The 14.04 and 16.04 releases need the Legacy add-on. * Debian 9 to 11: Freexian ELTS (paid) covers PHP 7.0 on Debian 9, 7.3 on Debian 10 and 7.4 on Debian 11. Debian's own LTS for Debian 11 ended on 31 August 2026, but Sury's php7.4 package is a free route. * AlmaLinux: Patched packages are out for the PHP streams on AlmaLinux 8, 9 and 10, including end-of-life streams. Future fixes aren't guaranteed. * RHEL and Remi: Red Hat's coverage is partial. Fixes exist for php:7.4 on RHEL 8 and PHP 8.0 on RHEL 9, but retired streams such as 7.2 and 8.1 on RHEL 9 get none. Remi has fixes for 7.4, 8.0 and 8.1 on RHEL 8 and 9, but nothing for 7.2 or 7.3. * cPanel: CloudLinux has released fixed ea-php packages for EasyApache 4 from ea-php52 through ea-php85. * Paid extended support: TuxCare ELS is rolling out patches per branch, so confirm your exact platform. Zend says its LTS builds of 7.2, 7.3, 7.4 and 8.1 were patched at release. * Docker: The official php image gets no fix for 8.1 or older. * Building from source: PHP's backports for PHP 7.4, PHP 8.0 and PHP 8.1 are a last resort. They're a minimal mitigation, not a restored support branch: they switch session upload progress off regardless of php.ini and add no hard memory limit. How to check a package is fixed: On Ubuntu and Sury's old-branch builds, which keep the upstream version number, check the changelog for CVE-2026-109618 and CVE-2026-109619. Debian and the Sury repos ship new upstream releases, so there the changelog may only say "New upstream version". Compare against the fixed version instead. On RHEL's 8.2 and 8.3 streams, the changelog only says "rebase", with no CVE numbers. Use dnf updateinfo there. If your vendor has no fix, upgrade to a supported PHP version. PHP 8.2 receives security fixes only until 31 December 2026, and PHP 8.3 until 31 December 2027, so aim for 8.4 or 8.5. Live timeline. * 13:57 UTC - Shortly after PHP's update, its telemetry shows only probing attacks, with no hard evidence of breaches yet. This is expected to change as details of the security update go public. Updating is absolutely necessary. * 13:52 UTC - PHP releases PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing both vulnerabilities. * Earlier on 21 October - As a precaution, services including Dutch government sites DigiD and MijnOverheid, The SEO Framework and major Japanese platforms go offline until the patch is released. * 07:43 UTC - Cloudflare's CTO says Cloudflare is seeing early attacks and has deployed initial WAF rules for known exploit vectors. * 07:34 UTC - Multiple active exploitation incidents reported to Patchstack by hosting partners. * 20 October - Details leak ahead of coordinated disclosure. The PHP security team announces the 21 October release. What Patchstack know. * The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both Critical (CVSS v4.0 9.2). * CVE-2026-109618: 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. * CVE-2026-109619: Request-owned internal state can survive after its memory has been freed. A later request handled by the same worker may use that stale state before normal initialisation resets it. * The flaws are in the PHP interpreter, not in any one application, so any site on a vulnerable PHP version is exposed. * Wiz Research, which reported the bugs to PHP, says every PHP version back to 5.4 is affected by at least one of the issues. It demonstrated unauthenticated remote code execution against the latest WordPress, Drupal and Joomla container images, and says even a simple "Hello World" app on a vulnerable PHP version can be exploited. It also demonstrated reading PHP worker memory, which can contain passwords, tokens and API keys, without achieving code execution. Wiz says PHP's patch fixes the underlying problem, including other variants. * Details leaked on 20 October, before the coordinated disclosure, and the issue was called "PHP2Shell". Security firm watchTowr had confirmed the flaws were real before the release. * Several organisations took services offline as a precaution until the patch was out: * Dutch broadcaster NOS reports that DigiD, MijnOverheid, the Dutch House of Representatives' website, Tweakers and the Dutch National Cyber Security Centre's own site were among those offline. * Japanese outlet ITmedia reports emergency maintenance at several major services, including Kodmon, Shadowverse: Worlds Beyond and Sakura Rental Server, believed to be linked to this vulnerability. It adds that others, including BASE and Xserver, were expected to follow. * The developers of The SEO Framework said they took their servers offline. * Cloudflare says PHP sites behind it have an initial set of WAF rules for the known exploit vectors, available to all customers, including free. It describes this as a stopgap only. The rules only help if your server accepts traffic exclusively from Cloudflare. * CERT-EU has issued an advisory, and the UK's National Cyber Security Centre has issued an alert urging organisations to update immediately. How to protect your websites. * Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's patched package. * Find every PHP install you run (servers, containers, staging sites, and appliances or third-party software that bundle PHP) so you know what needs updating. * If you run PHP 8.1 or older, check whether your vendor has a backported fix or upgrade to a supported version. * Avoid unofficial "fix" plugins and copy-pasted snippets. They are not verified and can break your site. * If you can't update right away and your site is high-risk, consider taking it offline or into maintenance mode until you can. The UK's NCSC gives similar advice. If you can't update immediately. Only an update is a complete fix. PHP lists the following measures, which reduce exposure to specific attack paths but do not make an installation safe. The advisories above have the full details. For CVE-2026-109618 (out-of-memory corruption): * Set memory_limit=-1 in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration. Check that no pool, directory or application setting puts a finite limit back. An underlying allocation failure can still reach the vulnerable path. * Set a low post_max_size: 8M if you don't need file uploads, 32M if you do. Keep upload_max_filesize below it. Consider also enforcing limits on request size, field count and multipart part count at the web server or proxy. * Use a container or cgroup limit as an availability boundary, preferably one that kills only the affected worker. Don't use RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure. For CVE-2026-109619 (stale global state): * Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration, not ini_set or .user.ini. This blocks the confirmed session paths but not other variants. * On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks only the confirmed fatal-backtrace path. * Remove invalid or deprecated settings applied per request that emit diagnostics before initialisation. Hiding diagnostics with error_reporting, display_errors or @ does not help. * Fix attacker-reachable fatal errors and execution timeouts. Signs your server may have been targeted. The flaws act below the application layer, so application logs may show little. Wiz Research suggests watching for: * Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses. * Unexpectedly large or malformed PHPSESSID cookies in responses. * Unexplained PHP worker restarts. These signs can guide an investigation but are not proof either way. If you see them, you still need to update. Also treat the server as potentially compromised, and consider rotating credentials it holds, because the flaws can also expose memory contents. Further reading. Like it? Share it. Karina Martirosova Account Executive

Spotlight: Sergei Gruntovskii on securing AI Agents at Atlas Digital Summit 2026. ATLAS Digital Summit is delighted to announce Sergei Gruntovskii, Chief Architect at CloudLinux, will be leading a critical discussion at the Atlas Digital Summit 2026 in Reykjavik, Iceland. As a distinguished expert at the forefront of server automation and security, Sergei brings an invaluable perspective to its invite-only C-level conference. Pioneering secure infrastructure. Sergei Gruntovskii's work at CloudLinux defines the technical direction for Linux platform security and server automation, impacting hosting providers globally. His deep understanding of kernel-level engineering, workload isolation, and managing vast operational fleets makes him uniquely qualified to address the complex challenges facing the industry today. The Atlas Digital Summit is dedicated to exploring the future of hosting, data centers, AI infrastructure, and security. Sergei's involvement underscores its commitment to featuring leaders who are actively shaping these domains with tangible, impactful solutions. Sergei Gruntovskii will lead the Security Track roundtable, focusing on the paramount challenge of 'Securing AI Agents Across the Hosting Fleet.' This session promises to delve into actionable strategies and advanced methodologies for protecting the integrity and performance of AI infrastructure at scale. This is a timely and crucial topic for all executives grappling with the rapid integration of AI into their operations. Attendees will gain direct insights from a technologist who navigates the intricacies of security and performance at the most fundamental levels. Join ATLAS Digital Summit to engage with Sergei Gruntovskii and other industry luminaries on September 28-29, 2026, for an unparalleled networking and knowledge-sharing experience.

MariaDB 10.6 reaches end of life on July 6. Here's how to keep your servers patched. Jun 18, 2026 8:16:39 AM If you run MariaDB on your hosting servers, there's a date worth putting on the calendar: July 6, 2026. That's when MariaDB Community Server 10.6 reaches end of life. After that, the MariaDB project stops shipping releases, bug fixes, and security patches for the 10.6 branch. Today CloudLinux Inc. is announcing ELS for MariaDB, available now to CloudLinux customers. It keeps MariaDB 10.6 patched past its end of life, delivered as drop-in updates through the package manager you already use, so you can stay secure without forcing a database migration across your customers' sites. ELS for MariaDB is built and maintained by TuxCare, its sister company and the team behind KernelCare and the Endless Lifecycle Support program. What end of life actually changes On July 7, your databases will keep serving queries exactly as they did the day before. Nothing breaks at midnight. The problem is slower and more dangerous than that, and it compounds over the months that follow. Security patches stop. After July 6, vulnerabilities in MariaDB get fixed only in supported branches. The 10.6 branch goes quiet. When a project patches a supported version, the fix is public, so attackers can study exactly what changed and work out the underlying bug, then hunt for that same flaw in the versions that will never be patched. A database engine is a high-value target: it holds the data and it's reachable from your application servers. On a shared hosting environment, an unpatched database doesn't put one site at risk. It exposes every customer site that depends on it. Compliance risk rises. Most security frameworks expect known vulnerabilities to be patched on a schedule. PCI DSS Requirement 6 calls for critical and high-severity patches within a month of release. SOC 2, HIPAA, and FedRAMP all expect timely, documented patching. An unsupported database can be the single finding that holds up an otherwise clean audit, and cyber-insurance reviews increasingly check for unsupported software too. The ecosystem drifts away. Once a version reaches end of life, the software around it gradually stops supporting it. Distributions, container images, and third-party repositories move their defaults to newer releases. Six months in, the upgrade you were putting off has quietly gotten harder, not easier. Why "just upgrade" is rarely simple for a host Upgrading to a supported release like 11.4 is the right long-term move, and CloudLinux Inc.'ll always tell you that. But on a fleet of hosting servers, a major database upgrade is a real project, not a one-line command. The engine itself rarely slows you down. What slows you down is everything that assumes the behavior of your current version: customer applications, stored procedures, replication topologies, connector versions, and the surrounding tooling. MariaDB 11.0 even introduced a new optimizer cost model, so some queries can get slower until you tune them. Multiply that testing across thousands of customer databases and a fixed deadline, and the math gets uncomfortable. Rushed upgrades are expensive in a specific way: they ship bugs, and on a hosting platform those bugs land on customer sites that were running fine for years. That shows up the next quarter as support tickets, refunds, and churn. For some servers, a major upgrade this year isn't even worth it: a database behind an application that's being replaced, or one running a fixed workload, may not justify the disruption. The point isn't that you shouldn't upgrade. It's that the upgrade should happen on a timeline you control, driven by engineering reality rather than a calendar date set by someone else. How ELS for MariaDB works ELS for MariaDB decouples security from the upgrade deadline. Here's the mechanism: * TuxCare tracks the CVEs. As new vulnerabilities are disclosed in MariaDB 10.6 and the system libraries it depends on, TuxCare backports the fixes to your open-source release. * Patches arrive as drop-in package replacements. The patched build is the same MariaDB 10.6 version, signed and published to an ELS repository. Your yum or dnf pulls it like any other update. The engine stays 10.6; only the binaries get the fix. * Your data and workflows stay untouched. No schema changes, no application rewrites, no disruption to replication or backup tooling. This is a binary swap of the same version, not a data migration. * Coverage goes beyond the engine. ELS patches MariaDB's dependency graph too: storage engines, system libraries, and crypto components, rebuilt alongside the core. What this means depending on where you run MariaDB 10.6 ELS for MariaDB covers MariaDB 10.6 (x86_64) on CloudLinux 7, 8, and 9, as well as other EL 7/8/9 systems like CentOS and Oracle Linux. Other distributions are available on request. A few specifics: On CloudLinux 8 and 9: MariaDB 10.6 loses upstream security patches on July 6 regardless of your OS support status. To keep those servers patched, you'll want ELS for MariaDB. On CloudLinux 7: if you're already on CloudLinux 7 ELS and you installed MariaDB from the CloudLinux ELS repo, those packages are already on the patched update path. If you installed MariaDB from a third-party repository, the cleanest way onto coverage is to repoint to its repo so your package manager can pull the patched builds. Not sure where your packages came from? CloudLinux Inc. can help check. Anywhere else: if you run MariaDB 10.6 on other Linux distributions, ELS for MariaDB can still keep them secure. Talk to CloudLinux Inc. and CloudLinux Inc.'ll scope it. The approach CloudLinux Inc.'d actually recommend Run ELS and your upgrade together. Use ELS to take the deadline off the table, then plan and test your move to a newer LTS release properly. In most environments, a year of coverage costs far less than the incidents, downtime, and emergency work a rushed migration creates. July 6 is close. The good news is that getting covered is quick and changes nothing about how your databases run. Existing CloudLinux customer? Enable ELS for MariaDB in the CloudLinux Network portal. Running MariaDB somewhere else, or not sure what you need? Talk to its team and CloudLinux Inc.'ll figure out coverage for your environment. ELS for MariaDB is part of CloudLinux's Endless Lifecycle Support program, in partnership with TuxCare.