Two vulnerabilities grouped under the identifiers CVE-2026-109618 and CVE-2026-109619 affect the PHP core and may allow an attacker to execute code on servers without authentication or read sensitive information from process memory. Wiz Research disclosed the findings on October 21, 2026, the date PHP released fixes for several security issues related to memory management in the language engine.
The severity reported by Wiz reaches a CVSS score of 9.2. The risk is not limited to a specific application: according to the research, the flaws reside in PHP and can affect even simple programs written in the language. Wiz says the vulnerabilities affect PHP versions dating back to 5.4, and that every version released during the past decade has at least one of the issues described.
What an attacker can do
Wiz grouped four cases of memory safety flaws under two CVEs. The demonstrated impacts include process memory disclosure, memory corruption, and remote code execution (RCE). Reading memory can expose passwords, authentication tokens, API keys, and certificates present in the process, even if the attacker cannot execute code.
To demonstrate the scope, the team developed an exploit called php2shell and demonstrated unauthenticated remote execution in WordPress, Drupal, and Joomla, using the latest container images of those platforms available during testing. Wiz emphasizes that these systems were demonstration targets: the vulnerability is in the PHP engine itself and does not require a flaw in WordPress, Drupal, or Joomla code.
PHP is used across a large part of the web and underpins content management systems and other services. Wiz Research estimates that the language powers 70% of the world's websites. El Español published a different estimate, at 75%. The figures do not match; in either case, both publications describe a widespread technology whose shared execution layer can turn an engine flaw into a problem for many organizations.
Why memory errors matter
The flaws described are related to handling fatal errors during requests, particularly out-of-memory errors. According to Wiz, an interrupted request can leave stale internal references or inconsistent memory state. If a process reuses that state while handling another request, the result can be a memory read or corruption.
One of the technical patterns identified is use-after-free: the program retains or uses a reference to a block of memory after it has been freed. Another case involves type confusion in OPcache, which keeps compiled structures in shared memory. These are difficult classes of errors to exploit because the outcome depends on how memory is organized and reused, as well as on the versions, configuration, and application behavior.
This also explains why updating the application may not be enough. If the flaw is in the interpreter, any service running an affected version of PHP may be exposed, even if its own code does not contain an equivalent error. For technical teams, the risk inventory should include runtime versions and the services that use them, not just each application's repositories.
The role of artificial intelligence
Wiz says the flaws had been in the code for more than a decade, but turning them into functional exploits required chaining several errors, adapting to each target's memory layout, and repeating testing and debugging cycles. The company used Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol during the research, and credits Gemini 4 Argon with a significant contribution to discovery, exploit development, attack detection, and patch verification.
The significance for professionals is not that AI eliminates the need for technical expertise, but that it can reduce the work required to investigate variations and adapt an exploit to different environments. Wiz says frontier models, combined with testing and debugging tools, made a process that would previously have been difficult to implement and scale feasible. The same capability can help find and fix flaws, but it also lowers the practical barrier to exploiting complex vulnerabilities.
The work included coordination with the PHP team, Calif, and OpenAI on discovery, disclosure, and patch verification. Wiz also says it collaborated with providers and organizations such as Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva, and Vercel to prepare guidance, detections, and mitigations for those unable to update immediately.
What teams should do
The primary measure is to update PHP to a fixed version, as Wiz recommends. Organizations should identify servers running PHP and check which version each one uses, including hosting environments and services that are not managed from the same repository as the application. If an update is not immediately possible, apply the mitigations available for the environment and review alerts and logs for anomalous activity.
Wiz recommends watching for signals including unusual multipart requests followed by memory errors or repeated HTTP 500 responses, PHPSESSID cookies of unexpected size or format, and unexplained restarts or changes in PHP processes. The company cautions that these signals can guide an investigation, but patching is the only complete remediation for the flaws described.
PHP also published an informational advisory about session upload progress. The team recommends temporarily disabling session.upload_progress.enabled until the next regular bug-fix release to protect against an unlikely RCE vector. PHP specifies that this case requires an unusual combination: setting session.serialize_handler to php_binary or php_serialize and then changing it to php at runtime using ini_set() before calling session_start(), while keeping upload progress enabled. If the application does not change the serialization handler this way, PHP says the feature can remain enabled. The organization plans to publish a full advisory for CVE-2026-115560 with the next release; this is an additional warning with specific conditions, not a description of all PHP2Shell vulnerabilities.
A security issue that does not end with the patch
Wiz says the four cases detailed do not exhaust the possible variants of this pattern in PHP code and that the patch fixes the problem at its root to eliminate the identified variants. For administrators, the immediate step is to install the applicable update and verify that processes are actually running the fixed version.
The disclosure offers a warning for developers and security leaders: technical complexity no longer guarantees that an old flaw will be difficult to exploit. Code review, testing, memory management, and coordinated response remain necessary; so does treating shared components, such as a language engine, as an essential part of the attack surface.
Sources: Wiz Research, PHP.net, El Español
