DEV Community

Cover image for Two core RCEs in one week, neither needs a sleepless night
Sammi De Blas
Sammi De Blas

Posted on Originally published at sammideblas.com

Two core RCEs in one week, neither needs a sleepless night

The main case

The PHP2Shell patches shipped on October 21: two vulnerabilities in the core of the language, CVE-2026-109618 and CVE-2026-109619, CVSS 9.2 (Source: helpnetsecurity.com).

They allow unauthenticated remote code execution, meaning someone outside can run whatever they want on the server without an account or a password.

The flaw is fixed in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

What stands out is the timeline.

AWS detected exploitation attempts from October 17, four days before the patch existed (Source: helpnetsecurity.com).

And it reaches further than it looks. WordPress, Magento, Drupal or Nextcloud can be exposed even when their own code is clean, because the flaw lives in the interpreter that runs them.

The second case arrived almost at the same time. Node2Shell, CVE-2026-111497, also CVSS 9.2, is an out-of-bounds write in the Node.js Brotli decoder that allows unauthenticated remote code execution (Source: cryptobriefing.com).

The Codex Security team at OpenAI found it, and the patches are in versions 22.23.4, 24.22.1 and 26.12.1.

One curious detail repeats in both: LLM agents found them, not a human researcher spending weeks with a debugger.

Not an isolated case

The week closes with a third episode that fits the same pattern.

On October 24 it was confirmed that Node2Shell also affects Bun, the Python brotli and brotlicffi libraries, Envoy and Istio. A public proof of concept already demonstrates remote code execution in a lab, though there is no confirmed exploitation in production (Source: thehackernews.com).

The common shape of the three cases is clear.

A flaw in an infrastructure piece almost nobody audits, a maximum score, a patch available in days, and an exposure window measured in hours, not months.

And AI itself is accelerating the discovery.

That changes the pace at which advisories appear, not the damage each one does.

The other side

The same week brings the opposite face.

Microsoft attributed to Storm-0940, a China-linked group, the abuse of ConnectWise OAuth credentials with the ARTEX framework (Source: microsoft.com).

The numbers of the attack are what matter.

2,250 Microsoft 365 tenants probed at 2,900 access attempts per minute, after a password spray against 327 accounts in 8 organizations.

It is not a core RCE: it is a poorly protected credential used at industrial scale, and the result is just as serious.

My reading is that AI accelerates the discovery of flaws, not the mass exploitation of those flaws.

A CVSS 9.2 does not always demand a sleepless night, because not every flaw has a universal exploit that works against any installation. This comes up a lot in CySA+.

What does demand a sleepless night is knowing whether your exposed surface is on the list.

What to check

  • PHP and Node.js version. Check whether your servers run 8.2.35, 8.3.36, 8.4.27, 8.5.12 or 22.23.4, 24.22.1, 26.12.1. If not, the patch is the first task of the day.
  • Exposed surface. A PHP that only talks locally is not the same as one serving requests from the internet. Prioritize by what is visible from outside, not by the CVE score.
  • Indirect dependencies. Check whether your WordPress, your Drupal or your Nextcloud run on an unpatched PHP. The application code can be clean and the flaw still be there.

How would I test it in my lab?

I would spin up a container with the vulnerable PHP version and another with the patched one, then send the same request against both.

I would watch whether the response changes shape, whether the process crashes, or whether a different trace shows up in the log.

With Node.js I would do the same against the Brotli decoder, sending a malformed payload and watching whether the process restarts on its own.

The conclusion I would draw is whether my specific configuration is reachable or whether the flaw stays theoretical for my case.

Closing

Two core flaws in the same week are not an emergency if you know which version you run and what you expose; but they are an emergency if you do not.


Originally published at https://sammideblas.com/notas/two-core-rces-in-one-week-neither-needs-a-sleepless-night

Si has leído hasta aquí... reacciona y comparte -> "la seguridad y la defensa en la era de la IA es cosa de todos los que la usan" ¿No Crees?

Top comments (1)

Collapse
 
the_saint_dac63e343ee8704 profile image
The Saint •

The point about exposed surface over CVSS score is the useful one. The step before it is knowing what you are running at all. Many small teams cannot answer which Node or PHP version each server is on without logging in to check, so the patch day turns into an inventory day. Even a simple list of host, runtime version and what it faces the internet with, kept somewhere current, turns an advisory into a ten minute job.