PHP2Shell and Node2Shell: how a SOC responds to a critical vulnerability

Recent vulnerabilities affecting PHP and Node.js have once again put organisations' response capabilities to the test. Identifying affected systems, checking the protections available and coordinating remediation are among the tasks that call for specialist teams.

Critical vulnerabilities in widely used technologies

On 21 October, the vulnerabilities known as PHP2Shell were disclosed. They are linked to flaws in the way PHP processes requests which, under certain conditions, can allow remote code execution.

Around the same time, Node2Shell was also disclosed, a vulnerability in the Brotli decompression component used by Node.js and other technologies. Exploitation can result in service failures, information disclosure or code execution, depending on the conditions in the environment.

The concern stems from how widely these technologies are used in web applications, corporate portals, digital services and APIs.

PHP2Shell also has a particularly noteworthy aspect: Artificial Intelligence played an important role in the research and discovery of the vulnerabilities. It is an example of how these capabilities are accelerating software analysis and changing response times in Cybersecurity.

However, the fact that an organisation uses PHP or Node.js does not necessarily mean that its systems are exploitable. The risk depends on the versions installed, their configuration, the components in use and their exposure.

■ When an alert of this severity emerges, it is essential to identify the affected assets and prioritise the response based on their criticality.

AI is accelerating vulnerability research and changing response times.

How do Operations teams respond to an alert like this?

The disclosure of a critical vulnerability triggers a series of analysis and review tasks. One of the first is to examine the available information, cross-check security guidance and assess how the environments covered by managed services may be affected.

To do this, specialists can draw on asset inventories, vulnerability analysis tools and security posture management platforms. These capabilities help identify affected versions, insecure configurations and exposed assets, including services or APIs that were not properly recorded in the inventory.

At the same time, teams review the available protections and assess how effective they are against known exploitation techniques.

Specialist teams analyse attack patterns, assess the severity of alerts and prioritise incidents.

For web applications and APIs protected by a WAF, this may involve checking existing signatures, reviewing security policies and considering new rules to block specific malicious requests.

Teams also analyse security events to identify exploitation attempts, check which protections are working and detect possible changes in attack behaviour.

This monitoring is important because information about a vulnerability evolves during the first few days. New exploitation techniques, additional indicators or updates to existing protections may emerge.

■ Specialists need to interpret these changes and decide whether adjustments are required, while ensuring that new rules do not inadvertently block legitimate users.

The analysis also needs to identify services and APIs that are missing from the inventory.

The value of a SOC: analysing, prioritising and coordinating the response

A critical vulnerability can generate thousands of exploitation attempts in a short period of time. However, receiving a high volume of attack attempts does not necessarily mean that a compromise has occurred.

One application may be successfully blocking thousands of malicious requests, while another system with far less activity may show indicators that warrant urgent investigation.

The experience of SOC analysts is essential in distinguishing between these situations. By monitoring and correlating events, specialist teams can analyse attack patterns, assess the severity of alerts and prioritise incidents according to their potential impact.

In particularly critical situations, teams may also step up monitoring of affected assets and increase the SOC's analysis and response capacity.

Specialists in Telefónica's SOC identify affected assets, review protections and coordinate remediation.

Managing the situation also requires coordination across different teams. While specialists responsible for protection measures review security policies, application and infrastructure owners need to check affected versions, apply the relevant updates and verify that the vulnerabilities have been remediated.

Perimeter security controls can reduce exposure while this work is under way, although their coverage is limited and depends on the vulnerability itself and the inspection capabilities of the technology being used.

If there are signs that a system may have been compromised, digital forensics and incident response (DFIR) specialists may become involved to determine how access was gained, what actions the attacker took and the extent of the compromise.

Containment measures may also be considered, such as restricting certain communications between systems to make it harder for an attacker to move laterally through the network.

■ Coordination between the SOC, specialist teams and technical owners makes it possible to respond to these situations while taking both security and service continuity into account.

The value of the SOC lies in distinguishing between attack attempts and signs of compromise, and in coordinating the response.

What we can learn from PHP2Shell and Node2Shell

These cases highlight several recommendations for businesses and public administrations.

1. Know your assets and their true exposure. Maintaining an up-to-date inventory, identifying unknown applications and APIs, and regularly assessing vulnerabilities make it easier to determine which systems require priority attention.
2. Apply fixes and verify that they work. Installing the relevant patches remains essential. Where updates require planning, it is worth reviewing which additional measures can temporarily reduce risk and then verifying that the vulnerability has been remediated.
3. Maintain detection and response capabilities. Threats evolve, exploitation techniques change and measures applied initially may need to be adjusted.

PHP2Shell and Node2Shell are recent examples of situations that organisations will continue to face. Specialist expertise, continuous review of protections and coordination with system owners help reduce exposure and respond to security incidents more effectively.

■ A managed SOC provides operational continuity, specialist expertise and the ability to coordinate response across different teams and technologies, always within the agreed service scope.

Knowing your assets, verifying remediation and maintaining response capabilities are essential to reducing exposure.

Cybersecurity

AI-Native SecOps: framework for assessing the maturity of an Artificial Intelligence enabled SOC

September 21, 2026