--- title: Old Site Copies Are a Security Risk description: Abandoned staging folders, /old directories and backup zips are a common way into a hosting account. Here is how to find and clear them out. date: 2026-09-21 updated: 2026-09-21 tags: [security monday, wordpress, hosting account] url: "https://drivenhost.com/blog/old-site-copies-risk" author: DrivenHost --- Most of the compromised sites we clean up were not broken into through the live site. The way in was a copy of it. A staging folder nobody has opened in two years, an `/old` directory left behind after a redesign, a zipped backup sitting in the web root where anyone can download it. Back for another Security Monday, and this one is about the files you forgot you had. ## Where old copies come from Nobody sets out to leave a second website on their account. It happens the way most things happen on a site that has been running for a decade. A designer builds the new version in `/new`, points the domain at it when it launches, and never removes the old one. A migration from a previous host copies everything across twice. Someone clones the site to test a theme change. A backup plugin writes `.zip` files inside `public_html` instead of somewhere private. Every one of those was reasonable at the time. The problem is what happens after, when the copy stops being maintained but keeps being reachable. ## Why the copy is riskier than the live site Your live site gets attention. Plugins get updated, you notice when something looks off, you read the odd security post. The copy gets none of that. Its WordPress core, its plugins and its themes are frozen on the day it was abandoned, which means every vulnerability published since then is still sitting there unpatched. Scanners do not need a link to find it. They work through a short list of guessable directory names: `/old`, `/new`, `/dev`, `/staging`, `/test`, `/backup`, `/site2`, `/wp-old`. If one of those returns a WordPress install, the scanner starts working through known vulnerabilities in whatever it finds. No human is involved, and the fact that the copy is not linked from anywhere makes no difference at all. Then there is the part that catches owners out. An old install usually lives in the same hosting account, under the same user, with the same file ownership as the live site. PHP executing inside the abandoned folder can generally read and write files in the folders beside it. So a break-in there is not contained to there. When we trace a defaced homepage back to its origin, the entry point is very often a directory the owner had genuinely forgotten about. We wrote about what this looks like from the server side in [what a hacked site looks like from our end](/blog/hacked-site-server-view). ## Find what is actually on your account Open File Manager in cPanel and look at the top level of `public_html` with dates showing. You are looking for three things. Directories that contain a `wp-config.php` file. Each one of those is a separate WordPress installation, with its own database and its own update schedule. Most sites should have exactly one. Archive files anywhere under the web root: `.zip`, `.tar.gz`, `.sql`, anything with a date in the filename. A database dump sitting in a web-accessible folder can be downloaded by anyone who guesses the name, and it contains your users table. Subdomains and addon domains you do not recognize. Check the subdomain list in cPanel against the sites you actually run, and check your autoinstaller's list of installations, which often remembers copies you do not. Write down what you find before you touch anything. Knowing which folder the live site actually runs from is worth five minutes. ## Delete, or lock it down properly Deleting is the right answer far more often than owners expect. If the copy has no job, it has no reason to be there. Take a full backup off the server first and confirm you can open it, then remove the folder and its database. Old installs usually have databases too, and leaving those behind wastes space and keeps stale credentials alive. If you are not sure your backup would actually restore, that is worth settling first: [backups that actually restore](/blog/backups-that-restore) covers how to check. If a copy genuinely has to stay, treat it as a live site. Move it out of the web root if you can, password-protect the directory, keep it out of search engines, and update it on the same schedule as everything else. A copy you maintain is fine. A copy you only intend to maintain is the same risk as before. ## Running staging without leaving debris Staging is useful and we are not arguing against it. The trouble is staging sites that outlive their purpose. Give one a deadline when you create it, put it behind a directory password, block indexing, give it its own database and its own credentials rather than sharing the live ones, and remove it when the change goes out. If you find yourself keeping a staging copy permanently, it deserves the same update routine as production, on the same [hosting account](/hosting) you are already paying attention to. Set aside twenty minutes this week and look through your file manager with fresh eyes. Most owners find at least one thing they had forgotten. If you open a folder and cannot work out whether the live site depends on it, do not guess and do not delete it: [get in touch with our support team](/support) and we will check the account and tell you what is safe to remove.