Hijacked siteurl and home Values in wp_options

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

The site looks broken in a very specific way: styling is gone, images are missing, links point somewhere strange, and when you try to reach wp-admin you get bounced to a domain you have never seen. Nothing in your theme changed. What changed is two rows in the database that tell WordPress where it lives, and they are among the easiest things for an attacker to alter and the most disruptive when they do.

What these two values control

WordPress stores its own address in the wp_options table as siteurl, and the public address of the site as home. Almost every URL WordPress generates is built from one of them: stylesheet and script sources, image paths, menu links, redirects, and the login URL itself. They are normally identical unless you have deliberately set up WordPress in a subdirectory.

Change them and you change every generated URL at once. That is what makes them such an effective target — a single database write redirects your entire site's asset loading and navigation without touching a single file, which means a file scanner has nothing to find and a core reinstall changes nothing.

What it looks like when they are wrong

The classic presentation is a site that renders as unstyled text, because the stylesheet is being requested from the attacker's domain and never arrives. Images break for the same reason. Internal links lead off-site. Attempting to log in redirects you away, often to a page designed to capture the credentials you were about to type.

Worse than the cosmetic damage is the loading: if a malicious domain is serving your scripts, every visitor is executing whatever that domain chooses to send. So this is not only a broken site, it is a site actively delivering someone else's code to your audience, which is why it deserves urgency rather than a note to look at on Monday.

Why you cannot log in to fix it

Because the login process itself uses these values. WordPress builds the admin URL from siteurl, so a request to your real wp-admin gets redirected to the attacker's version of it. You cannot fix a database value from an admin screen you cannot reach, which is exactly the point of the change.

That is not a dead end, though. Every route around it works outside the browser session, and there are three of them. My guide on being locked out of wp-admin after a hack covers the broader version of this problem.

Three ways to put them back

The most reliable fix is to override them in wp-config.php, because values defined there take precedence over whatever is in the database. Adding definitions for WP_HOME and WP_SITEURL with your correct address immediately restores normal behavior and lets you back in, without needing database access at all. It is the fastest route and the one I reach for first.

If you have database access, edit the two rows directly in phpMyAdmin — they are near the top of wp_options and easy to find. With shell access, WP-CLI does it in two commands. Whichever route you take, once you are back in, remove any temporary override only after you have confirmed the database rows themselves hold the right values, or you will simply hide the problem from yourself.

Fixing the rows is not fixing the hack

This is the part I care most about. Restoring the correct values makes the site work again in about two minutes, and that relief is precisely what makes people stop. But something had write access to your database to make that change in the first place, and that access has not gone anywhere.

Expect company. A compromise that reached wp_options frequently comes with a PHP backdoor on disk, an administrator account you did not create, injected content elsewhere in the database, and a persistence mechanism that will helpfully set siteurl back to the attacker's domain in a day or two. If the value changes again after you fix it, that is your confirmation. My guides on database malware, hidden admin users and backdoors cover the usual companions.

Doing the rest of the job

Work through the standard sequence: replace core, plugins and theme from clean sources; search the database for injected content and rogue rows; audit users and delete accounts you cannot account for; check scheduled tasks and must-use plugins for persistence. Then rotate everything — database password, WordPress salts, hosting and FTP credentials, and all user passwords — since your database credentials sit in a file the attacker could very plausibly read.

Finally, work out the way in and close it, because a clean site with an open door does not stay clean. If the site is business-critical and you would rather not spend a weekend proving to yourself that it is genuinely clear, my malware removal service handles the whole chain in one pass.

Common questions

Where exactly do I find these values?

In the wp_options table, in rows where option_name is siteurl and home. They are usually the first two rows in the table, so they are easy to spot in phpMyAdmin. With WP-CLI, wp option get siteurl and wp option get home will show you the current values without opening a database client.

Should siteurl and home be the same?

On most sites, yes — both should be your full site address with the correct protocol. They differ only in the specific case where WordPress core files live in a subdirectory but the site is served from the root. If yours differ and you did not deliberately set that up, one of them has been changed.

Can I fix this without database access?

Yes, and it is usually the quickest route. Define WP_HOME and WP_SITEURL in wp-config.php with your correct address. Those constants override the database values entirely, so the site starts working immediately and you can log in and clean up properly from there.

The values changed back a day after I fixed them. What is happening?

Something on the site is rewriting them — typically a backdoor that runs on every page load, or a scheduled task. This is the clearest possible evidence that the compromise is still active and that fixing the rows was treating a symptom. Go looking for the persistence mechanism rather than fixing the values a third time.

Is my data at risk from this specific change?

The change itself only alters two configuration values. But whoever made it had write access to your database, which implies read access to everything in it, including user records. Treat the siteurl change as evidence of a broader compromise rather than as an isolated act of vandalism.