A backup of the site can be downloaded

SeverityCritical

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_exposed_backup

Short answer

A backup file such as /backup.zip, /backup.sql or /wp-config.php.bak can be downloaded from your site. A database dump contains every user account, e-mail address and password hash; a config copy contains the database password in plain text. Delete the file from the public folder, keep backups outside the web root, and change the database password and any other credentials it contains.

Why it matters

Backup names are predictable, so bots request them on every site. A full archive gives an attacker your code, configuration and data in one download, and a .sql dump is a personal-data breach that you may be required to report under data-protection law. wp-config.php.bak or wp-config.php~ is especially common: an editor or a manual edit leaves a copy that the server sends as plain text instead of running it as PHP.

The search impact comes later, if the leak leads to a compromise: spam pages, malware and Google security warnings.

How Glimana detects it

Glimana requests a short list of common names over HTTPS: /wp-config.php.bak, /wp-config.php~, /wp-config.php.save, /backup.zip, /backup.sql, and /name.zip and /name.sql, where name is the first part of your domain. It reads only the first 2 KB and counts a file as exposed when the content matches: a ZIP header, SQL dump statements (CREATE TABLE, INSERT INTO or a MySQL, MariaDB or PostgreSQL dump header), or PHP with WordPress DB_ settings. If the server ignores the 2 KB limit and the file is too large to read, a non-HTML archive or SQL content type over 1 KB is enough. HTML pages and answers identical to a random non-existent address are ignored. Critical; a new finding also sends an immediate alert e-mail.

How to fix it

Watch out

Rotate what was exposed: the database password (update wp-config.php or .env at the same time), the WordPress salts in wp-config.php (this logs everyone out), and, if a dump was exposed, ask users to reset their passwords and check whether you must notify them. Many backup plugins protect their folder with .htaccess, which Nginx ignores; check that folder too.

Find the finding in Glimana. Open Security; this check is in the Exposed files group, with the evidence from the last scan under its title. The same problem is listed under Issues › A backup of the site can be downloaded.
Apply the fix on your platform.

WordPressApacheNginx

Delete the file over FTP or the hosting file manager. Set your backup plugin to send backups to remote storage (cloud storage or another server) rather than keeping copies in a public folder. Generate new salts at api.wordpress.org/secret-key/1.1/salt/ and replace the eight lines in wp-config.php. Edit wp-config.php on your computer or in the host's file manager, not with a server editor that leaves ~ or .save copies.

Block typical backup and editor-copy names in the virtual host or .htaccess: RewriteEngine On and RewriteRule "(\.(sql|bak|old|orig|save|swp)|~)$" - [F,NC]. Do not block .zip site-wide if you offer downloads; delete backup archives instead.

In the server block: location ~* (\.(sql|bak|old|orig|save|swp)|~)$ { deny all; }, then nginx -t && systemctl reload nginx. Keep backups in a directory outside the root, for example /var/backups/site/.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After fixing, press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes as soon as the check passes.