This week, security teams worldwide started patching PHP itself. Two critical flaws in the PHP runtime, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4), leaked online on 20 October 2026, before their planned disclosure. PHP announced an emergency security release the same day and published the fixes on 21 October. Researchers observed exploitation attempts from 21 October. Because the flaws sit in PHP's engine rather than in any one product, every PHP installation that serves web requests is in scope: content management systems, frameworks, admin tools and custom applications all run on the vulnerable engine until it's patched.
Three months earlier, a different "2shell" attack, wp2shell, let attackers take over WordPress sites without logging in.
The two attacks look alike in name, but they broke very different layers. Seen together, they explain how enterprise applications actually get compromised, and what it takes to protect them.
PHP2Shell: when the runtime itself breaks
PHP2Shell is two memory-handling flaws in PHP:
- When PHP runs out of memory in the middle of a request, it can abandon the request with memory only partly set up, and then treat that broken state as valid while cleaning up.
- PHP can keep a reference to memory from one request after that memory is freed, and a later request on the same worker can then use it.
Exploitation isn't trivial (it depends on the server's build and configuration), but it doesn't require logging in. Researchers have demonstrated remote code execution in some common setups, notably Apache's mod_php, and the leaking of PHP worker memory, which can expose passwords, tokens and API keys.
Fixes shipped on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches (7.4, 8.0 and 8.1) have no regular upstream release and rely on distribution or vendor backports; PHP 7.3 and older have no fix at all. One detail matters a lot: running PHP processes keep the vulnerable code in memory until they're restarted, so updating the package isn't enough on its own.
What makes PHP2Shell different is that the quality of your application code offers little protection. On mod_php, an attack can succeed before the application's own code even runs. PHP has stated that no configuration change fully mitigates the flaws; settings changes can reduce exposure, but the only complete fix is patching discipline: knowing every server that runs PHP, updating it, and restarting it.
wp2shell: when the application breaks
wp2shell (CVE-2026-63030 and CVE-2026-60137, disclosed and fixed on 17 July 2026) was the opposite: a pre-authentication attack chain in WordPress's own code, affecting WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1. Public reporting describes it in four steps:
| Step | What happened | The general weakness it illustrates |
|---|---|---|
| 1. Get in | A route-confusion flaw in the REST API's batch endpoint, which bundles several requests into one, let unauthenticated requests reach code they shouldn't | Request routing and permission checks that don't line up |
| 2. Reach the database | That path led to SQL injection in WordPress's query layer | Untrusted input reaching a query |
| 3. Become admin | The injection was used to create an administrator account | No second line of defence once the database was reachable |
| 4. Take over | As administrator, attackers uploaded malicious plugins containing webshells | Admin rights that effectively mean "run any code" |
Here the runtime was fine. The weakness was in how the application routed requests, checked permissions and handled input.
Two layers, two disciplines
| Layer | 2026 example | What fails | The defence |
|---|---|---|---|
| Runtime and libraries | PHP2Shell | The engine underneath every application | Inventory, fast patching, restarts, supported operating systems |
| Application code | wp2shell | Permission checks and input handling | Secure-by-default code: authorization in every method, parameterised queries, few and protected admins |
Many organisations are strong in one discipline and weak in the other. Attackers only need one.
Is Java or Liferay immune?
No platform is immune, but the risks differ by layer.
- Runtime layer: Java manages memory automatically, so the exact type of bug behind PHP2Shell is rare in Java applications. Java has had its own "flaw underneath everything" moment, though: Log4Shell in 2021, a remote code execution flaw in a logging library used by countless Java applications. The lesson is identical: patch the JDK and libraries, not just your own code.
- Application layer: Liferay had its own serious case in 2020 (CVE-2020-7961): unsafe deserialisation of data sent to its JSON web services allowed remote code execution in Liferay Portal versions before 7.2.1 CE GA2. CISA lists it as a known exploited vulnerability. Java doesn't protect you from application-level mistakes.
Why the application layer keeps failing
In most custom applications, security controls are written by hand, endpoint by endpoint:
- An authorization check is added to the API controller, but not to the service behind it. A batch call, a GraphQL query or another endpoint can then reach the same service without the check.
- A query is built by joining strings because it was quicker that day.
- Audit logging and field encryption are planned "for phase two".
AI coding assistants make this faster, not safer. They generate what they're asked for, and nothing that was forgotten in the prompt.
Security by default: how ARAD Studio handles the application layer
ARAD Studio generates the enterprise backbone of Liferay DXP applications: data model, services, APIs, forms and workflow. Security controls are generated into every module rather than left to each developer:
- Authorization in every service method. Permission checks happen in the service layer, not only at the API entry point. A request arriving by any route, whether batch, GraphQL or internal, must pass the same check. That's the kind of defence that stops a request arriving by an unexpected route, as in wp2shell's first step.
- Role-based access on every API.
- Validated input on every field, defined in the data model.
- Database access only through parameterised queries and generated finder methods, so user input is never joined into SQL text. That's the defence against wp2shell's second step.
- Full audit history of every record, with created-by and modified-by tracking, so unexpected changes such as a new privileged account leave a trail.
- Encryption of confidential fields in the database.
- Safe deployment: a database backup before every change and automatic rollback on failure.
That covers the application layer. The runtime layer still needs what PHP2Shell demands of every PHP team: patched platforms, supported operating systems and fast response when the next critical flaw lands.
If you run PHP: what to do this week
- Find every server running PHP, including legacy applications, client sites and admin tools such as phpMyAdmin. On each,
php -vshows the version. - Update to a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package (distributions often keep the old version number and backport the fix). On 7.4, 8.0 or 8.1, use a distribution or vendor backport; on 7.3 or older, upgrade to a supported branch.
- Restart PHP-FPM, Apache or whatever runs PHP. Until you do, the vulnerable code stays loaded.
- If you can't patch immediately, restrict internet access to that server. Configuration changes can reduce exposure, but they don't make an unpatched server safe.
- Check older operating systems. Distributions past their standard support may not receive patched PHP packages without extended support.
- If a server was exposed after 20 October, look for signs of compromise: unexpected
.phpfiles (especially in upload folders), new admin users, unusual outbound connections. Consider rotating credentials stored in PHP applications, since worker memory can leak.
Seven questions for any enterprise application
- Do we know every server and runtime version we're running, and can we patch all of them within days?
- Is authorization checked in the service layer, or only at the API controller?
- Can any public endpoint combine requests (batch, GraphQL), and does every sub-request get the same checks?
- Is user input ever joined into a query string?
- How many administrator accounts exist, and do they all use multi-factor authentication?
- Would we notice a new administrator account within a day?
- Which admin features can run code (script consoles, module uploads, template editors), and who can use them?
Frequently asked questions
What is PHP2Shell? Two critical flaws in the PHP runtime (CVE-2026-109618 and CVE-2026-109619) that leaked on 20 October 2026 and were fixed on 21 October. They can allow remote code execution and memory disclosure on PHP installations that serve web requests. They're fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP processes must be restarted after updating.
Is PHP2Shell the same as wp2shell? No. PHP2Shell is in PHP itself, so any PHP application runs on the vulnerable engine until it's patched. wp2shell (July 2026) was in WordPress's own code and affected specific WordPress versions.
Am I affected if my application is built on Java or Liferay? Not by PHP2Shell, which only affects PHP. But check for PHP elsewhere in your estate (legacy apps, admin tools, marketing sites), and keep your own runtime, the JDK and its libraries, patched with the same urgency.
Does secure-by-default code replace patching? No. It reduces the damage an application-level flaw can do. Runtime flaws like PHP2Shell can only be fixed by updating the runtime.
Not sure how exposed your applications are? Our team helps organisations find every vulnerable runtime, patch quickly and review applications against exactly these risks, as part of our cyber threat hunting service. Talk to us, or see how we build with security by default using ARAD Studio and custom software development.