I've read the first of the list (#10), and I'm skeptical this "top web technique" has ever been used in the wild. The blog post starts with a few obvious error

I've read the first of the list (#10), and I'm skeptical this "top web technique" has ever been used in the wild. The blog post starts with a few obvious errors. OPcache is parts of PHP since [PHP 5.5](http://php.net/manual/en/opcache.installation.php http://php.net/manual/en/opcache.installation.php), not PHP7. And "PHP7 by Rasmus Lerdof" is almost a joke: he was certainly not a top contributor to this iteration. These errors are not important _per se_, but they point to an overall lack of quality, and suggest no one reviewed before publication. The article is not very clear about the vectors one needs to attack. Here is the list: 1. A non-standard configuration that enables file cache in OPcache. Very improbable. 2. An access to the result of phpinfo() which gives many sensible details about the PHP instance. 3. A security breach allowing the attacker to upload files into the cache path without restriction on the file name. 4. The URL to a PHP file that received no HTTP query since the PHP server started. The alternative is a configuration that disables in-memory caching in OPcache, but that would be far too contrived. When the server has all these vulnerabilities but uses write-protected PHP files, then you can hack OPcache for remote code execution.