# PHP2Shell: Memory Safety, Secure Software Development, and System Resilience in the PHP Runtime

> A technical study of PHP2Shell, CVE-2026-109618 and CVE-2026-109619, examining memory lifetime, OOM, use-after-free, PHP SAPIs, secure software engineering, patch verification and digital forensics.

- Author: Muhammet Ali Köker
- Language: en
- Canonical: https://alikoker.com.tr/en/php2shell-php-memory-safety-and-secure-software-engineering
- Translation: https://alikoker.com.tr/php2shell-php-bellek-guvenligi-ve-guvenli-yazilim-muhendisligi
- Published: 2026-10-22T11:00:00+03:00
- Usage: https://alikoker.com.tr/en/copyright-and-terms-of-use
- Modified: 2026-10-22T11:41:54+03:00
- Verified: 2026-10-22T11:00:00+03:00
- Type: article

## Abstract

PHP2Shell denotes two related memory-safety vulnerabilities in the PHP runtime, identified as CVE-2026-109618 and CVE-2026-109619. This study examines their implications beyond a time-bound security announcement, connecting request lifetime, memory ownership, exceptional control flow, HTTP parsing, worker isolation, secure software engineering, and digital forensics. The first vulnerability arises when an out-of-memory interruption leaves partially initialized internal data that is later handled incorrectly during cleanup. The second involves request-owned memory references persisting within the global state of a long-lived worker and being accessed by a subsequent request. Under demonstrated conditions, these weaknesses permit unauthenticated remote code execution even when the application itself is not the origin of the defect. The discussion synthesizes primary PHP security advisories, PHP Foundation disclosures, CERT-EU guidance, original security research, and established secure-development concepts. It does not claim to reproduce an exploit, audit the patch independently, measure exploit success, or document a personal incident response. [1, 3, 7, 8, 10, 11, 12]

**Keywords:** PHP2Shell, PHP runtime, CVE-2026-109618, CVE-2026-109619, memory safety, Use-After-Free, Out-of-Memory, secure software engineering, threat modeling, digital forensics, defense in depth.

## 1. Introduction and Research Method

Application security is frequently discussed in terms of authentication, authorization, input validation, SQL injection, and client-side script execution. Yet processing one web request involves a chain of components: reverse proxy, HTTP server, server application programming interface (SAPI), language runtime, native extensions, operating system, and application code. A loss of memory integrity or state isolation at any point in that chain can compromise the security boundary, even when the other components follow appropriate secure-development practices. PHP2Shell provides a concrete basis for examining this relationship.

This article distinguishes the existence of a vulnerability, its demonstrated exploitation preconditions, its potential consequences, and practical defensive measures. The PHP project's primary security advisories provide the technical baseline; experimental claims made by security researchers are attributed to their respective reports. Historical release dates and version numbers establish the remediation context, while the central subject is the longer-lived engineering problem of memory lifetime and fault handling. The analysis does not assume a single universal exploit, because a reachable operation, SAPI implementation, runtime configuration, installed extensions, and worker lifetime can materially change the outcome.

From my perspective as an engineer working with high-traffic and critical software systems, normal-case performance is only one dimension of correctness. When work is unexpectedly interrupted, its memory, handles, transient state, and associated dependencies must not compromise subsequent operations. Low latency and high throughput are sustainable only when exceptional paths preserve these invariants. This is an engineering interpretation based on professional systems-development practice; it does not imply that I encountered or tested PHP2Shell in a personal production deployment.

## 2. PHP Runtime Architecture and Trust Boundaries

A PHP application is not merely a collection of scripts interpreted on a web server. The Zend Engine controls significant aspects of value representation, object management, allocation, error handling, and execution flow. Deploying PHP through Apache `mod_php`, PHP-FPM, CGI, or other SAPI implementations affects where a request starts, how it terminates, and which worker state remains available to the next request. These details are SAPI-specific. Two installations with an identical upstream PHP version should not automatically be assumed to expose identical attack paths. [10, 11]

A runtime may parse HTTP headers, request bodies, multipart form fields, uploaded files, and session-related data before ordinary application logic begins. Consequently, validation in an application router cannot guarantee protection from every defect in earlier parsing or runtime stages. The PHP security advisory records an attack route demonstrated with Apache `mod_php` that can be triggered before application code executes. The exact prerequisites for other SAPIs must be read from the corresponding source rather than inferred from the behavior of `mod_php`. [10]

The distinction between request-local memory and persistent worker state is central. Memory allocated for one request may be reclaimed when that request finishes, while the worker process continues serving future requests. If a persistent field still refers to the reclaimed memory, the lifetime contract is broken. Demonstrating that a worker is safe requires reviewing initialization order, cleanup order, exceptional exits, extension callbacks, and transitions between successive requests.

## 3. Memory Ownership, Initialization, and Object Lifetime

Memory safety begins with ownership: which component allocates a resource, how long its representation is valid, which operations may access it, and who is responsible for releasing it. Cleaning up an object whose initialization failed halfway through is not necessarily equivalent to cleaning up a fully initialized object. If allocation status, initialization flags, and ownership transfer are inconsistent, a cleanup routine can mistake an invalid state for a valid object.

Use-After-Free (UAF) occurs when code accesses an allocation after it has been freed. MITRE's CWE-416 description associates this weakness with possible memory disclosure, crashes, corruption, and—in appropriate circumstances—arbitrary code execution. UAF is not a synonym for remote code execution: the consequence depends on reuse of the freed allocation, the type of access, heap layout, and whether the corrupted state can influence execution. [5]

Out-of-Memory (OOM) is a resource-failure condition rather than a vulnerability class by itself. It becomes security-relevant when the runtime's response to allocation failure violates ownership or state invariants. PHP's `memory_limit`, HTTP payload restrictions, and operating-system or container memory boundaries operate at distinct layers. Removing a limit does not universally improve security; it may move an attack from a memory-corruption path toward resource exhaustion or service unavailability. [10]

A useful design invariant is that any persistent reference into request-local memory must be reset or made unreachable before that memory is reclaimed. Another is that partially initialized structures must never be finalized under assumptions reserved for completed initialization. PHP2Shell illustrates how these rules can fail under different exceptional paths.

## 4. CVE-2026-109618: Out-of-Memory Failure and Exceptional Control Flow

CVE-2026-109618 concerns an inconsistency between PHP's early exit on memory exhaustion and cleanup code that may encounter partially initialized internal data. Under affected conditions, the runtime uses `longjmp()` to leave the current execution context after reaching `memory_limit`. Such a jump can bypass ordinary function returns and intermediate initialization logic. If memory exhaustion interrupts parsing of an HTTP form or another vulnerable internal operation, the request shutdown path may handle incomplete objects as though all fields were valid. [10]

The critical factor is not simply the existence of a large incoming request. Which operation is active when the allocation fails, which object members have been initialized, and which cleanup path executes all affect the resulting state. Memory contents inherited from earlier allocations may then be interpreted as meaningful fields. The official advisory describes circumstances in which unauthenticated remote code execution was demonstrated; it does not establish identical exploitation reliability for every deployment mode. [10]

A conceptual sequence can be expressed without exploit payloads: the runtime parses untrusted request data; an internal object begins initialization; allocation fails at a sensitive point; the exceptional path bypasses expected initialization steps; shutdown logic encounters a structurally invalid object. Although the visible consequence can arise during cleanup, the design defect lies in the mismatch between exceptional control flow and the invariants required by that cleanup code.

The upstream remediation replaces the vulnerable immediate `longjmp()` OOM handling with a delayed, graceful soft OOM at a safe virtual-machine point and a hard OOM that terminates execution when a higher threshold is reached. The intent is to preserve normal memory limiting while preventing shutdown from traversing inconsistent intermediate state. A relevant lesson is that a memory-safety vulnerability cannot be repaired merely by hiding an error message: the internal control-flow and resource-ownership contract must be corrected. [10]

## 5. CVE-2026-109619: Stale Global State and Cross-Request UAF

CVE-2026-109619 concerns global state retained by a persistent PHP worker, including error, session, object, or extension information. That state may contain references to memory owned by one request. If the request ends and its heap is freed while a global reference persists, a later request can encounter stale memory before normal initialization overwrites the field. The resulting Use-After-Free is not confined to the original HTTP request. [11]

The official advisory describes this as a relationship between a producer and a consumer. A producer operation publishes request-owned state into a location that outlives the request; a later consumer operation reads or otherwise acts upon it. A fatal error, execution timeout, or memory exhaustion can interrupt the resetting of a field. In other circumstances, a shutdown diagnostic may repopulate an error field after the normal reset. This sequence can leave the worker holding a pointer into released request memory. [11]

The same worker serving both requests is relevant to documented attack paths. This does not mean that all PHP configurations have the same probability of reproducing a given sequence. Application-specific entry points, early initialization and diagnostics, configured features, and process-reuse behavior determine which paths exist. Nor must the application developer explicitly store a dangling pointer: the runtime's own persistent state can be sufficient.

The broader software-engineering concern is a mismatch between logical ownership and physical lifetime. Data logically owned by a request cannot safely be retained in a longer-lived component without an explicit ownership transfer, copying strategy, or invalidation policy. This principle also informs connection pools, reusable worker objects, thread-local state, and asynchronous execution contexts. These are architectural analogies, not claims that they contain the same underlying PHP vulnerability.

## 6. Comparative Root-Cause Analysis

The first CVE principally concerns incomplete state being processed during cleanup of an interrupted request. The second concerns state whose validity extends incorrectly into a later request. In both cases, exceptional execution invalidates assumptions that would have been true along the normal control-flow path. This common property explains why the problem cannot be reduced to one HTTP parameter, one content-management system, or an unsafe function in an application controller.

Security consequences must be differentiated. An invalid cleanup operation may crash a process; a stale reference may disclose memory; particular heap layouts and access primitives may enable a more serious loss of control over execution. The presence of an underlying memory fault does not prove that a specific RCE chain will work against every target. PHP version, SAPI implementation, extensions, deployment choices, and available memory conditions must be treated as independent variables. [7, 10, 11]

CWE terminology helps organize weaknesses but should not replace a root-cause narrative. CWE-416 addresses accessing freed memory, while cleanup of partially initialized data requires analysis of allocation, state flags, control-flow interruption, and ownership transfer. A generalizable secure-review technique is to model all legal state transitions, including failed initialization, error propagation, cancellation, and shutdown, instead of reviewing only named vulnerability signatures.

## 7. HTTP Parsing, Multipart Processing, and Attack Surface

The attack surface of a web application begins before the framework router or API controller. HTTP framing, decoded request-body limits, `multipart/form-data` parsing, file uploads, session initialization, and early runtime diagnostics can operate before application code or outside its validation controls. These stages are particularly relevant to the PHP2Shell disclosures. The official advisories discuss conservative payload-size policies and parsing limits as supplementary exposure-reduction controls. [10, 11]

Checking only the declared `Content-Length` is not an adequate universal model for resource control. Web servers and proxies must consider the actual decoded request, variable counts, multipart part counts, nesting limits, file-upload requirements, and what happens when length metadata is missing or unusable. Applications with no functional need for multipart bodies can remove this capability at an early boundary, reducing exposed parser behavior. Such measures do not eliminate defects within the language runtime itself.

Defense should therefore be assigned to explicit layers. Authentication and authorization protect business operations; frontends enforce request-resource policy; runtime security updates restore memory invariants; operating-system isolation limits the scope of compromise. These controls reinforce rather than substitute for one another. Threat models must include reachable pre-application processing and not stop at framework endpoints.

## 8. SAPI Differences and the Application Ecosystem

The PHP security team identifies Apache `mod_php` as a particularly high-risk setup for documented attack paths, including a path demonstrated before application execution. PHP-FPM should not be regarded as inherently immune; certain demonstrated conditions involve application execution and worker reuse. For `php-cgi`, FrankenPHP, and LiteSpeed/LSAPI, the degree of confirmation differs among paths. Statements based on source-code analysis must be distinguished from complete exploit demonstrations. [10, 11]

Demonstrations involving WordPress, Drupal, and Joomla do not imply that their application code caused these two PHP CVEs. A vulnerable runtime can expose applications whose own code does not contain the particular defect. Conversely, labeling a PHP branch affected is not equivalent to proving a one-request, unauthenticated RCE path for every host in that branch. Deployment-specific preconditions remain material.

A defensible environment inventory should identify the origin and package version of PHP binaries, the executing SAPI, enabled extensions, service accounts, worker pools, simultaneous PHP installations, container images, and the application-to-runtime mapping. The PHP version shown by a command-line executable may differ from the binary actually serving web requests. Asset attribution matters as much as version comparison.

## 9. Release Management, Backports, and Patch Verification

On 21 October 2026, the PHP project published security fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. These values are historical references to the initial remediated releases, not a permanent recommendation to stop at these versions. Later deployments should use a currently supported and security-maintained release for their respective branch. End-of-life upstream branches must be distinguished from distributions or long-term-support vendors that may provide independently maintained backports. [7, 8, 10, 11]

Patch verification cannot rely solely on `php -v`. Linux distributions sometimes retain an older upstream version identifier while incorporating a security patch into their package revision. Canonical's USN-8948-1 demonstrates this distinction for supported Ubuntu distributions. A naive version comparison may incorrectly classify a fixed backport as vulnerable. [2]

Operational acceptance criteria should include asset identification, matching the installed package to the vendor security notice, verifying which binary the active web service uses, restarting or replacing relevant workers, conducting regression tests, and confirming the runtime state afterward. Shared PHP-FPM pools make the scope of a change potentially broader than a single application. The process that is actually executing must be inspected, not merely the package that has been downloaded.

It is reasonable to compare throughput and P95/P99 latency before and after a security rollout. However, an alleged fixed performance cost must not be stated without controlled benchmarks from the relevant environment. Compatibility, capacity, latency, and security are jointly managed properties rather than separate release gates.

## 10. Temporary Controls and Defense in Depth

The PHP advisories emphasize that installing the fixed runtime is the only complete mitigation. Administratively enforcing `memory_limit=-1` may remove a predictable OOM trigger for a confirmed route, but a genuine allocation failure can still occur at the operating-system or allocator level. Removing the request limit can also worsen denial-of-service exposure unless appropriate process isolation and resource ceilings remain in place. It is therefore unsuitable as an unqualified permanent recommendation. [10]

Controls such as `session.upload_progress.enabled=0` and, for PHP 8.5, `fatal_error_backtraces=0` address particular demonstrated paths rather than every possible stale-state condition. The configuration layer and worker restart are relevant. A runtime setting introduced only after application code begins cannot reliably change parsing or initialization already performed. Silencing diagnostics is also different from correcting invalid or deprecated configuration entries. [11]

Reverse proxies and web application firewalls can reduce exposure to known malicious traffic but cannot replace a runtime patch. Cloudflare's PHP2Shell response described a full-transaction detection approach combining HTTP request and response information. Blocking a response from reaching the requester cannot necessarily reverse side effects that may already have occurred on the origin. Network controls, process isolation, privilege restrictions, and verified security updates address distinct failure modes. [4]

Reducing worker lifetime to one request may complicate some cross-request patterns, but it introduces process-creation overhead and can reduce service capacity in high-throughput environments. Such a change must be evaluated against the affected topology and measured operational consequences. The primary remediation remains the upstream or vendor-supported security correction.

## 11. Secure Software Development Lifecycle Implications

Secure software engineering is broader than validating parameters at application entry points. Design reviews should explicitly model resource ownership, component trust boundaries, permissions, exceptional execution, and the state to which a system returns after failure. PHP2Shell highlights the need to treat memory exhaustion, cancellation, timeout, and fatal errors as first-class control-flow cases rather than secondary operational accidents.

Useful review questions include: Which fields are initialized if an allocation fails? How does cleanup distinguish a completed object from a partially initialized one? Can a fatal interruption bypass required resetting? Does shutdown republish state that has already been invalidated? Can the next request observe a prior request's memory? Which native extension callbacks execute during failure and finalization? Answers to these questions can be expressed through explicit lifecycle states and ownership contracts.

A strong testing strategy combines static code review, dynamic analysis, AddressSanitizer or comparable memory instrumentation, allocation-failure injection, fuzzing, and repeated-request regression tests across relevant runtime configurations. Importantly, fuzzing should examine sequences of requests and exceptional outcomes, not just malformed individual inputs. Each technique has blind spots; using one tool is not a proof of complete memory safety. The MITRE CWE-416 guidance likewise identifies fuzzing and static and dynamic approaches as relevant to UAF detection. [5]

Threat modeling should distinguish protected assets, privilege boundaries, untrusted sources, and native-runtime operations. Parameterized SQL protects against SQL injection but does not repair a UAF in the Zend Engine. These controls operate at different layers and remain simultaneously necessary. The broader methods are covered in [Secure Software Engineering: Applied Cybersecurity](/en/secure-software-engineering-applied-cybersecurity) and can be studied alongside [Cybersecurity Engineering](/en/cybersecurity-engineering), where available.

## 12. Performance, Capacity, and Deterministic Failure

In critical production systems, a security control has operational value when its failure behavior can be understood and measured without neglecting availability. Request-memory limits, worker counts, payload sizes, queue capacity, and backpressure must be managed as one system. PHP's application memory limit is not interchangeable with an operating-system process limit or a cgroup boundary. Changing one restriction can alter whether failure is localized, amplified, or propagated to neighboring requests.

Capacity risk is not adequately represented by average latency alone. When memory pressure terminates workers or forces expensive restarts, pool capacity decreases and queues can grow abruptly; tail latency may rise even if normal requests remain fast. The interaction among resource isolation, secure termination, retries, and dependency capacity deserves explicit testing. Optimization should be assessed through end-to-end behavior rather than a single component's nominal benchmark.

My engineering interpretation is that deterministic failure handling is not opposed to performance: it is one of the prerequisites for sustainable performance. A request that relinquishes resources consistently on failure leaves the next request with a reliable initial state. An interrupted request that leaves ambiguous ownership or stale state introduces a low-frequency but potentially repeatable hazard at scale. This is a conceptual systems-engineering conclusion, not a claim to have collected quantitative production measurements for PHP2Shell.

Additional theoretical context is available in [Operating Systems: Processes, Memory, Files and I/O](/en/operating-systems-processes-memory-files-io) and [Red Hat Enterprise Linux System Administration](/en/red-hat-enterprise-linux-system-administration). These are complementary topics rather than substitutes for the PHP security advisories.

## 13. Digital Forensics and Incident Response

Investigating a possible PHP runtime exploitation attempt requires more than reading application-controller logs. If parsing or failure occurs before application routing, important events may not be represented in the application log at all. Relevant evidence sources can include reverse-proxy access records, HTTP server error logs, PHP-FPM or Apache worker events, systemd service changes, operating-system memory pressure and OOM events, unexpected process restarts, file-integrity changes, network connections, and package-installation history.

Potential hunting hypotheses include unusual multipart requests, recurrent memory-limit errors, bursts of 5xx responses, abnormal worker lifetimes, or inconsistent session behavior across requests. None is definitive proof of exploitation. Legitimate uploads, stress testing, internet scanning, and normal service failures can produce superficially similar evidence. Collection should preserve timestamps, integrity, provenance, and the chain of custody appropriate to an investigation. [3, 4, 12]

An incident-response workflow should identify exposed assets and software builds, preserve available evidence, choose isolation measures consistent with service criticality, apply the verified security correction, and then evaluate whether unauthorized activity may have preceded remediation. Successful patch installation does not retrospectively establish that no compromise occurred. Conversely, an HTTP 500 or OOM event by itself does not establish malicious exploitation.

A sound forensic report distinguishes observed artifacts, interpretations derived from those artifacts, and credible alternative explanations. This avoids turning uncertain telemetry into claims about successful compromises, attacker identities, or the number of affected systems. Technical restraint is essential to reliable cybersecurity analysis.

## 14. Discovery, AI-Assisted Security Research, and Coordinated Disclosure

The PHP Foundation reports that observations related to the root cause go back to security work in 2024. During 2026, researchers from Calif, OpenAI, and Wiz separately brought relevant findings and exploitability analyses to the PHP security team. Fixed releases were issued for four supported PHP branches on 21 October 2026. The sequence illustrates the difference between identifying a risky design decision and demonstrating its practical security consequences under suitable conditions. [7, 12]

AI-assisted vulnerability research can accelerate code exploration, correlation of suspicious patterns, hypothesis generation, and evaluation of reported reproductions. The PHP Foundation explicitly describes human responsibility in validating reports and making patch decisions. Neither comprehensive automated discovery nor the elimination of expert review follows from this case. Discovery, reproduction, exploitability assessment, secure patch design, compatibility review, and regression validation are distinct stages requiring different forms of evidence.

Coordinated disclosure is itself an engineering process. Maintainers, operating-system vendors, package distributors, and administrators need time to prepare deployable patches while technical details remain sensitive. Premature information disclosure can facilitate adversarial preparation; excessive delay can postpone remediation. The Foundation's public account records the impact of leaked identifiers and embargo disruption on release coordination. The broader lesson concerns security-maintenance capacity, disciplined communication, and the sustainability of essential open-source infrastructure. [7]

## 15. Risk Interpretation and Study Limitations

A CVSS score describes severity under a particular scoring framework; it is not proof of exploitation in a given organization. The PHP project's 9.2 CVSS v4.0 assessment should be interpreted together with asset criticality, network exposure, deployment configuration, installed patch provenance, and vendor-maintained backports. Scores produced under different CVSS versions are not directly interchangeable without explaining their assumptions. [10, 11]

Technology-use statistics likewise require careful denominators. The prevalence of PHP among websites does not mean that every PHP deployment is exploitable or compromised. Observed exploit attempts in honeypot or network telemetry do not directly provide a count of successful compromises. Some PHP2Shell paths were experimentally demonstrated in specific environments; other possible paths were assessed using source-code analysis. These evidence classes should not be merged. [3, 10, 12]

This article is a technical synthesis of publicly documented research and a secure-systems engineering analysis. It is not an original exploit demonstration, independent patch audit, production telemetry study, or laboratory benchmark. Claims supported by primary evidence are separated from architectural implications inferred from them. Future releases may change version-specific guidance, whereas memory ownership, exceptional control flow, and lifetime invariants remain broadly applicable.

## 16. Engineering Assessment and Conclusion

The enduring significance of PHP2Shell extends beyond the two CVE identifiers. A runtime can operate correctly on its normal path while violating memory and state invariants when execution is interrupted. If initialization, cleanup, and persistent-state reset are not consistent across error paths, the security boundary may fail even when higher-level business logic is well engineered. This lesson is relevant to web runtimes, long-lived service workers, message processors, and other reusable execution environments.

Three principles stand out in my assessment of critical software engineering. First, resource lifecycles must be designed for ordinary and exceptional outcomes together. Second, reusing workers or processes is not merely a capacity optimization; it creates a state-isolation contract that must be verified. Third, remediation should be accepted only after confirming that the executing component actually contains the security correction. These principles connect performance engineering, production reliability, and secure software development.

PHP2Shell consequently illustrates that a software security boundary is established not only by application statements, but also by runtime ownership rules, the sequence of HTTP processing, worker lifetime, and operating-system resource isolation. Secure systems should be evaluated by their ability to return to a safe, well-defined state after failure, as well as their ability to produce correct results under normal conditions.

## References

[1] Calif. [PHP2Shell: Security Research](https://calif.io/php2shell/), 2026.

[2] Canonical. [USN-8948-1: PHP Vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1), October 21, 2026.

[3] CERT-EU. [Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018/), Security Advisory 2026-018, 2026.

[4] Cloudflare. [Cloudflare Deploys Protections Against PHP2Shell Vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection), October 21, 2026.

[5] MITRE. [CWE-416: Use After Free](https://cwe.mitre.org/data/definitions/416.html).

[6] NCSC-NL. [PHP2Shell Tracking Repository](https://github.com/NCSC-NL/php2shell), 2026.

[7] PHP Foundation. [Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/), October 21, 2026.

[8] PHP Project. [PHP News Archive 2026: Critical Remote Code Execution Vulnerabilities](https://www.php.net/archive/2026.php), October 21, 2026.

[9] PHP Project. [Supported Versions](https://www.php.net/supported-versions.php).

[10] PHP Security Team. [RCE via OOM Corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), GHSA-w8hw-w9fx-j79w, 2026.

[11] PHP Security Team. [RCE via Stale Global State](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), GHSA-6wmf-4rv5-p3rp, 2026.

[12] Wiz Research. [PHP2Shell: AI Uncovers Critical RCE Vulnerabilities](https://www.wiz.io/blog/php2shell-php-rce), October 21, 2026.

## Cite This Work

Köker, M. A. (2026). PHP2Shell: Memory Safety, Secure Software Development, and System Resilience in the PHP Runtime. alikoker.com.tr. https://alikoker.com.tr/en/php2shell-php-memory-safety-and-secure-software-engineering

- BibTeX: https://alikoker.com.tr/en/php2shell-php-memory-safety-and-secure-software-engineering.bib
- RIS: https://alikoker.com.tr/en/php2shell-php-memory-safety-and-secure-software-engineering.ris
- CSL-JSON: https://alikoker.com.tr/en/php2shell-php-memory-safety-and-secure-software-engineering.csl.json