Rotate WordPress security keys after PHP2Shell

Why a memory leak means rotating secrets

PHP2Shell is really two bugs. One of them, CVE-2026-109619, can do more than run code: researchers showed it could disclose chunks of a PHP worker’s memory to an unauthenticated attacker. That’s the detail that makes secret rotation a precaution worth taking even if you never found a single malicious file.

Think about what passes through a PHP worker’s memory in a normal day. The password someone just typed into the login form. The database credentials WordPress uses on every request. A session token. An API key your SMTP or payment plugin loaded to send a message or take an order. None of those are necessarily written to disk where you could inspect them — but they’re in memory while they’re in use, and a memory-disclosure bug doesn’t care whether a value was ever saved to a file. One demonstrated technique leaked roughly 67 KB of worker memory per attack.

So if your site was exposed and unpatched during the PHP2Shell window, you can’t know what leaked. The safe, boring assumption is that your secrets were seen, which means replacing them. This guide is the rotation half of the response; it pairs with checking whether you were hacked, and the two are best done together.

What the keys and salts actually are

Open your wp-config.php and you’ll find a block of eight lines near the middle, usually under a comment that says “Authentication Unique Keys and Salts.” They are four keys and four matching salts:

AUTH_KEY / AUTH_SALT

Protect the login cookie for the standard (http) admin session

SECURE_AUTH_KEY / SECURE_AUTH_SALT

The same, for sessions served over HTTPS

LOGGED_IN_KEY / LOGGED_IN_SALT

Identify a logged-in user who isn’t in the admin area

NONCE_KEY / NONCE_SALT

Harden the one-time tokens (nonces) that guard form submissions

These aren’t passwords you type anywhere. WordPress uses them behind the scenes to sign and encrypt the login cookies it stores in your browser, so the server can trust a returning visitor without keeping a session table. That design is why the keys matter: anyone who knows them can forge a cookie that WordPress will accept as a valid, logged-in session — no password required. A memory leak that exposes them is therefore worth taking seriously, and the fix is simply to change them.

WordPress ships wp-config.php with placeholder text in these lines (“put your unique phrase here”). On a correctly set-up site they’ll already be long random strings. Either way, the rotation is the same: replace all eight with a fresh set.

Generate new salts the official way

WordPress.org runs a tiny service that returns eight ready-made lines, freshly randomised on every request. It’s the method WordPress’s own documentation points to.

Open that URL in your browser and you’ll get eight complete define() lines you can paste straight in. Or, if you have shell access, fetch it on the server or let WP-CLI do the whole job in one command:

# Fetch eight ready-made define() lines$ curl -s https://api.wordpress.org/secret-key/1.1/salt/# Or let WP-CLI generate and replace them in wp-config.php in one step$ wp config shuffle-salts

Where they go in wp-config.php

If you’re editing by hand, find the eight existing lines and replace them with your new set. The shape looks like this — these are placeholders, not real keys; use the unique values the generator gives you, never the example strings below:

define( 'AUTH_KEY',         'paste-your-own-unique-value-here' );define( 'SECURE_AUTH_KEY',  'paste-your-own-unique-value-here' );define( 'LOGGED_IN_KEY',    'paste-your-own-unique-value-here' );define( 'NONCE_KEY',        'paste-your-own-unique-value-here' );define( 'AUTH_SALT',        'paste-your-own-unique-value-here' );define( 'SECURE_AUTH_SALT', 'paste-your-own-unique-value-here' );define( 'LOGGED_IN_SALT',   'paste-your-own-unique-value-here' );define( 'NONCE_SALT',       'paste-your-own-unique-value-here' );

A few practical notes. Take a copy of wp-config.php before you edit it, so a stray keystroke can’t lock you out. Replace all eight lines, not some of them. And make sure each value stays inside its single quotes on one line — the generator’s output already does this correctly, which is the main reason to prefer it over inventing your own strings.

Rotating keys logs everyone out

The moment you save new keys and salts, every login cookie WordPress previously issued becomes invalid. Everyone is signed out at once: you, your editors, your logged-in members — and anyone who got in without permission and was relying on a stolen or forged session. You’ll simply log in again with your password.

That side-effect is a feature here. One of the ways an attacker keeps a foothold after exploiting a site is by holding a valid session or a forged auth cookie. Rotating the salts pulls the rug out from under all of them in a single step, which is why WordPress.org’s own hacked-site guidance lists it as a standard response. Pair it with resetting passwords (next section) and the stolen credentials become useless as well as the stolen sessions.

The full rotation checklist

The salts are the start, not the whole job. A leaked worker memory could have exposed anything PHP touched, so rotate every secret the site knows. Tick them off as you go — your progress is saved in this browser.

# Regenerate all eight keys and salts in wp-config.php$ wp config shuffle-salts# Point wp-config.php at the new database password you set in your panel$ wp config set DB_PASSWORD 'your-new-database-password'# Force a password reset for every administrator$ wp user reset-password $(wp user list --role=administrator --field=ID)

After you rotate

Rotation ends stolen sessions and makes leaked credentials useless — but it does not, by itself, remove a backdoor, delete a rogue admin account or fix a vulnerable runtime. It’s one step in a larger response, so make sure the others are done too.

1. 1

   Step 1: Confirm PHP is patched and restarted

   If you haven’t already, this is non-negotiable — see the PHP2Shell guide for patching every kind of host, and how to confirm with a managed host.
2. 2

   Step 2: Check for indicators of compromise

   Rotating secrets assumes exposure; now find out whether anyone acted on it. Work through the was-I-hacked checklist.
3. 3

   Step 3: Clean up or restore if you found anything

   If something turned up, follow the recovery checklist — restore a clean backup from before your exposure window, or rebuild from official sources.
4. 4

   Step 4: Change passwords again once you’re sure it’s clean

   WordPress.org recommends a second password change after you’ve confirmed the site is clean, in case the first round leaked before the hole was closed.
5. 5

   Step 5: Watch for a few weeks

   New admin users, unexpected logins, host notices and a site: search. A quiet month is the sign you’re through it.

A stack with fewer secrets to leak

The reason PHP2Shell forces a secret-rotation scramble is that a PHP worker holds your credentials in memory on every request, and a runtime bug put that memory within reach. Presscomet takes a different shape: it runs the same wp-admin, block editor, URLs and REST API on Node.js with a single SQLite file, and it has no PHP runtime. The whole class of PHP-runtime memory-disclosure bugs — PHP2Shell included — doesn’t apply to it, because PHP isn’t there to leak.

That’s a real reduction in what can go wrong, and it deserves honest edges. Presscomet still has its own secrets, its own login to protect, and its own software to keep updated — Node.js, its libraries and the host — so it isn’t “unhackable,” and good key hygiene still matters. It also doesn’t run PHP plugins: the common jobs (SEO, forms, SMTP, redirects, security, custom fields) are built in, but WooCommerce stores aren’t supported. The details are on our WordPress security page.