Security and recovery updates through September 23, 2026

There’s something reassuring about seeing a backup job finish successfully. The dashboard looks good, the customer’s website is online, and everything seems to be doing what it should.

But when a server is compromised, we need to answer a bigger question: can we actually bring that customer back?

September gave hosting providers plenty of reasons to take a closer look. We saw a compromised update channel, control panel vulnerabilities that could let one hosting account reach far beyond its own website, and backup interruptions that left operators without the fresh recovery points they expected.

There was also a reminder that the meaning of “system backup” can change between releases. A job can complete successfully while leaving out data you assumed it was protecting.

In our August roundup, we looked at the gap between having backups and being able to recover. This month, we’re building on that conversation: what does recovery look like when the software, credentials, or infrastructure you normally rely on can no longer be trusted?

Let’s walk through what happened, what needs attention, and what it means for your backups.

When a trusted update takes an unexpected route

The Virtualizor incident began in August, but the response and follow-up make it an important part of September’s roundup.

Between August 28 and August 30, a BGP hijack redirected traffic intended for part of Softaculous’s infrastructure. Put simply, internet routing was manipulated so that some traffic took a path controlled by an attacker.

Virtualizor confirmed that a malicious update reached a small number of installations. The attacker also obtained a valid TLS certificate after certificate-validation traffic was diverted. That meant a connection could look properly encrypted even though the update being delivered was malicious.

The incident lasted roughly 33 hours, with two interception waves and a gap between them.

Virtualizor released version 3.2.9.9 and a scanning tool. Its response guidance includes checking for:

/etc/systemd/system/java-jre-update.service

Operators should also rotate and restrict API credentials, review unfamiliar SSH keys and users, and check scheduled tasks. If you find the indicator above, the vendor recommends contacting its team rather than simply deleting it.

These checks are useful starting points for an investigation. A clean scan, however, is not enough on its own to establish that a previously compromised server is safe to trust again.

Softaculous reported no evidence of compromise in its other products. Being listed among the affected infrastructure domains does not, by itself, mean a product delivered malicious software. Its precautions also include resetting Client Area passwords and regenerating NOC API keys.

On September 21, Softaculous 6.4.1 added digital-signature verification for update packages and signed API responses using RSA and SHA-256. Those checks add a way to verify the authenticity of the content being received. The confirmed malicious-package delivery in this incident remains specific to Virtualizor.

What this means for recovery

If a hypervisor is compromised, snapshots stored on that same host may still be within the attacker’s reach. Your recovery plan needs a backup copy—and a way to access it—that remains available if you have to walk away from the original host.

JetBackup supports remote backup destinations, including JetBackup Premium Storage, so recovery copies can live outside the production server. Make sure the credentials, encryption keys, and instructions needed to use those backups are available independently, too.

A useful question to ask your team is: “If we couldn’t trust this server tomorrow, could we still get to our backups and restore somewhere else?”

One hosting account should stay one hosting account

Shared hosting works because customers have boundaries around their accounts. They can manage their websites, email, and databases without gaining access to everyone else’s.

Several advisories this month describe ways those boundaries can break down. The details matter here: these issues have different requirements, different impacts, and different fixes.

Developer tools deserve a place in the security review

Google Threat Intelligence’s September 8 report describes attackers publishing compromised AI developer tools and using malicious workflows to steal credentials.

In one operation observed during Q2, an attacker used an AI-assisted framework to plan, build, and execute a mass credential-harvesting campaign in under six hours.

These were earlier incidents reported in September. For hosting teams, the practical lesson is that developer environments and deployment pipelines may hold credentials with access well beyond a single application.

When you review recovery access, include the tools and workflows used to build and deploy customer websites.

cPanel, WP Toolkit, and CSF: check each component

Three separate cPanel advisories describe paths to root access, which gives an attacker control at the server level:

  • CVE-2026-65643: Domain parking and addon-domain handling. This requires an authenticated account with permission to add domains.
  • CVE-2026-67401: EmailTrack. This requires mail-related privileges.
  • CVE-2026-87899: CalDAV/CardDAV. This affects cPanel versions 120 and later.

The branch-specific patched builds are listed in the reference table at the end of this roundup.

Two additional issues affect access between accounts, but their impact is different.

CVE-2026-68490 allows a local user to read other accounts’ calendar and contact data. It does not allow that user to change the data or gain root access.

CVE-2026-87900 affects database creation in WP Toolkit and can allow an authenticated cPanel user to modify databases belonging to other accounts. WP Toolkit needs its own update to 6.11.3 or later.

CSF also has three separate advisories:

  • CVE-2026-67402 can allow code execution as the Apache user. The fix is CSF 16.31 or later.
  • CVE-2026-65638 can allow commands to run as an unprivileged service account when Messenger is enabled and a reCAPTCHA secret is configured. The fix is 16.30 or later.
  • CVE-2026-65639 can lead to root access if an attacker controls a configured remote allow/deny feed. The fix is 16.30 or later.

The risky configurations described in these CSF advisories are not enabled by default, so check your actual configuration alongside the installed version.

The takeaway is to look beyond the control panel’s update status. Extensions and supporting components may need separate updates.

Recovery also needs to include compromised credentials. JetBackup can help restore data from retained remote backups, but restoring a website will not revoke a stolen token. Replace exposed secrets, keep recovery access separate from production and deployment credentials, and check that rebuilding the application will not bring the same compromised dependency back with it.

Plesk: include backup and restore tools in your patch review

Plesk published Linux advisories covering privilege escalation through customer or reseller shell access (CVE-2026-67394) and arbitrary root-level code execution by a Plesk user (CVE-2026-67397). These have separate fixes, listed in the reference table.

Two Backup Manager issues are particularly relevant to recovery:

  • CVE-2026-68487 allows an authenticated customer to write files as root through path traversal.
  • CVE-2026-68488 involves a symlink race during a subscription restore that can ultimately give a customer root access.

Both are addressed in 18.0.80.7 / 18.0.79.11, depending on the release branch.

Sources: Path-traversal advisory, Restore advisory.

The Node.js Toolkit and Ruby extensions also have a local privilege-escalation issue, CVE-2026-68489. The published fixes are Node.js Toolkit 2.5.0 and Ruby 1.6.6.

Plesk lists Windows as unaffected by these five advisories.

Restore tools need powerful permissions to put customer data back where it belongs. That makes them an important part of the security review, right alongside the panel itself.

LiteSpeed: the build number matters

If you’re running LiteSpeed Enterprise, check the full version and build number.

cPanel’s advisory warns that a low-privilege website user could gain root access and bypass isolation controls, including CageFS. Its guidance is to install 6.3.7 Build 2 or later, even if you already installed an earlier build of 6.3.7.

The cited advisory does not assign a CVE.

This is one of those cases where “we’re on 6.3.7” needs a quick follow-up. Confirm the build before marking the update complete.

Backup plugins need updates, too

Acronis advisory SEC-10986 / CVE-2026-87886 covers local privilege escalation caused by insecure file permissions in its Linux hosting-panel integrations.

The fixed builds are:

  • cPanel & WHM: 1.9.3.1021
  • Plesk: 1.8.11.638
  • DirectAdmin: 1.2.3.238

Acronis reports limited, targeted exploitation specifically against cPanel & WHM deployments. That statement should not be read as confirmation of exploitation across every affected integration.

Liquid Web’s public incident record describes an inventory and patch-verification effort beginning September 16, monitoring on September 17, and resolution on September 18. It reported no service disruption. That provides a useful view of its response; it does not tell us whether another provider had or had not patched.

For your own review, check the installed plugin version. Seeing a backup product on the service list does not tell you whether its integration is current—or whether you could still recover if that integration became unavailable.

Customer website plugins belong on the list

The patch review also needs to reach inside customer websites.

Patchstack’s September 18 advisory lists CVE-2026-84434, an unauthenticated arbitrary file-upload vulnerability involving a hidden File Upload field in Gravity Forms. It identifies versions through 3.1.0.4 as affected and 3.1.1 as patched.

The Gravity Forms changelog also lists security enhancements in 3.1.2, released September 17. Update to the latest supported release and investigate suspicious uploads where exposure is suspected.

This is where keeping multiple JetBackup recovery points can help. If an investigation uncovers malicious files or altered site data, you have earlier copies to evaluate.

Validate the selected backup in an isolated environment, then apply the plugin update before returning the site to service. Otherwise, the same entry point may still be waiting when the restored website goes live.

Is the backup you’re expecting actually there?

Recovery gaps do not always begin with an attack. A paused schedule, a failed transfer, or a change to a job’s scope can leave you without the backup you thought you had.

This month brought examples of all three.

Contabo: check how recent the backup is

Contabo’s September 8 Object Storage incident remained open in its September 23 update. Automated backups to the affected cluster were still paused.

The company said existing backups were unaffected and restores continued to operate normally.

For affected workloads, the concern is backup freshness. The incident does not establish that retained backups were deleted, that every Auto Backup customer was affected, or that restores were unavailable.

Check the timestamp of the newest usable recovery point and compare it with how much recent data the business can afford to lose. An older backup can still be useful, but it may leave a larger gap than the customer expects.

OVHcloud: an available database can still miss backups

OVHcloud’s MongoDB incident record identifies a daily-backup interruption from August 25 at 00:00 UTC to September 3 at 13:00 UTC, with formal resolution posted September 4.

The company attributed the disruption to an underlying infrastructure malfunction. The record concerns backup creation; it does not establish that restoring existing backups was unavailable.

Managed services still need recovery-point monitoring. Checking that a database is running and checking that its latest backup completed answer two different questions. Both belong in your routine review.

Plesk: test getting backups out and bringing them back

Plesk’s 18.0.81 release notes list PPPM-15485, a fix for remote FTPS backups failing in passive mode against certain FTP servers. The issue involved the TLS data connection not resuming correctly.

The September 21 entries for 18.0.81 Update 1 and 18.0.80 Update 8 do not name this issue, so those entries do not independently confirm an 18.0.80 backport.

Plesk staff also confirmed PPPM-15524, a backup download problem involving Chrome retrying an interrupted POST request as GET. The forum response lists Firefox or renaming the affected .crdownload file to .tar as workarounds, with no fix ETA in the cited response.

The rename applies to that reported case. It cannot repair an incomplete archive, so verify the downloaded backup before relying on it.

Neither issue is presented here as a security vulnerability. They still matter to recovery: the backup has to reach its destination, and you need to be able to retrieve a usable copy when it’s time to restore.

DirectAdmin: take another look at “system backup”

DirectAdmin 1.709, released August 31, changed the system-backup script. Its changelog explicitly calls out breaking changes:

  • User home directories are excluded.
  • User-owned MySQL databases are excluded.
  • da_roundcube remains included.

DirectAdmin describes this backup as intended for global system files.

If your recovery plan treated this job as a complete customer backup, it needs a review. The job can finish successfully while customer homes and databases remain outside its scope.

Check the contents of an actual backup and confirm that another job protects the customer data you need.

With JetBackup, you can manage schedules, retention, and account coverage, along with job monitoring and notification integrations. Use those settings to match backup frequency to customer needs, then check the recovery points actually stored at the destination.

The schedule tells you what should happen. The stored backup tells you what did happen.

A recovery that worked

There was also a useful recovery example this month.

Hostinger’s September 17 report describes a September 16 attack on one shared server in Brazil. The company says a LiteSpeed vulnerability affecting versions before 6.3.7 Build 2 allowed root-level access.

Hostinger isolated the affected server, deployed the fix, restored affected websites from backups taken before the attack, and moved them to a new server.

That is the kind of outcome a recovery plan is meant to support. The report does not provide enough detail about backup storage or permissions to credit a particular isolation or immutability design. It does show the value of having recovery points from before an incident and a replacement environment ready for the restored sites.

Nexcess’s September 10 StyleSmuggler update also describes patch deployment, scanning, and validation to help affected sites return to a known-good state.

In both cases, restoring data is part of a wider response that includes addressing the vulnerability and checking the result.

When malware keeps coming back

If you’ve ever cleaned up a website only to see the infection return, you know how frustrating that cycle can be.

Monarx’s September 14 update describes a WordPress infection with persistence mechanisms across files, databases, WP-Cron, active themes, and the administrator’s browser. Its components can restore one another, allowing the infection to return after an apparently successful cleanup.

Removing the visible malicious file may only address one part of the problem.

For recovery, the next step is to work out when the infection began and validate both files and databases before bringing the site back online.

Keeping multiple JetBackup recovery points gives you more options when the newest backup already contains malicious changes. You still need to investigate and test the selected copy to establish whether it is safe to restore.

JetBackup Premium Storage with properly configured Object Lock can protect retained backup versions against alteration or deletion during their lock period, subject to the version and configuration requirements below. That protection helps preserve your recovery options while you determine which backup to use.

Four checks worth making now

There is a lot in this month’s roundup, but you can turn it into a manageable review.

  1. Check the installed versions across the stack. Include the control panel, web server, firewall, extensions, and backup plugins. Use the latest supported patched release for your branch. The reference table below records the advisory minimums.
  2. Open an actual recovery point and test it. Confirm the timestamp and contents, then restore a representative customer account into an isolated environment. Include files and databases, and check that the application works.
  3. Make sure recovery access survives the loss of production. Keep the credentials and encryption keys you need available outside the production panel. Review what an attacker with root access could read, overwrite, or delete on remote storage using credentials held by the server.
  4. Verify retention protection in your deployed setup. Where supported, confirm that immutability is enabled and covers the recovery window you need. An available feature does not automatically protect existing backups.

That fourth point also applies to how we describe our own products.

As of this review, JetBackup’s changelog lists 5.4.2.0 and 5.4.2.1 in the Alpha tier. The 5.4.2 work includes S3 Object Lock, with configuration documented in the Alpha guide. It should not be described as generally available Release-tier functionality.

At JetBackup, we want operators to be able to demonstrate recovery. When you use JetBackup and JetBackup Storage, review the deployed version, destination permissions, retention settings, and recovery procedure together.

A good place to start is one customer account. Check what its backup contains, restore it somewhere safe, and make sure you can complete the process without depending on the server you’re trying to replace.

That turns “we have backups” into something much more useful: confidence that you can bring a customer back.

Patch and recovery reference

The table below records fixes named in the cited advisories. It is not a complete vulnerability inventory, and the minimum versions should not be read as a recommendation to remain on an older branch.

cPanel’s September 22 CalDAV/CardDAV issues affect v120 and later. Plesk version pairs are alternatives for their corresponding release branches.

CVE / IDProductReported impactPatched builds / actionScope and conditions
BGP incident, August 28–30Virtualizor update pathConfirmed malicious update delivered to a small number of installations3.2.9.9 plus scan script and vendor response guidanceNo malicious package identified for Softaculous, Webuzo, Backuply, or SitePad
CVE-2026-65643cPanel parked/addon domainsAuthenticated account can write arbitrary files and reach root11.110.0.141 / 11.134.0.53 / 11.136.0.37 / 11.138.0.2+; WP2 11.138.1.7+August 27; requires permission to add domains
CVE-2026-67401cPanel EmailTrackMail-related privileges can lead to arbitrary file writes and root11.110.0.143 / 11.134.0.55 / 11.136.0.39 / 11.138.0.4; WP2 11.138.1.9September 8; separate from the domain-handling issue
CVE-2026-87899cPanel CalDAV/CardDAVAuthenticated account can escalate to root11.134.0.57 / 11.136.0.41 / 11.138.0.8; WP2 11.138.1.11+September 22; affects v120 and later
CVE-2026-68490cPanel CalDAV/CardDAVLocal user can read other accounts’ calendar and contact dataSame patched builds as CVE-2026-87899September 22; affects v120 and later; does not allow modification or grant root
CVE-2026-87900WP Toolkit database creationAuthenticated user can modify databases belonging to other accountsWP Toolkit 6.11.3+September 22; separate component update; no root-access claim
CVE-2026-67402CSF MessengerUnauthorized code execution as the Apache userCSF 16.31+Messenger is off by default; separate Messenger issue
CVE-2026-65638CSF MessengerUnauthenticated code execution as an unprivileged service accountCSF 16.30+Requires Messenger and a configured reCAPTCHA secret; neither is enabled/configured by default
CVE-2026-65639CSF advanced-rule parserRemote root access through an attacker-controlled allow/deny feedCSF 16.30+No remote feed is configured by default
CVE-2026-67394Plesk, MU5Customer/reseller shell access can lead to root18.0.79.9 / 18.0.80.5Windows unaffected
CVE-2026-67397Plesk, MU6Plesk user can execute arbitrary code as root18.0.79.10 / 18.0.80.6Windows unaffected
CVE-2026-68487Plesk Backup ManagerUnsigned header / path traversal allows root-level file writes18.0.80.7 / 18.0.79.11Authenticated customer; Windows unaffected
CVE-2026-68488Plesk Backup ManagerSymlink race during restore can lead to root18.0.80.7 / 18.0.79.11Subscription restore; Windows unaffected
CVE-2026-68489Plesk Node.js Toolkit / RubyLocal privilege escalation to rootNode.js Toolkit 2.5.0+; Ruby 1.6.6+Windows unaffected
LiteSpeed advisoryLiteSpeed EnterpriseLow-privilege website user can reach root; CageFS bypass possible6.3.7 Build 2 or laterCheck the build number; no CVE assigned in the cited cPanel advisory
SEC-10986 / CVE-2026-87886Acronis backup plugin/extensionLocal privilege escalation through insecure file permissionscPanel 1.9.3.1021; Plesk 1.8.11.638; DirectAdmin 1.2.3.238Reported limited, targeted exploitation specifically concerns cPanel & WHM
PPPM-15485Plesk FTPS remote backupBackup transfer failure; not a CVEFix named in Obsidian 18.0.81 Fixed Product IssuesPassive-mode TLS connection issue; September 21 entries for 18.0.81 Update 1 and 18.0.80 Update 8 do not confirm an 18.0.80 backport
PPPM-15524Plesk backup downloadChrome resume can produce home.html; not a CVENo fix ETA in cited staff responseFirefox or renaming the affected .crdownloadfile to .tar are reported workarounds; verify archive completeness
DA 1.709 sysbkDirectAdminUser homes and user-owned MySQL databases excluded from system backupsReview backup scope following 1.709, released August 31Documented breaking change; da_roundcuberemains included; not a vulnerability
CVE-2026-84434Gravity FormsUnauthenticated arbitrary file upload3.1.1 per Patchstack; use the latest supported releaseAdvisory published September 18; affected versions through 3.1.0.4; involves a hidden File Upload field; 3.1.2 includes additional security enhancements

As we close this month’s security roundup, the message for hosting providers is clear: security and recovery must be planned together. The incidents covered this month show how vulnerabilities, compromised credentials, and interrupted backup processes can put customer data and business continuity at risk.

AI adds another dimension to that challenge. Attackers are using AI-assisted tools to accelerate parts of their operations, while compromised developer tools create additional opportunities to steal credentials. As these threats evolve, organizations need confidence in both their defenses and their ability to recover when those defenses are breached.

That makes choosing a trusted backup partner more important than ever. Trust should be supported by dependable backups, clear documentation, responsive support, and recovery procedures that can be tested. Independent access, appropriate retention, and verified recovery points all contribute to restoring services with confidence.

At JetBackup, our monthly security roundup is part of an ongoing commitment to helping hosting providers understand emerging threats and make informed recovery decisions. We encourage every provider to use these updates as an opportunity to review protections, address vulnerabilities, and test a restore. Protecting customer data is a continuing responsibility, and a reliable backup partner is an essential part of meeting it.