This never got a response the first time I submitted it. PHP maintainers
recognize the vulnerability, and added an undocumented non-default
setting which mitigates it. Please assign a CVE if possible.
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.
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
Let me know if more details are needed, and feel free to contact me
privately if proof of concept is needed.