Blog

PHP2Shell: how we responded in under 24 hours

Written by Marketing | Oct 26, 2026, 3:59:46 PM

On October 21, two critical vulnerabilities in PHP were disclosed, identified as CVE-2026-109618 and CVE-2026-109619 and commonly known as PHP2Shell. Both could allow an attacker to execute code on a server without needing credentials.

At nsign, within less than 24 hours, the entire identified attack surface was patched. We’ll explain what happened, what we did, and why this case offers an important lesson about security in the age of artificial intelligence.

What is PHP2Shell?

The name is read as “PHP to shell”: from PHP to the shell, the console used to control a server. And it sums up the risk well: exploiting a flaw in PHP to end up issuing commands directly to the system, as if the attacker were sitting right in front of it.

The name follows in the tradition of Log4Shell, the vulnerability that rocked the internet in 2021.

If you want the full technical explanation, you can find it at php2shell.com.

Our Response, Step by Step

When the vulnerabilities were disclosed, nsign’s Technology team took action on three fronts:

  1. Impact analysis. We reviewed our code and infrastructure to precisely identify the attack surface.
  2. Patching. We deployed the patched version of PHP on our platform as soon as the official image became available.
  3. Containment. Where the patch could not be applied immediately, we blocked access to the affected areas.

Result: In less than 24 hours, the entire identified attack surface was secured.

Reflection: An Old Vulnerability, a New Threat

One fact gives us pause: this flaw had been in the PHP code for more than ten years. It’s not new.

What is new is that artificial intelligence is now finding vulnerabilities like this at an unprecedented rate. And that capability is available to both defenders and attackers.

Reacting quickly is necessary, but not enough

That’s why response speed is only part of the equation. To truly protect a platform, you need to:

  • Rely on AI to detect and prioritize risks early on.
  • Designing with a secure architecture, so that a one-off failure doesn’t become an open door.
  • Managing the infrastructure rigorously: continuous patching and proven processes.

Security certified by the ENS

At nsign, we’ve always worked this way, and today this is validated by our certification under the National Security Scheme (ENS), Medium category.

Because security isn’t a project with an end date. It’s a daily practice.

Thank you to the entire Technology team for their speed and thoroughness over the past few days.

Watch the video

Teresa Rojas, nsign’s Chief Technology & Product Officer, explains it in one minute:

LinkedIn video here