We have a Linux environment serving a few different applications, all written in PHP 7.4. They are served out of a single Nginx web server using virtual hosts, and are all using FPM.
In our code we are using a JSON-RPC client class (@package JsonRPC, @author Frederic Guillot), which is a wrapper around PHP CURL. For historical reasons, the Client.php class exists in different versions within the different applications. These are obviously loaded from different physical locations in the file system, lets say it is /var/www/appA/classes/Client.php and /var/www/appB/classes/Client.php.
To our big surprise we have found that FPM sometimes serves the Client.php version that is from appA when it is called from appB! We found out about it because the appB application threw an exception, and from the stack trace we could see that Client.php was loaded from a path under appA. Inserting debugging statements in one version of the Client.php code confirmed the issue.
Further evidence of the problem is that when the FPM service is restarted, the problem goes away, and the correct version is loaded. For a while at least ... the issue comes back after several hours, after the other version of Client.php has been used.
Obviously, if this is true, it seems that this could present an enormous security issue!
One hypothesis is that the two applications receive requests that are served in sequence by the same FPM worker process, and the cache logic mistakenly finds that the Client.php has already been loaded.
The two versions are using the same PHP namespace, but differ within the PHP code. Could that be the reason for FPM mixing them up? One would think that there would be a checksum on the files that area loaded which would detect that the files are indeed different.
Are there any known restrictions on how to deal with identically named classes within FPM?
