I was logged in as one of my customers

Gini H. Probably you clicked somone else Magic Link from some email to logged in - did anybody send you email with that community link to log in?

Mat ‎ No, I did not click anything, I just wanted to open the login page (from a bookmark in my browser) but instead was logged in directly within the customers account.

Mat ‎ This said customer also did never share any login data or magic links with us via mail or other messaging.

Gini H. If your bookmark in your browser is pure URL without any ?query string (token) in it than it is really strange. Its also strange that you did not provide any credentials and you were logged in (I assume that you were somehow logged into WP as other user not as any Admin/Edit role).

In that case I have no clue what happened there.

Mat ‎ That's why I am so concerned. It was a simple customer account (just registrated within fluent CRM and as user within wordpress). As written above I also cleared everything yesterday. So I should not have been logged in on any account at all.

Gini H. 

1. Do you allow changing UserName directly in Fluent Community?

   Case where that user or you changed recently a userName.

2. Do you use CDN like CloudFlare? If Yes then did you clear it.

3. Do you use Redis/Memcached? If Yes then did you clear it.

4. Do you use standard wp-login feature or you use any external plugin for user authentication (other than Fluent Auth)?

5. Did you changed or do you use headers: Cache-Control: Private?

6. Do you use WP multisite?

7. If you use any 3rd party Fluent Community addons then disable them for troubleshooting - maybe they mix users sessions/nonces/autentication somehow.

8. Did you scan your wordpress for any malicious software or you use any fancy code snippets to change some WP behaviour related to your WP security settings?

9. Did you use Incognito Mode wihout any browser extensions while verifiing this case to replicate your issue?

Read this:

Primary Potential Causes (Session & Authorization Failures)
​These issues occur when the server incorrectly associates the requesting browser with the wrong user ID.

1. Server-Side Session Mix-up (Session Swap)
   ​This is the most likely technical cause, independent of client-side cache/cookies.
   ​Mechanism: When the user visited the site, their browser sent a Session Cookie to the server. Due to a bug in the server's session management system (e.g., poor implementation using Redis, Memcached, or standard PHP sessions), the server mistakenly matched that incoming session key to the customer's User ID instead of to a valid logged-out state or the intended user ID.
   ​Context: This can happen under heavy load, due to race conditions, or if the session handler fails to properly isolate session data, potentially assigning two users the same session_id or mixing up the user_id associated with a session token.
2. Aggressive Server-Side Caching (Misconfigured Varnish/CDN)
   ​This often affects authenticated users if not configured correctly.
   ​Mechanism: A proxy cache (like Varnish, LiteSpeed Cache, or a CDN) might have been configured to cache the HTML output of logged-in user pages. The customer's authenticated page was cached and subsequently served to the second user.
   ​Context: This is a serious configuration error. Pages for authenticated users (containing personalized data or an active session) must never be publicly cached. The server should always send specific headers (like Cache-Control: private) to prevent this.

Secondary, Less Likely Causes
​

1. Plugin Vulnerability (Authentication Flaw)

   The community plugin or WordPress itself might contain a vulnerability that allows a user to directly pass a customer's unique identifier (e.g., an unhashed user ID or a sequential primary key) in a maliciously crafted URL (even if the user claims to have used a simple bookmark, the browser could have included extra data). However, this usually requires some input, not just opening a bookmark.
   ​

2. Shared Environment Residual Data
   ​If the user's machine is shared or part of an enterprise network, a local application or extension (not just the browser's standard cookie storage) could have retained a session token that was reactivated upon visiting the domain.
   ​

Immediate Security Recommendations

• Force All Logouts: The site administrators must immediately invalidate all active sessions for the specific customer account and force a password change.
• Audit Session Handling: Developers need to perform an urgent review of the code responsible for mapping session cookies to user IDs, focusing on the custom community plugin and any caching layers.
• Check Access Logs: Review the server's access logs to pinpoint the exact time of the event, identifying the IP address and the Session ID received from the browser, and seeing how the system authenticated that ID to the customer's account.

Shahjahan Jewel Well but it was possible somehow. We have not installed a user switch plugin and also don't use auto login feature of our pw manager for this site (and even if we would have enabled it, it would not have the credentials of the customer).
I have not clicked a link, I did the same as everytime I log in into the community, but did not end at the login screen at all but directly within the customers account.