📋 TL;DR

On AccelerateWP versions up to 1.9-37, enabling the Object Cache feature saved a backup of the site’s wp-config.php in the public document root, where anyone could download it. The fix shipped in accelerate-wp-1.9-38 in December 2025 and removes existing backup files automatically on update.

Affected customers were notified directly in December 2025 and January 2026. The vast majority of installations now run a fixed version, and the remaining exposure across the fleet is minimal.

If you run AccelerateWP, confirm the package is 1.9-38 or later, check that no wp-config.php.backup files remain, and rotate credentials on any site where one was present.

What happened

AccelerateWP, the performance optimization suite for WordPress included with CloudLinux, has a premium feature called Object Cache that adds Redis object caching to a site. The feature’s activation workflow had a flaw: when Object Cache was enabled on a site, the workflow saved a backup of the site’s configuration file as wp-config.php.backup, directly in the public document root.

A .backup file is treated as a static asset and served as plain text to anyone who requests it. On an affected site, https://example.com/wp-config.php.backup was downloadable by any visitor. No authentication was required.

A downloaded backup exposes the site’s database name, user, and password, along with its WordPress authentication keys and salts. With the database credentials, an attacker can read and modify the site’s database directly. With the keys and salts, an attacker can forge valid session cookies. Either path typically ends in full site compromise.

The flaw was reported to CloudLinux in December 2025 by Tom van Miltenburg of Milcraft, and the fix was released the same month. We thank him for reporting it to us privately, which let us fix it and notify affected customers before any details became public.

 

Who was affected

Two conditions had to hold:

  • the server ran accelerate-wp 1.9-37 or earlier, and
  • the Object Cache feature was enabled on the site.

Sites that never enabled Object Cache never generated the backup file and were not exposed.

 

The fix

accelerate-wp-1.9-38 stops writing the backup into the document root and, on update, automatically removes any existing wp-config.php.backup files. Every later version (1.9-39, 1.10.x) contains the fix.

As part of the post-incident response, we also ran a security design review of the affected and related components and made architectural and validation changes to prevent this class of issue in the future.

 

How to verify

Confirm the package version is 1.9-38 or later:

rpm -qa | grep accelerate-wp

Confirm no backup files remain (adjust the path if your document roots are not under /home):

find /home -type f -name "wp-config.php.backup"

This should return nothing.

 

If a site had a backup file, rotate its credentials

Removing the file stops new downloads. It does not help if someone already downloaded it. For any site where wp-config.php.backup was present:

  • Reset the database user password and update the live wp-config.php.
  • Replace the WordPress salt block with fresh values from the official WordPress generator. This invalidates all session cookies and signs every user out.
  • Where applicable, terminate active database sessions after the change.

 

Imunify360 as additional protection

On servers running Imunify360, its web application firewall blocks direct requests to wp-config.php.backup. That is defense in depth, not a reason to skip the update. The fix removes the file entirely.

 

Questions

If you run into any issues, or have questions, contact our support team.