PHP2Shell: the discovery that broke half the internet

If you’ve been following the tech news, you’ve probably heard about an earthquake that shook the internet over the past two days. Perhaps you’ve simply come across two strange codes: CVE-2026-109618 and CVE-2026-109619, already informally dubbed “PHP2Shell”. Two vulnerabilities that prompted several organizations to suspend their services as a precaution.

This was not a minor bug on some random website, but two critical vulnerabilities that had lain dormant for more than a decade, since 2011/2012, at the heart of PHP, the language and engine that powers a large share of the websites on the internet, from WordPress blogs to e-commerce platforms.

We want to share with you what happened, how we responded, and what this episode tells us about the future of digital security.

For non-coders: what exactly is “PHP2Shell”?

To understand how serious this is without needing a software engineering course, think of PHP as a car engine and the internet as a highway.

About 15 years ago, PHP’s creators added a feature called session.upload_progress, with a simple goal: when a user uploads a large file, such as a photo or a video, through a web form, the server calculates the upload percentage so it can display that classic progress bar: 20%, 50%, 100%.

The problem? In the internal C code, the language used to build the PHP engine itself, there was a subtle flaw in the way memory was cleaned up when an error occurred.

If an attacker sent a deliberately malformed web request, with thousands of fake headers or scrambled data, the server could run out of memory and enter a state called Out of Memory.

Instead of closing the door and locking everything down safely, the engine left “ghost” memory references dangling and lost. With a second request, the attacker could take advantage of that memory space to inject their own instructions.

The practical result? What security experts call RCE, or remote code execution: the attacker gains the ability to run commands on the server with the permissions of the affected process.

A simple public web form could become a gateway to taking control of a server.

Why was this only discovered 15 years later?

This is one of the most fascinating, and worrying, parts of this episode.

PHP’s code is open source. It has been publicly available for decades. Over 15 years, those lines of code went through reviews, audits and security tests without these flaws being identified.

What changed? Artificial intelligence and the computing power now applied to code analysis are expanding our ability to find problems that previously required far more time and human effort.

Advanced language models, combined with automated code analysis tools and fuzzing, which tests programs with large volumes of unexpected or malformed data, make it possible to explore complex behaviors on a different scale.

AI is speeding up the reading, analysis and correlation of execution flows. This helps those who protect systems, but it can also give more power to those trying to attack them.

A paradigm shift: closed code does not guarantee security

For decades, part of the industry relied on a comfortable idea: so-called security through obscurity.

The logic was simple: “If our code is closed or compiled, attackers will have a harder time understanding how it works.”

But a compiled or closed-source program is not, by itself, a guarantee of protection. Analysis and reverse-engineering tools keep evolving, and AI is accelerating that process.

We can no longer assume that something is secure just because it has always worked the same way.

Security requires multiple layers of protection, a resilient architecture, active monitoring and the ability to respond quickly when a new threat emerges.

How did E-goi respond?

As soon as the international alert was issued, our Engineering and Security team sprang into action.

The priority was clear: protect our customers’ services and data while keeping operations running.

Our response combined immediate mitigation, strengthened input filters, the application of patches and an infrastructure audit.

Our response in the first 24 hours

• October 21: assessment of potentially affected services and servers.
• October 21, afternoon: preventive deactivation of the vulnerable feature, with no service downtime.
• October 21, afternoon: strengthening of input filters to block malformed requests before they reach the applications.
• October 21, night: application of the security updates released.
• October 22, morning: tests to verify the effectiveness of the measures and an audit of 369 servers.
• October 22, throughout the day: continued application of patches and verification of services.

Immediate mitigation without stopping the business

Before updating the entire infrastructure, we applied a preventive measure: we deactivated the vulnerable feature and reloaded the services in a controlled way.

Our customers kept sending campaigns with no interruptions caused by this intervention.

Protection right at the entrance

We strengthened the filters at the infrastructure’s entry points to block anomalous requests.

If a request with thousands of fake headers tried to get in, it was stopped before reaching the application servers.

Audit and search for signs of intrusion

During this process, we audited the servers and the remaining infrastructure components. We cross-checked logs and looked for suspicious files, anomalous connections and other signs of intrusion.

The audit found everything clean, as it should be.

What this episode shows about transparency

When a vulnerability of this magnitude becomes public, assessing its impact can take time. Organizations need to identify the affected systems, apply protective measures and investigate any signs of exploitation.

At E-goi, we believe in transparency, technical rigor and the responsibility of protecting our customers’ data and trust every single day.

Having a team capable of following events, assessing risk and applying protective measures within the first hours of an alert is essential to respond to situations like this.

What can you do to protect your accounts and your business?

Moments of heightened media attention can also be exploited for phishing and social engineering attempts. An email that looks like a security alert may, in fact, be the trap itself.

That is why we are sharing a few practical recommendations:

• Review the security of your passwords: if any are weak, reused or suspected of being exposed, change them. A password manager can help you create and store strong credentials.
• Never reuse passwords: your email password should not be the same one you use on social media or an online store. If one of those services is compromised, your other accounts may be at risk.
• Enable two-factor authentication: whenever possible, use an authenticator app or set up passkeys, where available.
• Be extra careful with suspicious emails and links: if you receive an email asking you to urgently change your password, warning that your account is about to expire or asking you to open unexpected attachments, stop and verify the source. Access the service through its usual address.
• Keep your devices up to date: install security updates for your operating system, browser and the apps you use.

Security is a daily job

Information security requires attention, continuous improvement and teamwork.

Artificial intelligence is giving new capabilities to those who build and protect technology, but also to those who seek to exploit its flaws. The ability to detect, fix and respond must keep pace with that evolution.

At E-goi, we remain vigilant and keep working to protect the services, the data and the trust of everyone who counts on us.