CISA confirms active attacks against two critical PHP flaws

The U.S. cybersecurity agency CISA confirmed this Monday the active exploitation of two recent vulnerabilities in PHP, the programming language that underpins a large part of the websites and applications used by small and medium-sized businesses. Both flaws, identified as part of the PHP2Shell group, have a score of 9.2 out of 10 in the CVSS system, placing them in the critical range. The attack vector is especially delicate: they allow remote code execution without the need to authenticate to the affected system.

This is not just another theoretical warning. CISA including a vulnerability in its Known Exploited Vulnerabilities (KEV) catalog implies that there is evidence of real-world use against production systems. One of the flaws, CVE-2026-109618, is associated with a memory exhaustion (out-of-memory) issue that ultimately leads to code execution by the attacker. The other shares the same severity and the same type of impact.

Why this matters to an SME

PHP is not a minor technical detail in the Spanish business fabric. It is the foundation of most content management systems and of a good number of internal applications that have been accumulating in SMEs over the years: the corporate website, the online store, the customer portal, the billing panel inherited from a previous provider. When a vulnerability of this type is exploited in the wild, the attacker does not need credentials or to trick anyone with an email: it is enough to find an unpatched installation and launch their payload.

Unauthenticated remote code execution is one of the most dangerous categories that exist. It means the attacker can take control of the server, read databases, install persistent tools, or use the infrastructure as a starting point to move into other systems. In an SME with limited resources, that scenario can translate into a complete halt of commercial activity, a personal data breach with notification obligations, or both at once.

It is also worth bearing the context in mind: attackers do not wait for the technical community to react. Inclusion in the KEV catalog is usually accompanied by an increase in automated scans looking for vulnerable servers. It is a matter of hours, not weeks.

What we recommend the IT team do

The first thing is to locate all the PHP installations in our inventory, including those we do not manage directly because they come bundled with a third-party product. Many SMEs are discovering right now that they have PHP in places they did not even remember: an old plugin, a forgotten administration panel, a marketing tool installed by a provider. Without that map, any patching plan is a lottery.

1. Inventory and prioritize. Identify the PHP versions and affected components, and order the action by exposure: first what is published on the internet, then what is internal.
2. Patch without delay. Apply the available updates for the affected versions. If any system cannot be updated immediately, isolate it behind access controls or temporarily take it offline.
3. Check for signs of compromise. Patching is not enough if the attacker has already got in. Look for anomalous processes, new files in upload directories, unexpected outbound connections, and recently created accounts.
4. Strengthen monitoring. Enable or review alerts for memory errors, traffic spikes to administration routes, and system command executions from the web server.
5. Document the process. Keep a record of what has been patched, what is pending, and who is responsible for each system. In an audit or an incident, that record makes the difference.

This type of warning fits a trend we have already discussed in other posts: an SME's attack surface grows faster than its ability to maintain it. We saw it with the AI agents that escape and with cases such as uCreator and the Android spyware. The pattern repeats: components that get installed, forgotten, and become the entry point.

An opportunity to get things in order

Beyond the urgency of the patch, this incident should serve to rethink how the software lifecycle is managed in the company. An update schedule, an up-to-date inventory, and a clear procedure for responding to critical vulnerabilities are cheap measures compared with the cost of an incident. You do not need a cybersecurity department of twenty people: you need consistency and someone with assigned responsibility.

If your team is not sure where to start, a good first step is to review which services expose PHP to the internet and check whether they are on the latest stable version. It is an afternoon's work that can prevent a problem lasting weeks.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.