Session overlapping - Logging in as another user

The big, and obvious, question - is how does your session management work. You have described the surroundings but not the vehicle - which is crucial to dealing with this problem.

I had same question as Julian.

Sounds like you're running custom code, so this means to answer your question will require reviewing all your session management code...

To understand it... Then find + fix the problem...

Fairly simple process + also likely time consuming.

You mention, "We have just migrated to a CentOS server running Nginx/Apache".

So likely first considerations is "migrated from what", as likely problem will be something code was written using old PHP APIs or Apache-2.2 + something minor config file fix is required. Or possibly running phpcs + phpcbf across all your PHP source is required.

If your code was working before, then logical place to look is version changes.

Also, be sure you look through all your log files closely (and that you have deep debugging enabled every where, especially PHP) as problems normally show up (with correct logging verbosity) very clearly.

Do all new users upon creation of a new login profile, login as the same user, the one (an internal account) that created their account?
Do users come in as different users?
Is there a pattern, similar last name, etc.

My gut feeling is that you have two or more subdomains on the same server that are both from the same domain and both implement the same session cookie domain scope.

In other words, siteA.yourdomain.com sets a session cookie for .yourdomain.com, and the session variables contain a generic variable name like userID. When you log into siteA, userID is 111.

Then you log into siteB.yourdomain.com, which uses the same session cookie but a different DB table so it either puts you into a "random user's account" (user ID 111) or when you log into siteB, it overwrites the session userID and changes it to userID 222. So when you go back to siteA, it thinks you are still logged in but as userID 222.

Again, this is just a gut feeling based on how common it is to have conflicting session cookies on the same server vs. being less common to have custom, problematic session management code.

First let's see what a session looks like. Start by editing one of your existing site files that uses sessions and in the middle of the code, just drop in this command:
if(isset($_GET["info"])) phpinfo();

Then after you log in, go to that place and update the URL to add ?info=1 at the end.

On the resulting page, copy down the path to the loaded PHP.ini file and all sections and settings related to the word "session" and paste all that information here.

Next, tell us whether there's any web server configuration for multiple sites on the same server (especially if they have the same primary domain).

Next, identify whether the problem is truly a random user or if person A always ends up seeing person X's account, while person B always ends up seeing person Y's account, etc.

Next, after logging in, check your browser's development tools (hit F12) and find your session cookie. It should have one long string of random characters as its value, like abcdef12345... Then go into your /tmp folder and you should find a PHP session file that has that same session ID value as part of it's name. Go copy the contents of that file into notepad or something. Then try to reproduce the issue if you can. If you're able to reproduce the issue, repeat this entire step and see if you have a different session ID or different contents within the same session file in tmp.

Those initial steps should help us figure out the next ones.

Check 'php.ini' to see where the 'session.save_path' is pointing to.  Sometimes it is not set at all so you can't tell where your session files are being stored.  It has to point to something for sessions to work properly.

we figured it out

the egnintron is v1.8.8 on our old server while the new server has v1.11.0 which they turned on cache for dynamic content in get request, this is the root cause of the problem.

we turned off cache

fixed