WordPress hacked: detecting and cleaning a malware redirect

Visitors get redirected to a spam page, but you see nothing when you check. This article explains how modern WordPress redirect malware hides from admins, where it actually lives, and how to clean a site so it stays clean.

A visitor sends you a screenshot. Your site redirects to a pharma page, a fake Amazon login, or a scam "you have won" landing page. You open your own site in Chrome, nothing happens. You open it on your phone while logged in, still nothing. You check in incognito mode, and there it is: the redirect fires on the first click. The most unsettling part of a modern WordPress hack is not the hack itself; it is that the site looks fine to you while it robs your visitors.

This article is the cleanup playbook for that scenario. It covers how to confirm the infection, where redirect malware actually hides in 2026 (spoiler: not where most articles look), the exact steps to clean the files and the database, and how to keep the site clean after. If you are reading this at 11 PM on a Friday with a host suspension email open in another tab, skip to confirming the infection and come back to the context sections later.

Why you cannot see the redirect yourself

Nearly every modern WordPress redirect malware family checks is_user_logged_in() or inspects the wordpress_logged_in_* cookie before firing the redirect. If you are logged into wp-admin on the same browser, the malware silently returns the normal page and your visit looks identical to a clean site. The mu-plugins backdoor campaign documented by Sucuri in March 2025 does exactly this in its redirect.php file: conditional redirect to updatesnow[.]net, explicitly skipping logged-in users and bots.

The same check protects the attacker's SEO damage. The redirect regex blocks Googlebot and Bingbot so the malicious content never surfaces in Google's crawl cache, which lets the infection persist for weeks before Google Search Console flags it. You will see the redirect only from a browser that:

is not logged into WordPress,
has no WordPress admin cookies set,
uses a common consumer User-Agent.

The reliable check is an incognito window on a phone over mobile data, on a domain you have never logged into from that browser. If the redirect is intermittent, some families also set a session cookie (the January 2025 Sucuri-tracked malware sets a cookie called MkQQ) so that a repeat visitor does not get redirected twice in a row. One incognito hit, one redirect, is still a hit.

Signs your WordPress site has been hacked

A compromise rarely announces itself with a single clear symptom. The common patterns, in roughly the order people notice them:

Visitors report redirects to unfamiliar domains. Pharma, gambling, streaming scams, fake antivirus, or fake browser update pages. The source URL is always yours; the destination is not.
Google Search Console shows a "Security Issues" warning. Navigate to Security & Manual Actions > Security Issues in your Search Console property. Google categorizes these as "Hacked content", "Malware and unwanted software", or "Social engineering". Google's help page on hacked content lists the specific categories.
Chrome shows an interstitial warning to visitors. "Deceptive site ahead" or "The site ahead contains malware" is served by Google Safe Browsing, which receives its feeds from the same systems feeding Search Console. The interstitial also drops your click-through rate to roughly zero overnight.
Your host sends you a suspension notice. Shared hosts scan their customers with server-side tools and will either quarantine the account or email you with a deadline. Managed WordPress hosts are usually faster about this.
wp-admin shows admin users you did not create. Names like wpadmin2, license_admin2, or random hex strings are a giveaway. The January 2025 fake security plugin campaign (documented by The Hacker News) creates accounts specifically designed to hide from the WordPress users list via hook injection, so the absence of an unexpected account in the UI is not proof there is none.
New posts or pages you did not write, often in a language you do not speak. Usually spammy pharma or gambling SEO content, sometimes hidden as drafts, sometimes published and hidden via custom CSS.
Search traffic drops sharply. A 40 percent to 90 percent drop in organic traffic over 48 hours is the SEO signature of either a Safe Browsing warning or a manual penalty.
Unexplained files in wp-content/uploads/ with .php extensions. There should be none. Ever.

A single one of these is suspicious. Two or more together means the rest of this article applies.

The misconceptions that keep sites infected

Before the cleanup steps, three beliefs cost site owners days of their lives and usually leave the site dirty.

"Deleting the malicious file is enough." It is not. Modern reinfector malware, documented by Sucuri in November 2024, spreads its payload across every active plugin file, stores a second copy in wp_options under a hex-encoded option name, adds a third in the wpcode_snippets option, and modifies wp-cron.php so a scheduled event reinstalls the deleted file within minutes. Sucuri's own wording is blunt: "If the site isn't fully cleaned, even small remnants of the malware can cause it to quickly reinfect everything." One surviving vector is one too many.

"A security scan plugin finds all malware." It does not, and the gap is wider than most people expect. Remote scanners like Sucuri's SiteCheck cannot see server-side files at all; they only see what a public visitor sees. Server-side plugin scanners like Wordfence's free scanner catch roughly 70 to 80 percent of known malware signatures but miss malware hidden in the database, and the Wordfence team itself shipped database scanning only in Wordfence CLI 5.0.1 in November 2024, which confirms the gap existed for years. Worse, a July 2024 Sucuri report documented malware that actively disables Wordfence by renaming its plugin directory to wordfence1 and then injects a fake JavaScript overlay that makes the disabled plugin appear active in the dashboard. A clean scan is evidence, not proof.

"Reinstalling WordPress fixes it." A WordPress reinstall replaces /wp-admin/ and /wp-includes/. It does not touch /wp-content/ (where your plugins, themes, uploads, and mu-plugins live), it does not touch the database, and it does not touch wp-config.php. All four of those are primary persistence vectors. The WordPress.org support forums have an active thread titled exactly malware recreates itself even after deleting and reinstalling WordPress, with multiple documented cases of reinfection within hours of a full core reinstall.

Keep these three in your head as you work. Every step below exists because one of them is wrong.

Confirming the infection

Before you start cleaning, you need three things: a clear list of symptoms, a fresh forensic backup, and evidence that Google and the security community already see what you see.

Reproduce the redirect in a clean environment. Open your site in an incognito window on a device that has never logged into the WordPress admin. Try mobile data, not your office Wi-Fi, in case the attacker is geofencing. Note the destination URL of the redirect and the exact path on your site that triggers it. Screenshot it.
Take a forensic backup of the current (infected) state. This is not the backup you restore from; it is the copy that lets an incident responder reconstruct what happened. Use your host's snapshot feature, wp db export, and a tar -czf of the WordPress tree. Store this copy outside the web host. Do not skip this step. The instinct in a panic is to delete everything and start over, which destroys the only evidence you have.
Run Sucuri SiteCheck against your URL. Visit sitecheck.sucuri.net and submit your domain. SiteCheck is a remote scanner and will only find publicly visible malware and blocklist hits, but "publicly visible" is exactly what matters for a redirect campaign. Note every URL it flags.
Check Google Search Console > Security Issues. If Google has flagged your site, the report lists the affected URLs and the category of hack. The full flow is documented in Google's hacked content help. Screenshot everything.
Run a VirusTotal URL scan. VirusTotal's URL scanner cross-checks your domain against roughly 70 vendor blocklists, which tells you how widespread the damage is and which vendors you will need to contact after cleanup.
Pull your hosting access logs for the last 30 days. Look for POST requests to wp-login.php or xmlrpc.php that returned 200 (successful logins) from IPs that are not yours. Look for POST requests to wp-admin/admin-ajax.php with action parameters you do not recognize. Note the timestamps; they anchor the rest of the investigation.

The goal of this phase is a written list of what you know. If you find nothing in incognito and nothing in Search Console, but your visitors are seeing redirects, the next most likely culprit is a compromised ad tag or a third-party script rather than a WordPress hack. Stop and investigate that path first.

Where redirect malware actually hides

Most cleanup guides tell you to "check the theme files". That is half the story. Modern WordPress redirect malware hides in seven places in rough order of how common they became in 2024 and 2025:

1. wp-content/mu-plugins/. The must-use plugins directory is the stealth vector of 2024 and 2025. Files in here load automatically on every request, cannot be deactivated from the admin panel, do not appear in the Plugins list, and are ignored by most file integrity tools. The March 2025 Sucuri report documented three malicious files in a single campaign: redirect.php (conditional redirect with bot and admin evasion), index.php (downloads and executes remote PHP from GitHub via cURL), and custom-js-loader.php (replaces images and hijacks outbound links).

2. The wp_options table. This is the 2023 and 2024 favorite, and the one server-side file scanners miss entirely. Malware stores its payload in options rows with hex-encoded names like 55e7183bded6e0fa810c47b04e65ea6e, in the wpcode_snippets option, in the td_live_css_local_storage option (Balada Injector's favorite), or by modifying siteurl and home to point at attacker domains so every WordPress page loads resources from them. The Balada Injector campaign, synopsized by Sucuri in April 2023, has compromised over a million sites this way.

3. Active theme functions.php. An injected hook at the top of functions.php runs on every WordPress load and can fire a redirect, inject a script, or write other malware into the database. The injection is often a single line that loads encoded PHP from a string stored elsewhere in the file.

4. .htaccess (Apache) or nginx config. On Apache, injected RewriteRule and RewriteCond blocks execute before WordPress even loads. They can redirect based on User-Agent, Referer, or the absence of a specific cookie. Nginx equivalents appear in the site's nginx.conf or an included server block. Since these fire before PHP, no PHP-based scanner sees them.

5. wp-config.php. A single prepended <?php block that runs on every request is hard to notice because most people never read wp-config.php top to bottom. Anything above the define('DB_NAME', ...) line that you do not recognize is suspicious.

6. Active plugin files and the WPCode snippets plugin. The reinfector family identified by Sucuri in November 2024 specifically uses wpcode_snippets as a persistence mechanism because it is the legitimate storage location for a widely-installed code snippet plugin, which makes the injected PHP look like intended use.

7. wp-content/uploads/. Any .php file in the uploads directory is a backdoor. There is no legitimate reason for PHP files to live there. The combination find wp-content/uploads -name '*.php' on a clean site returns zero results; on a compromised site it returns the backdoor location.

Then there are the named malware families you will see referenced if you search for your symptoms. The ones that are actually documented in primary security research, as of 2024 and 2025:

Balada Injector, active since 2017 and named in 2022, documented by Sucuri's April 2023 synopsis and The Hacker News' January 2024 Popup Builder campaign coverage. It exploits plugin CVEs (tagDiv Composer, Popup Builder CVE-2023-6000), injects into td_live_css_local_storage, and modifies siteurl.
Mal.Metrica, active since 2023 and documented by Sucuri in May 2024. 17,449 infected sites tracked in 2024. Distinguishes itself by using CDN-lookalike domains such as gll.metricaga.com rather than nonsense word combinations.
SocGholish, active since 2017, documented in Sucuri's June 2024 analysis. 147,332 identified infections in 2024. Delivers fake browser and Java update warnings that drop a Remote Access Trojan on the visitor's machine. A March 2024 wave started impersonating WordPress plugin structure to evade detection.
The mu-plugins persistence campaigns already linked above.

If your symptoms match one of these families by name, the Sucuri reports linked above document the exact files and option names to look for.

Phase 1: isolate and preserve evidence

Before you touch anything, preserve what is there. Rushing into deletion destroys evidence and can destroy the data you need to rebuild.

Enable maintenance mode with a static HTML file at the web server level, not a WordPress plugin. Any plugin you activate now may be the thing that is compromised. A one-file maintenance.html served by a web server rewrite rule is tamper-proof.
Take a full file backup: tar -czf /tmp/infected-files-$(date +%F).tar.gz /var/www/html (adjust the path). Take a full database backup: wp db export /tmp/infected-db-$(date +%F).sql. Download both to a machine that is not your web host. This is the forensic copy.
Record the timeline: when did complaints start, which plugins and themes were updated in the 72 hours before, and what does your hosting access log show for admin logins in the same window? Write this down. You will need it for the Google Search Console review request later.
Rotate every credential: WordPress admin passwords (for all admins, not just yours), hosting control panel password, FTP and SSH passwords, database password, and any API tokens stored in plugins (MailChimp, Stripe, reCAPTCHA). Assume the attacker has copies of everything.

Phase 2: clean the files

With evidence preserved, start with the filesystem. Databases come next; credentials and hardening come last.

Run wp core verify-checksums with WP-CLI. This compares every file under wp-admin/ and wp-includes/ against the canonical WordPress release on wordpress.org, flagging any file that has been modified or added. Every flagged file in the core directories is suspicious; none should exist on a clean install.
```
# Compare installed core files against wordpress.org release hashes.
# Flags any modified, missing, or extra file in wp-admin/ and wp-includes/.
wp core verify-checksums
```
Inspect wp-content/mu-plugins/ manually. Delete any file you did not personally place there. If you do not recognize any file here, delete the entire directory; WordPress will recreate it empty. If your host installs drop-ins here (some managed hosts do), write those filenames down first and verify them against a fresh install on the same host.
```
# List every file in mu-plugins with modification time and size.
ls -la wp-content/mu-plugins/
# Common malicious filenames from the Sucuri March 2025 campaign:
# redirect.php, index.php, custom-js-loader.php
```

Grep the entire WordPress tree for obfuscation markers. These patterns are the signature of encoded payloads. Investigate every file this command returns.

# Find PHP files containing common obfuscation patterns.
# Each hit is a file to read by hand and decide on.
grep -rl "eval(base64_decode" /var/www/html/wp-content/
grep -rl "gzinflate(base64_decode" /var/www/html/wp-content/
grep -rl "str_rot13(" /var/www/html/wp-content/
grep -rl "preg_replace.*\/e" /var/www/html/wp-content/

Find PHP files in the uploads directory. There should be zero.

# A clean site returns no results. Any hit is a backdoor.
find /var/www/html/wp-content/uploads/ -type f -name "*.php"

Read wp-config.php from the top. Anything before the opening comment block or before the define('DB_NAME', ...) line that you do not recognize is injected. Compare against a fresh wp-config-sample.php from the matching WordPress release.
Read the active theme's functions.php and any header.php or footer.php top to bottom. Redirect injections sit at the top of the file or inside the first add_action('init', ...) hook.
Replace plugins and themes from their sources. Do not try to clean individual plugin files line by line. For every active plugin and the active theme, download a fresh copy from wordpress.org or the original vendor, delete the entire directory under wp-content/plugins/plugin-name/ or wp-content/themes/theme-name/, and upload the fresh copy. This is faster and more reliable than file-by-file cleanup. Commercial plugins often require the license file; keep a copy handy.
Replace WordPress core. Download the matching version from wordpress.org/download/releases/ and upload it, overwriting the existing wp-admin/ and wp-includes/ directories. Do not overwrite wp-content/ or wp-config.php. WP-CLI's wp core download --force does the same from the command line.
Regenerate .htaccess. Delete the current file and then visit wp-admin > Settings > Permalinks and click Save. WordPress writes a fresh default .htaccess block. If you had custom rewrite rules for caching or redirects, restore them from a known-good backup, not from the current infected file.
Clear every cache. Page cache, object cache, CDN cache, and any Cloudflare or similar edge cache. Cached pages serve stale malicious content long after the underlying file is clean.

Verification after Phase 2. Run these checks before moving on:

wp core verify-checksums returns no modified files.
find wp-content/uploads/ -name "*.php" returns nothing.
ls wp-content/mu-plugins/ shows only files you recognize.
grep -rl "eval(base64_decode" wp-content/ returns nothing.

If any of these still return hits, do not proceed to database cleanup until they are clean. Reinfector malware will reinstall the files you just removed.

Phase 3: clean the database

This is the phase most guides skip, and the phase most reinfector malware survives. Open phpMyAdmin or the MySQL CLI against your database.

Verify siteurl and home. These two options should be exactly your domain, nothing else.
```
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');
```
If either points at a domain you do not recognize, update it. This is a classic Balada Injector technique.

Hunt for obfuscated PHP in wp_options. This catches the hex-name payload pattern from the November 2024 reinfector family.

SELECT option_name, LEFT(option_value, 200) FROM wp_options
WHERE option_value LIKE '%eval(%'
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%gzinflate%'
   OR option_value LIKE '%str_rot13%'
   OR option_value LIKE '%<script%';

Read every hit by hand. Delete the ones that are malicious (DELETE FROM wp_options WHERE option_name = '...').

Find hex-named options. The reinfector family stores its payload under random 32-character hex strings.
```
SELECT option_name FROM wp_options
WHERE option_name REGEXP '^[0-9a-f]{32}$';
```
A clean WordPress install has zero rows matching this. Any row is suspicious.
Check the wpcode_snippets option specifically. If you do not use the WPCode plugin, this option should not exist at all. If you do, read its current value and verify every snippet is one you wrote.

Inspect wp_users for unexpected admin accounts. Do not rely on the wp-admin users list; hook-injection malware can hide accounts from it.

SELECT u.ID, u.user_login, u.user_email, u.user_registered, m.meta_value
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Any account you do not recognize needs to be deleted. Delete via SQL if wp-admin is compromised.

Check wp_posts for injected script tags in published content.
```
SELECT ID, post_title, post_status FROM wp_posts
WHERE post_content LIKE '%<script%'
  AND post_status = 'publish';
```
Review every match. Legitimate uses (Google Analytics via a custom block, embed codes) are usually in the theme or header, not in post content.

Clear scheduled tasks. The reinfector family modifies wp-cron.php and schedules a task that reinstalls the deleted files. Clear and regenerate the cron table with WP-CLI:

# List all scheduled events; inspect for hooks you do not recognize.
wp cron event list
# Delete suspicious scheduled hooks one by one.
wp cron event delete <hook_name>

Verification after Phase 3. Re-run every SQL query above. Every one should return either nothing or only rows you explicitly recognize. wp cron event list should show only WordPress core and known-plugin events.

Phase 4: lock down access and harden

Cleaning without hardening leaves the door the attacker came through wide open. The goal of this phase is to close it and invalidate any remaining foothold.

Reset every credential, again. Even if you rotated in Phase 1, any credential in use during the cleanup phase may have been observed. Admin passwords for every user, hosting control panel, FTP, SSH, database user, and any API tokens.
Invalidate all existing sessions. Change the AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT constants in wp-config.php to fresh values from the WordPress.org secret-key generator. Replacing the salts invalidates every active cookie, which logs out any attacker who still has a session.
Remove unknown admin users and demote any user you do not recognize to subscriber before deleting, so you preserve their authored content for review.

Disable the dashboard file editor in wp-config.php:

// Blocks wp-admin > Appearance > Theme File Editor
// and Plugins > Plugin File Editor. A reinfection vector closed.
define( 'DISALLOW_FILE_EDIT', true );

Set correct file permissions. The WordPress hardening guide is the canonical source: directories 755, files 644, wp-config.php at 440 or 400. Run from the WordPress root:

# Set directory permissions to 755 and file permissions to 644.
cd /var/www/html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Block PHP execution in the uploads directory. Add an .htaccess file at wp-content/uploads/.htaccess (Apache) or the equivalent nginx location rule:

# Block any PHP file from executing inside the uploads directory.
# A backdoor dropped here can no longer be invoked.

    Require all denied

Reinstate Wordfence or your chosen server-side scanner and run a full scan. If Wordfence was previously installed and renamed to wordfence1 by the July 2024 evasion malware, verify that the plugin directory is now at the correct path wp-content/plugins/wordfence/.
Apply the rest of the hardening baseline. File permissions, login rate limiting, 2FA on every admin account, and the full wp-config.php security block are covered in detail in WordPress security hardening. A cleaned site that goes back online without those controls is a site that will be reinfected.

A reassuring version note. Since WordPress 5.2 (released May 7, 2019), core automatic updates are verified with an Ed25519 signature via libsodium, documented in the Paragon Initiative post on WordPress 5.2 supply-chain mitigation and the WordPress 5.2 security announcement. If your WordPress version is 5.2 or newer, the core auto-update path itself is not a credible attack vector. Every compromise I have cleaned has come in through a plugin, a theme, a stolen credential, or server misconfiguration. Core is not the weak link.

Phase 5: tell Google the site is clean

A clean site that still has a Search Console warning is a site with no traffic. The review request is the last step and it is not optional.

Verify the cleanup with Sucuri SiteCheck one more time. Submit your URL to sitecheck.sucuri.net. Every previously-flagged URL should come back clean. If SiteCheck still flags something, you have missed a vector; go back to Phase 2.
Run a Wordfence or Jetpack Protect server-side scan. The server-side view catches things SiteCheck cannot. Confirm zero hits.
Open Google Search Console > Security & Manual Actions > Security Issues. Click "Request a review". The form asks what kind of hack was found and what you did about it. Be specific. Google's reviewer is a human (or at least human-supervised) and vague answers get rejected. A reasonable description looks like this:

Site was compromised on April 5, 2026. Found a conditional redirect in wp-content/mu-plugins/redirect.php and an injected payload in wp_options under a hex-encoded option name. Cleaned by: replacing all plugin, theme, and WordPress core files with fresh copies; removing malicious options from the database; deleting two unexpected admin users; rotating all credentials and session salts; enabling DISALLOW_FILE_EDIT and blocking PHP execution in wp-content/uploads/. Verified clean via Sucuri SiteCheck and Wordfence full scan. Also applied the full WordPress hardening baseline going forward.
Wait. Google's published timeline is several days to a few weeks. Sites that submit a specific, credible description within 48 hours of cleaning typically clear faster than sites that submit a boilerplate "please remove the warning". If the review is rejected, Google will tell you why; clean that specific issue and resubmit.
Separately, check for a manual action. Security Issues and Manual Actions are two different Search Console reports. If the attacker used your site for spam SEO and Google added a manual penalty (spam, cloaking), you will see it under Security & Manual Actions > Manual Actions, and it requires its own Reconsideration Request.
Notify VirusTotal and the vendors that flagged you. Most vendor blocklists auto-clear when their next scan finds the site clean, but some (notably Norton/Symantec and a handful of smaller vendors) require a manual report form. Submit one to each vendor VirusTotal showed as flagging you.

When to escalate

Call for help when any of these is true. Before you do, collect the checklist below so the first hour is not spent on context.

You cleaned the files and ran the SQL queries, but the site redirects again within minutes of going live.
You find evidence of access that predates your logs; the compromise started more than 30 days ago and your host's retention does not cover it.
You find injected code in database tables I did not mention (wp_posts, wp_postmeta, wp_users, wp_usermeta) that you cannot decode.
Your host has suspended the account and will not restore it without a third-party incident report.
The compromise involves a payment processor integration (WooCommerce, Stripe, PayPal) and you have any reason to believe card data or order details were exposed. Card data exposure has PCI-DSS reporting obligations that apply regardless of the cleanup state of the site.
Personal data of EU residents has been exposed and you have not yet notified your data protection authority. GDPR Article 33 requires notification within 72 hours of becoming aware of a breach.

Collect before you ask:

The WordPress version, PHP version, web server (Apache or nginx), and host.
The active theme and a list of active plugins with versions (wp plugin list --format=csv).
The forensic backup you took in Phase 1.
The output of wp core verify-checksums.
The first and last dates in your access logs showing unexplained admin activity.
Every screenshot from Phase 1 (the redirect, Search Console, SiteCheck, VirusTotal).
A timeline of what you have already tried and what happened.

How to prevent this from happening again

A clean site is a starting point, not a finished project. The controls that would have stopped the compromise in the first place are the same ones that will stop the next one:

Automatic updates for WordPress core, plugins, and themes. Patchstack's 2024 State of WordPress Security report puts the median time from public vulnerability disclosure to mass exploitation at five hours. Manual patching does not fit in that window. The full reasoning and the WP-CLI commands are in WordPress security hardening.
A real backup strategy, off the web host, with a tested restore. The compromise you just cleaned would have taken an hour instead of a day if you had a clean backup from before it happened. Stored in wp-content/backups/ does not count; an attacker with write access to wp-content/ can delete those. The full approach is in WordPress backup strategy.
Two-factor authentication on every administrator account. Credential compromise is the attack path that does not show up in vulnerability counts because it dominates the data. A second factor stops almost every single one. The setup walkthrough, including the grace period that stops you from locking your team out, is in two-factor authentication (2FA) for WordPress.
Rate limiting at the web server or WAF on wp-login.php and xmlrpc.php, covered in the hardening article. If the attacker cannot try 10,000 passwords, they do not get the weak one.
Weekly review of admin users and weekly review of the plugin list. Dormant admin accounts and abandoned plugins are the two failure modes that sink sites quietly. Neither takes long to check; both are easy to miss.

If a file change during Phase 2 left your site showing a fully blank page instead of its normal theme, the recovery path for that specific state is in white screen of death in WordPress.

Want this to stop being your problem?

If outages or errors keep repeating, the fix is often consistency: updates, backups and monitoring that don't get skipped.

See WordPress maintenance