Hacked Static HTML Site: What Happened and How to Fix It

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

You do not run WordPress. There is no database, no login page, no plugins to be out of date. Just HTML files you wrote and upload occasionally. And somehow there is a redirect on your pages, or a folder of files you never made. The reassuring part is that the cleanup is usually much simpler than a CMS compromise. The uncomfortable part is what the entry point tells you.

How a static site gets compromised

If there is no application to exploit, the attacker did not exploit one. Almost always this means credentials: your FTP or SFTP password, your hosting control panel login, or an SSH key. Someone signed in as you and uploaded files, which is why the site itself shows no vulnerability — there was nothing to break because the door was opened with a key.

The other routes are server-side rather than site-side: another site on the same hosting account being compromised and reaching across, a vulnerability in server software rather than your content, or a compromised account at whatever service you deploy through. My guide on cross-site contamination covers the neighbour scenario.

Why credentials are the likely answer

Plain FTP transmits passwords unencrypted, which is a real risk on untrusted networks and a good reason to use SFTP instead. Beyond that, the common sources are the same as everywhere: a password reused from a service that was breached, a password saved in an FTP client on a computer that later picked up information-stealing malware, or one captured by phishing.

That last category is worth taking seriously, because a stolen credential from your own machine means the problem is not really on the server. My guide on infostealer malware on a developer machine covers how that works and what to check.

Finding what was changed

This is where static sites are genuinely easier. Sort every file by modification date and read the top of the list — on a site you update rarely, anything touched recently that you did not touch yourself is your answer. There is no database to search and no plugin tree to audit.

Look for injected script tags in your HTML files, which is the most common change, and for added files and directories: uploaded PHP, phishing page folders, or spam directories. If your host permits PHP execution, an uploaded PHP file works perfectly well on a site that is otherwise pure HTML, which surprises people. My guide on timestamp forensics covers reading the dates properly.

Cleaning it

If you have a clean local copy of your site — and most people who hand-build sites do — the fastest fix is to delete everything on the server and re-upload from your local copy. That removes every added file and every modification in one step, with no risk of missing something. It is the one genuine advantage of not running a CMS.

If you do not have a local copy, work through the files individually: remove injected scripts, delete files you did not create, and check for modified .htaccess files anywhere in the tree, which is a favourite for redirects — my guide on hacked .htaccess files covers what to look for.

Fixing the actual problem

Cleaning the files accomplishes nothing if the credentials are still compromised, because whoever uploaded those files can simply upload them again. This is the essential step, and it is the one people skip because the site looks fixed.

Change your hosting control panel password, change or delete every FTP and SFTP account, remove SSH keys you did not add, and enable two-factor authentication where offered. Do it from a device you trust. Then scan your own computers for malware, since that is a very plausible source, and switch from FTP to SFTP if you have not already.

Afterwards

Handle the downstream consequences as normal: browser and search warnings clear through the usual channels, covered in deceptive site warnings and Search Console security issues, and antivirus blocks through the vendor delisting forms.

Then keep the advantage you have. A static site with a clean local copy, strong unique credentials and two-factor authentication is a genuinely hard target, because there is no application surface to attack at all. Keep a versioned local copy so a future incident is a five-minute re-upload, and if you would rather have someone confirm the server is genuinely clear, that is what my cleanup service covers.

Related reading: Wix and Squarespace sites. See also every platform I clean.

Common questions

How can a site with no database be hacked?

Through credentials rather than code. Someone with your FTP, SFTP, SSH or control panel login can upload whatever they like, and no vulnerability in your site is required. It can also happen through another site on the same hosting account, or through the server software itself.

Can PHP files run on my HTML-only site?

On most hosting, yes. The server will execute a PHP file if one is uploaded, regardless of whether the rest of your site uses PHP. That is why a static site can end up hosting a backdoor or a phishing kit even though you never wrote a line of server-side code.

What is the fastest way to clean it?

If you have a clean local copy, delete everything on the server and re-upload. That guarantees removal of every added file and modification without needing to identify each one. It is the single biggest practical advantage of running a static site.

Is FTP safe to use?

Plain FTP sends credentials unencrypted, which is a genuine risk on any untrusted network. Use SFTP or FTPS instead — most hosts support both, and the change is usually a matter of switching the protocol and port in your client. Combine it with a unique password and two-factor authentication on the panel.

How do I stop it happening again?

Change every credential that touches the server, enable two-factor authentication, use SFTP rather than FTP, and scan your own computers for password-stealing malware. Then keep a clean versioned local copy, which turns any future incident into a quick re-upload rather than an investigation.