Book a demo
Book a demo
Login

SECURITY RESPONSE RECORD

Zero-Day Vulnerabilities, Protected Before the Official Fix

A zero-day vulnerability is a flaw attackers can use before an official fix exists. When one hits Linux, PHP or WordPress, we protect servers connected to xCloud with a temporary fix, then patch them once the official fix is out. This record lists every response, with dates.

Start free
  • No SSH, no tickets, no action needed
  • xCloud Managed and Self-managed servers
  • Every date published
8 hPHP2Shell temporary fix, live before PHP's official fix11 daysKernel TCP protection, before Ubuntu's official fix< 1 dayDirty Frag temporary fix, after a public exploit10,000+servers protected by the Copy Fail and Dirty Frag temporary fixes

THE RECORD

Every Vulnerability We Responded To, With Dates

Newest first. Each entry shows when the vulnerability was disclosed, when servers were protected, when the official fix came out and when we patched. Zero-day marks the entries where servers were protected before any official fix existed. Filter by the part of the stack it hit.

Filter by layer
  • Disclosed
  • Protected
  • Official fix
  • Patched

  1. Linux kernel TCP vulnerability

    CVE-2026-98432CVSS 9.8

    Security updateLinux kernel

    Protected 11 days before Ubuntu's official fix

    1. Disclosed:CVE published
    2. Protected:Temporary fix: firewall rule on connected servers
    3. Official fix:Ubuntu releases its official fix

    A Linux vulnerability an attacker can use from the internet through any open port, without logging in. Ubuntu had no official fix, so our temporary fix added a firewall rule that blocks the traffic the attack needs and switched off two rarely used network features in Linux, with no downtime. Once Ubuntu's official fix was out, servers were patched through automatic security updates.

    Covered: xCloud Managed and Self-managed serversFull response

  2. MariaDB security update

    CVE-2026-107814 to CVE-2026-107823Up to 8.4

    Security updateDatabase

    Patched in stages, with 72 hours' notice

    1. Disclosed:CVE records published
    2. Protected:New servers install only the fixed version
    3. Patched:Staged patching starts, after a 28 Oct email and 72 hours' notice

    A group of MariaDB vulnerabilities, with official fixes in the 10.6 to 13.0 releases. New servers were protected first. Existing servers got an email, a Patch Date 72 hours later and an Update now button, then were patched to the official fix for their own branch in their update window. Ubuntu 20.04 servers get the security settings only, because the official fix is not built for it.

    Covered: xCloud Managed and Self-managed servers running MariaDBFull responsev2.9.7.2 notes

  3. PHP session upload progress

    CVE-2026-115560Lower risk (PHP)

    Zero-dayPHP

    Protected 2 days before it was disclosed

    1. Protected:Setting turned off on all connected servers
    2. Disclosed:PHP publishes its advisory

    PHP's advice for this vulnerability is to turn off one PHP setting (upload progress tracking). We had already turned it off on every server connected to xCloud on 21 October, as part of the PHP2Shell temporary fix, and it stays off after patching. New PHP installs get it too.

    Covered: xCloud Managed and Self-managed serversFull response

  4. PHP2Shell

    CVE-2026-109618CVE-2026-109619CVSS v4.0 9.2

    Zero-dayPHP

    Temporary fix 8 hours before PHP's official fix, patched the same day

    1. Disclosed:PHP announces the security release
    2. Protected:06:00 UTC: temporary fix starts on every server
    3. Official fix:14:00 UTC: PHP 8.2.35 to 8.5.12 released
    4. Patched:18:24 UTC: automatic patching starts

    Two critical remote code execution vulnerabilities in PHP itself. From 06:00 UTC on 21 October our temporary fix reached PHP on every connected server. PHP released its official fix at 14:00 UTC, and from 18:24 UTC we patched NGINX and OpenLiteSpeed servers, then checked that each site served the fixed version. More than 95% of servers were patched two days later.

    Covered: xCloud Managed and Self-managed serversFull responsev2.9.4 notesChecklist for any host

  5. Fragnesia

    CVE-2026-46300

    Zero-dayLinux kernel

    Already protected when it was disclosed

    1. Protected:Dirty Frag temporary fix already protects against it
    2. Disclosed:Disclosed with a public exploit

    A Linux kernel privilege escalation in the same family as Dirty Frag, with a public proof of concept. Our Dirty Frag temporary fix had already switched off the parts of Linux the attack needs, so servers were protected on the day it was disclosed.

    Covered: xCloud Managed and Self-managed serversFull response

  6. Dirty Frag

    CVE-2026-43284CVE-2026-43500

    Zero-dayLinux kernel

    Temporary fix the next day, before any official fix

    1. Disclosed:Embargo breaks, exploit public
    2. Protected:Temporary fix on all connected servers

    A Linux kernel root exploit whose embargo broke, so a working exploit was public before any distribution had an official fix. Our temporary fix switched off the parts of Linux the attack needs on every connected server, with no downtime and no reboot.

    Covered: xCloud Managed and Self-managed serversFull responsev2.5.5 notes

  7. Copy Fail

    CVE-2026-31431CVSS 7.8

    Security updateLinux kernel

    Temporary fix 2 days after disclosure, no reboot

    1. Disclosed:Disclosed with a public exploit
    2. Protected:Temporary fix on all connected servers

    A Linux kernel vulnerability that lets any local user become root, with a 732-byte public exploit. Our temporary fix switched off the part of Linux the attack uses on more than 10,000 servers, checked it stayed off, and built new servers with it off too.

    Covered: xCloud Managed and Self-managed serversFull responsev2.5.3 notes

  8. Modular DS plugin

    CVE-2026-23800CVSS 10.0

    Zero-dayWordPress plugins

    Zero-day blocked by Patchstack, sites patched

    1. Protected:Zero-day blocked, sites patched to 2.5.2
    2. Patched:CVE-2026-23800: sites patched to 2.6.0

    Two critical vulnerabilities in the Modular DS (Modular Connector) WordPress plugin. The first, a zero-day, was blocked on sites with Site Security PRO powered by Patchstack, and every affected site was patched to 2.5.2. Two days later a second one followed, and we patched every affected site to 2.6.0 without waiting for owners. Owners were told by email.

    Covered: WordPress sites with the pluginv2.2.3 notesv2.2.4 notes

  9. LiteSpeed Cache plugin

    CVE-2024-28000

    Security updateWordPress plugins

    Sites patched to the official fix

    1. Patched:Plugin patched to 6.4.1 on customer sites

    An unauthenticated privilege escalation in LiteSpeed Cache 6.3.0.1 and older. We patched the plugin to 6.4.1, its official fix, on customer sites instead of waiting for each owner to do it.

    Covered: WordPress sites with the pluginv1.4.7 notes

  10. OpenSSH regreSSHion

    CVE-2024-6387

    Security updateSSH

    Patched with Ubuntu's official fix

    1. Disclosed:Disclosed by Qualys
    2. Patched:Patched in v1.4.4 with Ubuntu's official fix

    A remote code execution vulnerability in the OpenSSH server. We patched servers with Ubuntu's official fix in v1.4.4.

    v1.4.4 notes

HOW WE RESPOND

What Happens on Day Zero

Usually the same four steps, run from the platform across every connected server instead of one SSH session at a time.

  1. Assess the same day

    We read the advisory and early reports, and check which servers and versions are in scope.

  2. Protect before the official fix

    If no official fix exists yet, a temporary fix goes out to every connected server: a firewall rule, switching off part of Linux or a PHP setting.

  3. Patch when the official fix is out

    We install the official fix automatically and restart services, so the fixed version is the one running.

  4. Verify, then tell you

    We check the real state of each server, not just that a script ran, and tell each team what we did. For automatic rollouts like PHP2Shell, servers that were offline are retried daily.

YOUR SERVER, ON YOUR OWN

Running Servers Alone Means Reading Every Advisory Yourself

A bare server leaves this work to you, at whatever hour a vulnerability is disclosed. This is the list of jobs, and what xCloud does instead.

Scroll the table sideways to compare.

On your ownWith xCloud
Watch mailing lists, CVE feeds and vendor blogs, and work out which of your servers are affected.We track Linux, PHP, database and WordPress advisories and check which servers are in scope.
Wait for your distribution's official fix, or write and test your own temporary fix at 2 a.m.A tested temporary fix goes out to every connected server, often before the official fix exists.
SSH into each server, one by one, and hope none were missed or offline.One rollout covers every connected server. For automatic rollouts like PHP2Shell, offline servers are retried daily.
Restart PHP and services, and confirm the new version is the one actually running.After we patch PHP, it is restarted and checked, so the fixed version is the one serving your sites.
Find out about a plugin vulnerability when your site is already hacked.Daily vulnerability scans on paid plans, and Patchstack virtual patching blocks attacks before a plugin update exists.

SECURITY ON EVERY SERVER

The Security Built Into Every xCloud Server

The response record above is the emergency path. These run every day, on xCloud Managed and Self-managed servers alike.

  • Site Security PRO by Patchstack

    Virtual patching for WordPress plugins, themes and core, real-time vulnerability alerts and early warning of new vulnerabilities.

  • WordPress vulnerability scanner

    A daily check of core, plugin and theme versions against known vulnerabilities, with one-click updates for vulnerable plugins.

  • Automatic security updates

    Ubuntu's security patches install on their own, with an optional reboot window. PHP, database and Redis patches can be included.

  • Built-in firewall (7G/8G)

    The built-in firewall blocks SQL injection, script injection and bad bots at the web server, before WordPress or PHP starts. One switch per site.

  • Firewall management

    Allow or deny traffic by port and IP address with firewall rules from the dashboard, and ban an IP address in one step.

  • Security headers

    Every site sends a basic set. Add HSTS, CSP and more on WordPress sites with presets in Site Rules, a PRO feature.

Related: Self-managed hosting, Site Security PRO, Automatic security updates, Security incident checklist.

Zero-Day Vulnerability FAQs

What a zero-day is, what xCloud does when one lands and what is still yours to do.

What is a zero-day vulnerability?

A zero-day vulnerability is a security flaw that attackers can use before the software's maker has released an official fix. The name counts the days defenders have had to patch: zero. Until the official fix is out, the only protection is a temporary fix, also called a mitigation, such as switching off the vulnerable feature or blocking the traffic the attack needs.

What is the difference between a zero-day and a CVE?

A CVE is the public ID a vulnerability gets, such as CVE-2026-109618. A zero-day describes timing: the vulnerability is known or exploited before an official fix exists. Many CVEs are never zero-days, because the official fix comes out the same day they are disclosed.

Does xCloud patch zero-day vulnerabilities on Self-managed servers?

Yes, on servers connected to xCloud. The temporary fixes for Copy Fail, Dirty Frag, PHP2Shell and the kernel TCP flaw, and the PHP2Shell and MariaDB patches, went out to xCloud Managed and Self-managed servers alike. During the PHP2Shell rollout, servers that were offline were retried daily.

Self-managed hosting

Do I need to do anything when a vulnerability hits?

Usually not. Temporary fixes and patches go out automatically and each team gets an email listing its servers. The common exception is a kernel patch, which only takes effect after a reboot: restart from the server's Security Update page, or turn on Automatic Reboot.

How automated security updates work

Does a temporary fix replace the official fix?

No. A temporary fix closes the attack path until the official fix exists. Once the official fix is out, we patch your server with it, and the temporary fix usually stays in place as an extra layer.

How does xCloud protect WordPress plugins before an update exists?

Site Security PRO, powered by Patchstack, is a per-site add-on. When a vulnerability is found, Patchstack's protective rules block attacks on it until the official fix is out. The built-in vulnerability scanner checks every WordPress site daily on paid plans.

Site Security PRO

Is running a bare server risky?

It is not unsafe by itself, but every vulnerability becomes your job: noticing it, writing a temporary fix, patching each server and checking the result, at any hour. A control panel that patches for you removes that gap.

Let Us Take the Next Zero-Day Off Your Plate

Bring your own server or use ours. Either way, we work on the next vulnerability for you and tell you what we did.

Start freeBring your own server