A very serious security issue that has been long standing with PHP have been quietly fixed without being noticed until it was submitted to the OSS security mailing list. The vulnerability is related to PHP with Zend OPCache code permission/sensitive data protection :
To briefly summarize, in PHP SAPI’s where PHP interpreters share a common parent process (eg. Apache mod_php and PHP-FPM), Zend OpCache creates a shared memory object owned by the common parent during initialization. Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode (“opcode” in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script’s filename is known or can be guessed.
Many common shared hosting configurations change EUID in child processes to enforce privilege separation among hosted users. In these scenarios, default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes.
PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user’s script usually means gaining privileges to the CMS database.
The issue have been first discovered two years ago here then here, but didn’t get fixed only recently. Original reporter in bug #67481 closed his bug report stating “It turns out this is not a bug, it is the behaviour that is expected when opcache.use_cwd is set to zero,” but the same behavior occurs when opcache.use_cwd is enabled unless scripts are invoked with relative paths. Absolute paths are typically used by web servers and web applications.
PHP7 < 7.0.14 and PHP5 < 5.6.29. Later versions are still vulnerable by default unless opcache.validate_permission=1 is enabled.
Code permission/sensitive information disclosure
Cross-user compromise of PHP web applications in shared hosting