OPcache and PHP2Shell: What Site Owners Need to Know

As of 23 October 2026, neither of PHP's two PHP2Shell advisories mentions OPcache, and neither recommends any OPcache setting. OPcache comes up because Wiz, one of the research teams, listed an OPcache-related bug among the problems it found and used it in its demonstration against WordPress. Wiz also says the PHP patch closes it.

So the practical answer is short. Install the fixed PHP (8.5.12, 8.4.27, 8.3.36, 8.2.35 or your vendor's patched package), then fully restart PHP. No separate OPcache step, setting or reset has been published by PHP, Wiz or the vendors we checked.

This page explains what OPcache is in plain terms, what was reported about it at headline level, and why a restart, not a cache reset, is what finishes the job. It does not describe how any flaw works.

What OPcache Is, in Plain Terms

Each time a visitor loads a page, PHP has to read your site's PHP files and translate them into instructions it can run. OPcache saves that work. PHP's OPcache manual describes it this way: "OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request."

Think of it as keeping a translated copy of a document on your desk instead of translating it again for every reader. "Shared memory" means the cache is held in memory that PHP's worker processes share, rather than each one keeping its own copy.

A few facts from PHP's manual help explain how it behaves on real servers:

• It has been bundled with PHP since version 5.5.0 and is loaded as an extension.
• When it is loaded, opcache.enable defaults to 1 (on).
• opcache.enable_cli defaults to 0, so the command-line PHP usually runs without OPcache even when your website uses it.
• An optional disk-based "file cache" (opcache.file_cache) is off by default.

OPcache is a performance feature. It is not a security tool.

What Researchers Reported About OPcache

At headline level, this is what is public:

• Wiz's write-up (21 October 2026) describes four bugs. One is named "OPcache type confusion."
• Wiz lists the demonstration for that bug as "Pre-authentication RCE on WordPress." RCE means remote code execution: running code on the server without permission.
• Wiz's table files it under CVE-2026-109619. Wiz's CVE grouping differs from PHP's own in places; we follow PHP's mapping, which is explained in our CVE-2026-109619 summary.
• On the fix, Wiz says: "the patch provided by the PHP team fixes the issue at its core and eliminates all variants in the patched release."

Wiz gives no OPcache-specific advice. It does not tell readers to disable OPcache or reset it. Its only remediation is the PHP patch.

WordPress was a demonstration target, not the cause. Wiz itself says the content management systems it tested "are representative targets - exploitation does not require one of these CMSs." Our PHP2Shell guide for WordPress covers what this means for WordPress sites.

What the Official Advisories Say, and Don't

PHP published two advisories, GHSA-w8hw-w9fx-j79w for CVE-2026-109618 and GHSA-6wmf-4rv5-p3rp for CVE-2026-109619. Neither one mentions OPcache or any opcache setting.

The php.net announcement of 21 October 2026 lists interim settings for session upload progress, fatal error backtraces, memory limits and request size. None of them is an OPcache setting. Its process instruction is "restart every worker."

Put simply: OPcache is named by researchers as one of the paths, and PHP's fix covers it. There is no OPcache-specific instruction to follow.

Why a Full Restart, Not a Cache Reset

It is tempting to think that clearing the cache would help. It doesn't, and here is why.

The PHP2Shell fix is in the PHP program (the binary), not in the cache. When you install a fixed PHP package, the new program sits on disk, but the PHP processes already running are still the old program. OPcache lives inside those running processes.

PHP's manual says opcache_reset() "resets the entire opcode cache. After calling opcache_reset(), all scripts will be reloaded and reparsed the next time they are hit." That refreshes the cached copies of your site's files. It does not replace the PHP program that is doing the work, so it does not apply the fix. The manual adds that it "only resets in-memory cache, not the file cache."

A full restart of the PHP service stops the old processes and starts new ones from the fixed program. Their in-memory OPcache starts empty, which is normal; it fills again as visitors load pages. Every vendor's PHP2Shell guidance says to restart, and we treat OPcache as covered by that restart rather than as a separate step.

What a full restart means depends on your setup:

The exact commands and how to confirm each restart are in our guide to restarting PHP workers.

Should You Turn OPcache Off?

No source recommends it. PHP's advisories don't, Wiz doesn't, and none of the hosting or vendor statements we read do. Turning OPcache off would slow your site, since it would lose the speed benefit PHP's manual describes, and it would not fix either PHP2Shell flaw. The flaws are in PHP itself, and the patch is the fix.

If someone suggests disabling OPcache as a PHP2Shell fix, ask for their source. As of 23 October 2026, there isn't a first-party one.

What About the OPcache File Cache?

Some servers turn on OPcache's optional file cache, which saves compiled scripts to disk. PHP's manual says it "should improve performance when SHM memory is full, at server restart or SHM reset." SHM means shared memory. In other words, it is designed to survive a restart.

No PHP advisory, research post or vendor statement we found asks site owners to clear the file cache for PHP2Shell. It is off by default, and most sites don't use it. If yours does and you have questions, ask your developer or host, but don't treat it as a required step that nobody has published.

How to Check Whether Your Site Uses OPcache

A temporary phpinfo() page shows an OPcache section with its settings when the extension is loaded. Delete that page as soon as you've read it, because it exposes server details. Our guide on how to check your PHP version explains how to create one safely.

Don't rely on the command line for this. Because opcache.enable_cli defaults to 0, running PHP from a terminal can show OPcache as off while your website is using it. The same command-line caveat applies to the PHP version itself.

Either way, the answer doesn't change what you need to do. Patch and restart whether OPcache is on or off.

What to Do Now

1. Install a fixed PHP release or your distribution's patched package. Our fixed versions table lists them.
2. Fully restart the PHP service for every PHP version that serves a site.
3. Confirm the PHP processes started after the update, and confirm the build (version, build date or package changelog).
4. Leave OPcache settings as they are unless you have another reason to change them.
5. Keep session.upload_progress.enabled=0 in place if you don't need upload progress bars. PHP suggests this until its next regular release because of a separate issue, CVE-2026-115560, that affects even patched releases under an unusual setup.

Conclusion

OPcache is a speed feature, and in PHP2Shell it is one of the paths researchers named, not a separate problem with its own fix. PHP's patch covers it, and a full restart of PHP puts the patch into effect. There is no OPcache setting to change and no cache reset to run. Make the restart part of every PHP update, as our security patching guide recommends. If you'd like a team to patch, restart and verify your servers, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions