[Resolved] wp-admin session invalidated (reauth=1) after updating to 4.8.3

Hi Carlos,

Short answer first: there’s no change in 4.8.3 that touches wp-admin session or cookie validation, so rolling back to 4.8.2 probably won’t help you. Your isolation result is still real though, and I can point you at the exact code in the plugin that’s capable of producing reauth=1, plus why one of your own troubleshooting steps may have made it worse.

On 4.8.3

I went through the full 4.8.2 to 4.8.3 diff before replying. The changes are Stripe/PayPal IPN handling and payment button ID validation, annual fixed-date expiry calculation, some new opt-in subscription renewal email settings, the login event auto-prune window, and moving the auto-login-after-registration handler out of init. None of it calls into WordPress’s auth cookie or session APIs. You read the changelog correctly. We also have no other reports of this from Hostinger or LiteSpeed users.

How the plugin can still cause it

There are three code paths in Simple Membership that call wp_destroy_current_session() and wp_clear_auth_cookie(). They all run on init or wp_loaded, which fire before auth_redirect() in wp-admin. So if one of them triggers, WordPress’s session token check fails milliseconds later in the same request, and you get bounced to wp-login.php?…&reauth=1. That’s exactly your symptom, and it’s why deactivating the plugin makes wp-admin stable.

The most likely of the three is our cookie integrity check. Our auth cookie’s HMAC is derived from your AUTH_KEY and AUTH_SALT values. You mentioned regenerating the salts in wp-config.php as one of your fix attempts, and that invalidates every Simple Membership cookie already sitting in a browser. Our code reacts to a failed check by clearing the WordPress session too. If the stale cookie then doesn’t get removed cleanly (which happens when COOKIE_DOMAIN or COOKIEPATH don’t match whatever originally set it, www vs non-www being the usual culprit), it keeps re-triggering on every request. It’s possible the salt regeneration turned an intermittent problem into a permanent one.

One thing I’d gently push back on: “the public site works” doesn’t actually clear the cookie layer. reauth=1 means auth_redirect() rejected the wordpress_[hash] / wordpress_sec_[hash] cookie, and that one is scoped to /wp-admin. The logged_in cookie at path / can be completely valid at the same time, which is why your front end behaves normally. That also means object caching of the session_tokens user meta isn’t fully ruled out by the tests you ran, even though I agree you’ve been thorough with LiteSpeed.

What would settle this

#1) Clear all cookies for guiacepa.com in your test browser, both www and non-www. This is necessary after a salt change regardless, and it might be the whole fix.

#2) Turn on our auth debug log: WP Membership, Settings, Advanced Settings, “Enable Debug”. Reactivate the plugin, reproduce the logout, then check the wp-content/plugins/simple-membership/log-auth-*.txt. If it shows Validate() function – Bad hash or Active login limit feature – login session token expired at the time of the logout, that narrows it to one specific branch.

#3) Log the WordPress side too. Drop this into wp-content/mu-plugins/auth-debug.php, reproduce, and send the matching lines from your PHP error log:

<?php
add_action('auth_cookie_bad_hash',          function($c){ error_log('SWPM-DBG bad_hash '.print_r($c,true)); });
add_action('auth_cookie_bad_session_token', function($c){ error_log('SWPM-DBG bad_session_token '.print_r($c,true)); });
add_action('auth_cookie_expired',           function($c){ error_log('SWPM-DBG expired '.print_r($c,true)); });
add_action('clear_auth_cookie',             function(){   error_log('SWPM-DBG clear_auth_cookie '.wp_debug_backtrace_summary()); });

bad_session_token means something destroyed the session. bad_hash points at salts or a cookie scope mismatch. And the clear_auth_cookie backtrace will name the function responsible outright, so if it’s our code, our file will be right there in the trace.

#4) Check three settings under Advanced Settings and tell me whether each is on or off: “Force WP User Synchronization”, “Enable Active Login Limit”, and “Disable Access to WP Dashboard”. All three interact with session handling.

#5) Is your admin WordPress account also a member record? Check for the same username or the same email address under WP Membership, Members. If it is, that links the two session systems together and makes the paths above reachable for your admin user.

#6) Delete and reinstall Simple Membership 4.8.3 from scratch, rather than updating in place. Those 19 HTTP 500s bracketing the 21:39 update, plus Hostinger flagging the site as Inaccessible, look a lot like an interrupted or partially written update. A clean reinstall costs you nothing and rules it out. Your settings and member data live in the database, so nothing is lost.

#7) If you still have them, the PHP error log lines from 21:24 to 21:53 UTC on 2026-09-17 would be a very useful thing you could share with us.

If you’d rather keep the plugin deactivated while we work through this, that’s fine. Do steps 1 and 6 first, and just send the logs from step 2 or 3 if you can reproduce it once. With either log, I can tell you definitively whether this is our code or something in the environment, and if it’s ours, it goes into the next release.