WordPress Site Hacked? What to Do in the First 24 Hours (October 2026)

A WordPress site has been hacked when it does things nobody set up: it redirects visitors elsewhere, shows spam pages in Google, has admin users nobody created, or gets flagged by Google, your host or antivirus software. WordPress's own FAQ for hacked sites calls these indicators of compromise. The usual ones:

• Redirects that only some people see. A lot of infections redirect only visitors who arrive from Google, or only phones, and leave logged-in admins alone. So "it looks fine to me" proves nothing. Test on your phone over mobile data, clicking through from a Google search.
• Spam pages in Google. Search site:yourdomain.com.sg and look for pages you never wrote: Japanese text, pharmacy products, casino or loan pages. Sucuri found SEO spam on 20.30% of the infected websites in its 2023 data.
• Admin users you don't recognise. In WordPress, open Users and filter by Administrator. Sucuri found at least one malicious admin user on 55% of the sites it saw with database malware in 2023, planted so the attacker can log back in.
• A warning from someone else. A red Google Safe Browsing page, a Search Console email about security issues, a suspension notice from your host, or customers saying their antivirus blocked your site.
• Strange server behaviour. For PHP2Shell, Wiz and CISA list unusual multipart requests followed by memory-limit errors, repeated HTTP 500 errors, oversized PHPSESSID cookies and PHP workers launching shells or downloading tools. Your host or developer can look for those in the logs.

Two free checks take two minutes. Look your domain up on Google's Safe Browsing site status, and open the Security Issues report in Google Search Console if your site is verified there. If nothing looks wrong but you want to know whether you're exposed to this week's PHP flaw, send me your web address for a free PHP check. I'll look at which PHP version it runs, what it's built on and how old its theme and plugins are, and tell you what I find.

Containing a hacked WordPress site means stopping it from hurting visitors or leaking more data, without deleting anything yet. The PDPC and CSA's joint incident checklist, printed in the PDPC's data breach guide, starts the same way. It calls the process C.A.R.E: Contain, Assess, Report, Evaluate. For a website, containing it looks like this:

1. Tell your host. On shared hosting, an infection can reach other sites on the same server, and most hosts will isolate the account and help with logs. Ask what backups they hold and how far back they go.
2. Take the site offline if it's attacking visitors. If it serves malware, a phishing page or a fake card form, put up a maintenance page or ask the host to suspend it. A few hours offline costs less than a customer's card details.
3. Switch off payments if it's a shop. In WooCommerce, disable the payment gateways so nobody types card details into a checkout you no longer trust.
4. Don't delete or restore anything yet. The infected files are evidence, and a restore wipes them. That comes after step 2.

If someone has emailed demanding money, whether to "fix" the hole or to keep your data off a forum, keep the email and don't reply. Step 8 covers who to send it to.

Before you clean anything, take a full copy of the hacked site, files and database, and download the server logs, because they're the only record of how the attacker got in and what they touched. WordPress's hardening guide puts it simply: backups from before the compromise help you rebuild, and backups from after it help you work out how it happened.

• Files and database. Use a cPanel backup, your host's snapshot tool or a plugin export. Store it off the server and name it clearly as infected, so nobody restores it by mistake.
• Access and error logs. In cPanel they sit under Raw Access and Errors. Shared hosts often keep only a few days of raw logs, so this one can't wait until next week.
• A short written timeline. What you saw, when (Singapore time), and anything that changed recently: a new plugin, a theme edit, a staff member leaving. WordPress's FAQ calls this the start of your incident report.
• Screenshots of the redirect, the spam pages and any message from the attacker.

If customer data sat on the site, the logs are how you find out what the attacker could reach, and the PDPC's guide says you must document every step of assessing a breach. Without logs, you may have to assume the worst.

After a hack, change every credential that touches the site: hosting, SFTP or FTP, the database, every WordPress admin, email on the domain, the domain registrar and DNS, and any API keys stored in plugins. WordPress's FAQ says to reset all access points, then change the passwords again once the site is clean. This is the list I work through:

Do it from a computer you trust. WordPress's FAQ points out that some attacks start with malware on the owner's own laptop, capturing FTP and admin logins as they're typed. Then switch on two-factor login for the host, the registrar, email and WordPress.

Remove old developers and agencies too. The person who built the site in 2019 may still have an admin account, an FTP login or a server key. In a PDPC decision published in 2024, a Singapore ferry operator's server was accessed with root credentials first given to the contractor who set up its booking website in 2019, which nobody had switched off. The attacker took the passport details of 108,488 customers and emailed ransom demands, and the PDPC fined the operator S$28,000 (Horizon Fast Ferry, [2024] SGPDPC 1).

Restore from a backup when you have one from before the infection began and can patch the hole straight after; clean the site by hand when you don't, or when the infection is older than every backup you hold. The catch is the date. Attackers usually leave a backdoor, a hidden way back in, before doing anything you can see. Sucuri's 2023 hacked website report, drawn from 39,594 sites its team cleaned plus its scanners, found at least one backdoor on 49.21% of compromised websites. Last week's backup may already have one in it.

A proper manual clean, in outline:

1. Replace WordPress core. Delete /wp-admin and /wp-includes and upload fresh copies of the same version, as WordPress's FAQ recommends. Skip the dashboard's reinstall button: it overwrites files but leaves the attacker's extra ones in place.
2. Reinstall every plugin and theme from its official source. Delete the ones you don't use, and any "nulled" (pirated) premium plugin, which can come with malware already inside.
3. Look for PHP files in /wp-content/uploads, which should only hold media, and check .htaccess, wp-config.php and the mu-plugins folder for code nobody on your side added.
4. Check the database for unknown admin users, spam posts, and scripts injected into options and widgets.
5. Scan with a server-side scanner such as Wordfence or Sucuri's plugin, then with an outside one.

One warning about that last step. An outside scanner only sees what your pages send to a browser, so a clean result isn't a clean bill of health. My guide to free website security scanners explains what each one can and can't see.

Most WordPress sites are broken into through an outdated plugin or theme, a weak or reused password, or an unpatched server, and you need to know which, or the site will be reinfected. Patchstack's State of WordPress Security in 2026 counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and just six in WordPress core. Two more of its numbers explain why "I'll update next month" doesn't work:

• 46% of those vulnerabilities had no fix from the developer by the time they were made public.
• For the heavily exploited ones, the weighted median time to the first attack was five hours.

WordPress's hardening guide names the two most common attacks: requests crafted for a specific known vulnerability, and brute-force password guessing. The logs from step 2 usually point to one of them. Find the earliest file the attacker changed, then read the requests to the server just before that time. A run of POST requests to one plugin's file points at that plugin. A successful admin login from a country you've never been to points at a password.

The PHP layer is the one most guides skip. PHP2Shell sits in PHP itself, and PHP's advisory says that on servers running mod_php, a demonstrated exploit fires "before any application code runs". Wordfence and other security plugins are application code, so they can't be relied on to stop it. And if your server runs PHP 8.1 or older, the PHP project isn't releasing a fix for those versions at all.

Don't mix it up with wp2shell, which searchers often do. That one was a flaw in WordPress core itself, published in July 2026 and fixed in WordPress 6.9.5 and 7.0.2 (Rapid7's write-up). If your site was still on 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1 when it was hacked, that's a strong suspect too. And if the logs are gone, treat every plausible door as open.

Before the site goes back online, update WordPress core, every plugin and theme, and the server's PHP version, then delete anything you don't use. For PHP2Shell, the fixed releases from 21 October 2026 are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP urged every user to update immediately (php.net). Checking your PHP version takes a minute in WordPress, under Tools, Site Health, Info, Server, but read the number with care. Site Health judges the PHP branch, not the patch level, so a green result doesn't mean you're patched. And Linux vendors often fix PHP without changing its number: Ubuntu 22.04's patched PHP still reports 8.1.2. Your host's changelog is the definitive answer.

Who updates PHP depends on your hosting:

• Shared hosting: the host patches PHP. SiteGround says it patched all its servers on 21 October. With any other host, ask rather than assume. If your host has already patched it, that part costs you nothing.
• A VPS or cloud server: nobody patches it unless someone is paid to. Three years after launch, that someone is often nobody.
• PHP 7.4, 8.0 or 8.1: sites get pinned there because "a plugin breaks on 8.x", and WordPress.org's own stats put about 36% of WordPress sites on 8.1 or older. Those versions get no update from the PHP project.

Sources disagree on what to do with a site that can't be patched yet. CISA's advice is to take unpatched PHP systems offline until they are fixed. Sansec, which watches online shops, said on 22 October that mass exploitation looks less likely than it expected on release day and that "you do not need to take your store offline", while still telling everyone to update PHP. For a site that has just been hacked, I'd keep it offline until it's patched anyway: you already know someone got in.

PHP 8.2 itself reaches end of life on 31 December 2026. A site moving up to 8.2 this week will need to move again in about ten weeks, so go to 8.3 or 8.4 if your plugins allow it.

Google removes a hacked-site warning after you fix the problem and request a review in Search Console's Security Issues report, and Google says a review "can take from a few days to a few weeks". Its Security Issues help page asks you to explain the problem, the steps you took and the result. Three things I'd do:

• Make sure every spam URL now returns a 404 or 410 error, so Google drops those pages from its results.
• Don't ask for a review until the site really is clean. Google warns that asking before the issue is fixed can make the next review take longer.
• Check the Safe Browsing status again a few days later, and look in Bing Webmaster Tools in case Bing flagged the site as well.

In Singapore, report a hacked website to SingCERT through CSA's Cyber Aid page, make a police report if there's extortion or theft, and if personal data was involved, assess within 30 days whether the PDPC has to be notified. Each one does a different job.

• SingCERT, part of the Cyber Security Agency, lists website defacement and malware hosting among the incidents it takes through its Cyber Aid reporting page. It gives advice. Investigating cybercrime is the police's job.
• The police, if anyone demands money to restore files, fix the hole or keep your customers' data off the internet. Lodge a police report online. The police's ransomware advisory says ransom payments are "strongly discouraged" and that paying is no guarantee you'll get your files back.
• The PDPC, within 3 calendar days of you assessing that a breach is notifiable: 500 or more people affected, or significant harm likely, such as leaked logins with passwords or card numbers. The deadlines, the tests and the PDPC's own decisions on hacked websites are in my guide to your PDPA data breach duties.
• Your customers, if their data was taken and harm is likely. The PDPC's guide asks for plain language: what happened, which data, what you've done, and what they should do, such as changing a password or watching card statements.
• Your payment provider, if a card form was tampered with, and your insurer if you hold cyber cover. Check the policy's notice terms today rather than next month.

Cleaning a hacked WordPress site is usually cheaper up front, and rebuilding wins when the site keeps getting reinfected, is stuck on an old PHP version, or depends on plugins nobody maintains. These are my own prices, since this is my service.

For a hacked site, my clean-up starts from SGD 850. I look at the site first, because nobody can tell how deep an infection goes before seeing it, and then you get a fixed price in writing before I start: the clean, the patching (PHP included) and anything the updates break. To stop it happening again, my content retainer at SGD 550 a month covers core, plugin, backup and security work. Both are on my website maintenance page.

Now the honest maths. Three clean-ups at the SGD 850 starting price already cost more than a Starter rebuild from SGD 2,535, and a clean doesn't remove the reason the site was hacked if the reason is the stack itself. I'd rebuild instead of cleaning when:

• it's the second or third infection this year
• the site is pinned to PHP 7.4, 8.0 or 8.1 because the theme or page builder breaks on anything newer
• plugins the site depends on haven't had an update in over a year
• it's a brochure site of ten or so pages that nobody edits every week
• nobody is paid to keep it updated, and nobody will be

A statically built site, the kind I build on Astro and serve from a CDN (terris.sg is one), has no PHP running on the server, no database and no public WordPress login for this kind of attack to reach. It still has things to protect: the domain registrar and DNS logins, the hosting account, the form endpoint and any third-party scripts. That's a much shorter list. MET Interior moved its 176-page site off WordPress onto Astro with me, with every old URL mapped across. My website design packages set out each tier: Starter from SGD 2,535, the One Week Website at SGD 3,545, and Growth from SGD 7,585 if your team needs a CMS to edit the site themselves.

If you run WooCommerce, a membership site or anything your team edits daily, staying on a well-kept WordPress is often the right call. Clean it, patch it, and make sure someone keeps it patched.

Stopping WordPress being hacked again comes down to updates (PHP included), fewer plugins, two-factor logins, off-server backups, and one named person responsible for all of it every month. The full list, in priority order, is my WordPress security checklist. The short version:

• Keep core, plugins, themes and PHP on supported, patched versions.
• Delete plugins you don't use, and replace any with no update in a year.
• Switch on two-factor login for every admin, the host and the registrar.
• Keep backups off the server with at least a month of history, so a slow infection doesn't outlast them.
• Give every person their own login, and remove it the day they leave.

Yes, a hacked WordPress site can almost always be fixed, either by restoring a backup from before the infection or by replacing core files, reinstalling plugins and themes, and removing the attacker's code and users. What decides whether it stays fixed is finding and closing the hole they used. Skip that, and the same attacker usually walks straight back in.

A WordPress security plugin runs inside WordPress, so it can miss attacks that come from below it, like a PHP flaw or a stolen hosting password, and it can't fix a vulnerable plugin for you. Wordfence and Kadence Security (formerly Solid Security) still reduce risk, and they're worth installing. But they sit on top of PHP, and PHP says its mod_php exploit runs before any application code, plugins included.

Paying a hacker is "strongly discouraged" by the Singapore Police Force, which says paying doesn't guarantee your files will be decrypted. Keep every message, lodge a police report online, and assess whether the PDPC needs to be told if customer data was taken. In my view, paying also tells the attacker you're worth coming back to. In the Horizon Fast Ferry case, the attacker asked for money to "fix" the very hole it had used.

For most small businesses, reporting a hacked website to SingCERT is optional, but if the hack exposed personal data, the PDPA requires you to assess the breach and notify the PDPC within 3 calendar days of deciding it's notifiable. Notifiable means 500 or more people affected, or significant harm likely. A police report is your call, and the sensible one whenever there's extortion or stolen data.