Two critical vulnerabilities in PHP highlight a strategic challenge for companies: how to ensure that the infrastructure supporting their business is protected against threats that are not always visible?
Digital security often gains priority in companies after an incident. A system becomes unavailable, data is exposed, or an operation ceases to function. At that moment, the problem ceases to be exclusively technological and begins to involve revenue, customers, reputation, and operational continuity.
The disclosure of two critical vulnerabilities in PHP, identified as CVE-2026-109618 and CVE-2026-109619, brings this debate to the forefront again.
The vulnerabilities, associated with the name PHP2Shell, received a severity score of 9.2 on a scale of 10. Depending on the version and execution conditions, they could allow an attacker to remotely execute code on a vulnerable server without prior authentication.
An analysis by Palo Alto Networks identified more than 22 million potentially vulnerable instances in its telemetry. This number does not represent proven compromised systems, but it demonstrates the potential scale of the exposure.
For business owners, CTOs, CIOs, and product leaders, the central issue is not just understanding the vulnerability.
The question is: can your company quickly identify which operations depend on affected components, assess the risk, and ensure that the necessary corrections are applied?
Technological risk is also a business risk.
PHP is used in millions of web applications. It's present in corporate websites, e-commerce platforms, customer portals, and custom-developed systems. It can also be part of third-party solutions used daily by companies.
Since vulnerabilities affect the core of the language, exposure is not limited to a specific application. It depends on the versions used, the configurations, and the characteristics of each environment.
If successfully exploited, such a vulnerability could allow an attacker to execute commands on the compromised server. The consequences depend on the available permissions and the infrastructure architecture.
From a business perspective, the risks include:
- Operational continuity: Unavailability of platforms essential for sales, customer service, or service delivery.
- Information integrity: Unauthorized alteration of data and compromise of applications.
- Confidentiality: unauthorized access to corporate information or personal data.
- Financial impact: Costs of investigation, recovery, service interruption, and incident response.
- Trust and reputation: Loss of credibility with clients, partners, and investors.
Not every vulnerable environment will be exploited, and the existence of a flaw does not mean that an intrusion has occurred. However, when a critical vulnerability can be exploited remotely, identifying the exposure and applying fixes must be treated as management priorities.
What does this episode reveal about technology management?
Incidents like this highlight a recurring difficulty: many companies are familiar with their digital products, but lack a sufficiently up-to-date understanding of all the components that keep them running.
An application may depend on libraries, runtimes, operating systems, hosting services, integrations, and external vendors. Each layer can introduce risks and require specific maintenance processes.
This complexity makes three capabilities particularly important.
1. Visibility over the infrastructure
The company needs to know which applications are in operation, what technologies they use, and who is responsible for their maintenance.
This includes internally developed systems, third-party applications, and solutions that remain in production even after their original developers leave the organization.
Without this inventory, a critical update could go unnoticed simply because no one identified that a particular environment depended on the affected component.
2. Responsiveness
Discovering a vulnerability is only the beginning.
It is necessary to identify the affected environments, assess the criticality of each application, plan the update, validate compatibility, and confirm that the fix has effectively taken effect.
In more complex operations, these activities need to be coordinated between Engineering, Infrastructure, Security, Product, and suppliers.
Responsiveness depends less on improvised actions and more on the existence of processes, responsibilities, and reliable information.
3. Continuous risk management
Patching a vulnerability solves a specific problem, but it does not eliminate the risk of new flaws.
Companies that rely on technology need to establish recurring processes for updating, monitoring, reviewing access, and assessing vulnerable components.
The goal is not to prevent new vulnerabilities from being discovered. That would be impossible.
The goal is to reduce the time between the disclosure of a problem, the identification of the exposure, and the implementation of the necessary measures.
What should CTOs, CIOs, and Engineering leaders evaluate?
Given a critical vulnerability like PHP2Shell, the technical response should begin with identifying potentially affected environments.
The corrected versions released for the maintained PHP lines include 8.2.35, 8.3.36, 8.4.27, and 8.5.12.
Environments using older versions need to be evaluated and updated to a corrected and compatible version. Older installations, outside of official support, may require an additional migration strategy or specialized maintenance.
In addition to the update, the evaluation should consider:
Asset inventory: Which applications and services use PHP, including staging environments, production environments, and third-party solutions?
Outdoor display: Which of these environments are accessible via the internet, and what security controls are in place?
Dependencies and permissions: What resources, credentials, databases, and integrations could be affected if an application were compromised?
Applying the corrections: Were the updates successfully installed in the running environments? Were the services restarted when necessary and the results validated?
Monitoring and investigation: Are there sufficient records to identify exploration attempts and investigate possible signs of compromise?
It is important to distinguish vulnerability assessment from incident investigation. Updating an environment reduces exposure to the patched vulnerability, but does not prove that it was never compromised.
If there are indications of exploitation, the organization should follow an appropriate incident response process, preserving evidence and assessing the extent of the potential compromise.
And what about product and business leadership?
Application security is not the sole responsibility of the infrastructure team.
Product leaders need to consider security among the operational requirements of the products they manage, especially when these products process sensitive information, support critical processes, or represent significant revenue streams.
This doesn't mean that every Product Leader needs to master the details of a PHP vulnerability.
It means ensuring that there are answers to fundamental questions:
- Do we know which vendors are responsible for the security and maintenance of our applications?
- Do we have a designated person responsible for assessing and correcting critical vulnerabilities?
- Were we able to identify which products and operations would be affected by an infrastructure failure?
- Are there criteria for prioritizing repairs based on the criticality and exposure of each system?
- Do we have a contingency plan for situations where an essential application needs to be isolated or temporarily interrupted?
These questions help transform safety from a reactive activity into an organizational capability.
They also allow decisions to be made with greater clarity regarding risks, costs, priorities, and impacts on customers.
Digital security requires governance, not just emergency fixes.
PHP2Shell is a specific case, but the challenge it presents is recurring.
New vulnerabilities are being discovered in languages, libraries, operating systems, and services used by companies of all sizes. The speed at which these problems are identified reinforces the need for processes capable of keeping pace with the evolution of the technological environment.
Artificial intelligence is also expanding the possibilities for vulnerability research and analysis, contributing to transforming the dynamics of digital security.
In this scenario, maintaining a secure infrastructure depends on a combination of visibility, continuous updates, monitoring, vendor management, and responsiveness.
For leadership, the question is not only how much it costs to maintain these controls, but also what the potential cost is of operating without them.
A structured approach allows for the early identification of risks, prioritization of investments, and reduced reliance on emergency responses when a problem becomes public.
Is your infrastructure prepared to respond to a critical vulnerability?
Follow55 supports companies in assessing their digital environments, helping to identify potential exposures, understand technological dependencies, and define remediation priorities.
A technical diagnosis can help answer essential questions: which components deserve attention, which risks need to be prioritized, and what measures are necessary to strengthen the safety and continuity of operations.
If your company hasn't yet assessed the impact of recent vulnerabilities on its environments, now is a good time to begin that analysis.
Portuguese 
English