PHP2Shell: The Security Engineering Lessons We Shouldn’t Have to Learn Twice

When a critical vulnerability makes the headlines, the first challenge for a security engineer isn't writing a risk assessment or sending out another security advisory. It's answering a much more fundamental question: Do we know where we're affected, and can we prove we've fixed it?

In practice, that question can be harder to answer than it sounds. An organization might have multiple repositories, container images, cloud workloads, legacy applications, and development teams using different tools and release processes. A vulnerability disclosed today can quickly become a coordination exercise involving security, developers, infrastructure teams, and application owners.

This is why I see PHP2Shell as more than another vulnerability to investigate. It's an opportunity to revisit the fundamentals of security engineering: knowing what we run, finding vulnerabilities early, prioritizing the right fixes, and building a software development lifecycle (SDLC) that makes the next response easier.

You don't need an enormous security budget or a perfect application security program to start improving. You need visibility, repeatable processes, and the discipline to close the gaps you discover.

A critical vulnerability is rarely just a test of how quickly your security team can respond. It is a test of how well your organization understands its technology stack, how effectively security is integrated into software development, and how quickly engineering teams can turn a vulnerability disclosure into a verified fix.

PHP2Shell is a useful reminder of this.

The vulnerabilities tracked as CVE-2026–109618 and CVE-2026–109619 affect PHP itself and can enable unauthenticated remote code execution. This is not simply a case of an application using a vulnerable third-party library. The underlying runtime is affected, which broadens the scope of discovery and remediation.

For security engineers, that distinction matters.

When a vulnerability like this emerges, the immediate questions are familiar:

• Where are we running the affected technology?
• Which applications and services are exposed?
• Can we identify affected versions quickly?
• Who owns each affected workload?
• How do we remediate without creating unnecessary disruption?
• How do we prevent the same visibility and remediation gaps from recurring?

These are incident-response questions. But they are also software development lifecycle (SDLC) questions.

The organizations best positioned to answer them are not necessarily those with the largest security budgets. They are the ones that have built reliable foundations for software visibility, vulnerability management, and collaboration between security and engineering.

Here are the lessons I believe security engineers should take away from PHP2Shell.

1. You cannot secure what you don't know you have

This is one of the most basic principles in security engineering, yet it remains one of the most common operational gaps.

Imagine receiving a critical vulnerability advisory and discovering that your organization cannot confidently answer a simple question: Where are we running PHP?

You might have an asset inventory, a cloud inventory, a vulnerability scanner, and several application security tools. But do they give you a complete picture of the PHP runtimes embedded in containers, virtual machines, build images, serverless workloads, and legacy applications?

Probably not without some integration and ownership work.

Application inventories and dependency manifests are valuable, but they are not always a complete representation of what is actually deployed and running.

This is where software composition analysis (SCA), software bills of materials (SBOMs), infrastructure inventories, container scanning, and vulnerability management processes work together.

SCA helps identify software components and their known vulnerabilities. An SBOM provides a structured inventory of components and versions. Container and host scanning can help identify vulnerable packages in deployed environments. Cloud and asset inventories help establish where workloads exist.

Together, these capabilities make it possible to move from an advisory to an actionable list of affected systems.

The lesson: inventory is not administrative overhead. It is an incident-response capability.

If your organization cannot map a vulnerable component to an application, environment, owner, and deployment, your remediation process will be slower than it needs to be.

Start by establishing a reliable inventory of:

• Applications and their technical owners.
• Direct and transitive dependencies.
• Runtime versions, including PHP, Java, Node.js, and Python.
• Container images and their base images.
• Production and non-production deployments.
• Internet-facing services and other high-risk workloads.

You do not need to achieve perfect visibility on day one. Start with your most critical applications and expand coverage iteratively.

2. Shift security left, but don't forget production

Shift-left security means identifying and addressing security issues earlier in the software development lifecycle, ideally before vulnerable software reaches production.

For dependency vulnerabilities, this means checking dependencies when developers introduce or update them, not waiting until a periodic scan or penetration test reveals a problem.

Consider a basic CI/CD pipeline:

1. A developer updates a dependency.
2. The pull request triggers dependency analysis.
3. The scanner identifies a known vulnerability.
4. The developer receives actionable feedback.
5. The change is blocked or requires an explicit risk decision, depending on the severity and policy.
6. The issue is resolved before the change reaches production.

This is a much better outcome than discovering the vulnerability after deployment.

However, PHP2Shell highlights an important nuance: not every vulnerability lives in an application dependency.

A vulnerable PHP runtime may be installed in a container base image, a server package, or an environment managed outside the application's dependency manager. Scanning only composer.json or composer.lock will not necessarily discover every affected PHP installation.

That is why shift-left security must be complemented by continuous security validation in production.

A mature approach includes:

• During development: dependency scanning, secret detection, static application security testing (SAST), and secure coding practices.
• During builds: container image scanning, infrastructure-as-code scanning, dependency checks, and SBOM generation.
• Before release: risk-based security gates and verification that critical findings have been addressed.
• In production: asset discovery, runtime and package vulnerability assessment, exposure analysis, logging, and detection.

The objective is not to run every possible security tool at every stage. It is to place the right controls where they can prevent or detect the relevant risks.

The OWASP DevSecOps Guideline provides a useful framework for building these controls incrementally.

Shift left reduces the likelihood of introducing vulnerabilities. Continuous validation helps you find what slipped through. You need both.

3. SCA and dependency scanning: start with what you already have

One of the most practical lessons from a critical vulnerability disclosure is that you should not have to begin your investigation from scratch.

SCA tools help security teams identify known vulnerabilities in open-source and third-party components. They can also provide dependency relationships and, depending on the product, license information and remediation guidance.

But there is an important distinction between knowing that a repository uses a vulnerable library and knowing that an exposed production service runs a vulnerable version of a runtime.

For PHP2Shell, that distinction is particularly relevant because the vulnerabilities affect PHP itself.

Use multiple sources of evidence where necessary: repository manifests and lockfiles, operating system packages, container images, runtime inventories, and deployed workload scans.

Tools worth considering

You do not need to buy an expensive platform before getting started.

Open-source and developer-accessible options

• OWASP Dependency-Check: Identifies publicly disclosed vulnerabilities in supported dependency ecosystems.
• OSV-Scanner: Scans supported projects and dependency lockfiles against the OSV vulnerability database.
• Trivy: Scans container images, filesystems, repositories, and supported infrastructure configurations for vulnerabilities and other security issues.
• Syft: Generates SBOMs to help establish which software components are present.
• Grype: Scans container images, filesystems, and SBOMs for known vulnerabilities.
• OWASP Dependency-Track: Helps organizations track component risk across applications using SBOMs.

These tools serve different purposes. Some focus on application dependencies, others on operating system packages, container images, or inventory management. Check the supported ecosystems and detection coverage before relying on any single tool.

Commercial options

• Sonatype Lifecycle: Commercial software composition analysis (SCA) that identifies vulnerable open-source dependencies, prioritizes component risk, and provides remediation guidance integrated into developer workflows and CI/CD pipelines.
• Mend.io: Software composition analysis and broader application security capabilities.
• Black Duck: Software composition analysis, open-source risk management, and software supply-chain security.
• GitHub Advanced Security: Repository security capabilities including dependency alerts, dependency review, code scanning, and related remediation features, depending on the plan and configuration.
• Wiz: Cloud security capabilities that can help connect vulnerabilities with cloud assets, configurations, and exposure context.

These are examples, not a recommendation to deploy every product. Pricing, feature availability, supported ecosystems, and licensing vary.

If you already use GitHub, start by evaluating its dependency graph, Dependabot alerts, and dependency review capabilities. If you already operate a container registry and vulnerability management platform, investigate whether those tools can provide the visibility you need before introducing another scanner.

The goal is not to maximize the number of security tools in your environment.

It is to answer three questions reliably:

1. What is vulnerable?
2. Where is it deployed, and how exposed is it?
3. What action will reduce the risk?

4. Prioritize by risk, not by the number of findings

A vulnerability scanner can generate hundreds or thousands of findings. That does not mean all findings deserve the same response.

During a critical vulnerability event, security engineering needs to quickly distinguish urgent remediation from routine backlog work.

For PHP2Shell, useful prioritization factors include:

• Severity: How serious is the vulnerability?
• Exploitability: Is exploitation practical, and is there evidence of exploitation in the wild?
• Exposure: Is the affected runtime reachable from the internet or another untrusted network?
• Impact: What data, systems, or business processes could an attacker reach?
• Privilege and blast radius: What could an attacker do after successful exploitation?
• Remediation: Is a supported patch available, and can it be deployed safely?

A critical vulnerability in an internet-facing runtime should generally take precedence over a lower-risk issue in an isolated development environment.

But exposure should not become an excuse to ignore affected systems that appear internal. Internal workloads can still be reachable through compromised accounts, lateral movement, or other vulnerable services.

For PHP2Shell, the immediate priority is to identify affected runtimes and apply the appropriate fixed release or verified vendor backport. Do not assume that a clean application dependency scan proves the underlying runtime is safe.

A useful vulnerability management workflow connects findings to ownership, deadlines, remediation status, and verification.

Without that workflow, even an excellent scanner becomes another source of alerts.

5. AI can accelerate remediation, but it cannot replace engineering judgment

AI is increasingly useful for security engineering, especially when teams must investigate unfamiliar code, understand vulnerability advisories, and develop fixes quickly.

Used appropriately, it can reduce the time between discovery and remediation.

For example, a security engineer can provide an AI coding assistant with a vulnerability advisory, relevant dependency manifests, a container definition, and a sanitized build configuration.

The assistant can help:

• Identify potentially affected package declarations and version constraints.
• Explain dependency relationships and likely upgrade paths.
• Propose changes to Dockerfiles, package manifests, and CI/CD workflows.
• Generate scripts to inventory affected versions across repositories.
• Draft regression tests and remediation checklists.
• Summarize release notes and identify potentially breaking changes.
• Review a patch for obvious omissions and suggest additional validation steps.

AI can also help with repetitive investigation. If you have dozens of repositories, it can assist with producing a consistent report of which manifests, lockfiles, Dockerfiles, and build workflows need review.

This is especially useful for small security teams supporting multiple engineering teams.

However, there is a critical distinction between using AI to accelerate a fix and trusting AI to determine that a system is secure.

For PHP2Shell, the vulnerability exists in the PHP runtime itself. An AI assistant might help update a container image or identify an affected host, but it cannot make a vulnerable runtime safe simply by modifying application code.

The fix must address the actual vulnerable component.

A sensible AI-assisted remediation process looks like this:

1. Establish the facts. Use authoritative vendor advisories and confirmed asset or dependency data.
2. Identify the affected scope. Use scanning and inventory tooling to find affected versions and workloads.
3. Generate candidate fixes. Ask AI to propose updates, migration steps, tests, or automation.
4. Review the changes. Have engineers verify the package versions, configuration, compatibility, and scope.
5. Test the fix. Run regression tests and relevant security checks in a representative environment.
6. Deploy and verify. Confirm the actual running workload uses the fixed version.
7. Monitor the outcome. Review deployment health and relevant security telemetry.

Never send secrets, proprietary code, or sensitive production data to an AI service unless its use is approved under your organization's data-handling policies.

AI should reduce the time spent on repetitive work and help engineers make better decisions. It should not become another unverified dependency in the security process.

6. Where should a security engineer start?

If you are responsible for security engineering and your organization has limited AppSec maturity, it is easy to feel overwhelmed by the number of controls you could implement.

My advice is to focus on a few foundational capabilities first.

Step 1: Establish visibility

Identify your critical applications, repositories, runtime environments, container images, and owners.

Start with the systems that matter most to the business and those exposed to untrusted networks.

Create a repeatable way to answer: Which applications and workloads are affected by this vulnerability?

Step 2: Enable dependency and image scanning

Use the tools already available in your development platform, repository hosting service, or cloud environment.

Enable dependency alerts and review new dependencies in pull requests. Add container scanning where containers are part of your delivery process.

Do not wait until you have a complete security platform to begin.

Step 3: Define remediation expectations

Agree with engineering teams on how quickly critical and high-risk vulnerabilities should be triaged and remediated.

Make exceptions explicit, time-bound, and owned by someone with the authority to accept the risk.

A remediation SLA is only useful if it reflects the organization's risk tolerance and if teams can realistically meet it.

Step 4: Automate the repeatable work

Automate routine dependency checks, scanning, ticket creation, ownership assignment, and reporting where possible.

Use AI selectively to help investigate findings, prepare fixes, and create automation. Keep human review and validation in the loop.

Step 5: Measure whether the process works

Track more than the number of vulnerabilities closed.

Useful measures include:

• Percentage of critical applications with a known owner.
• Percentage of repositories and production workloads covered by appropriate scanning.
• Time from vulnerability disclosure to initial impact assessment.
• Time from confirmed impact to verified remediation.
• Number of overdue critical vulnerabilities.
• Percentage of fixes validated in the deployed environment.
• Number of recurring findings caused by the same underlying process gap.

These metrics help you identify whether the security program is improving or simply generating more activity.

7. Close the gaps after the incident

Remediating a critical vulnerability is necessary, but it is not the end of the work.

Once the immediate risk is addressed, security engineers should ask what the event revealed about the SDLC.

Perhaps some repositories were not covered by SCA. Perhaps container images were built from outdated base images. Perhaps nobody knew who owned a legacy application. Perhaps the team patched production but did not update the underlying image, allowing the vulnerability to return during the next deployment.

These are the loose ends that turn a one-time incident into a recurring problem.

A post-remediation review should consider:

Dependency management: Are manifests and lockfiles maintained? Are dependency updates reviewed regularly? Can teams identify vulnerable transitive dependencies?

Build and release security: Are base images maintained? Are images rebuilt when critical vulnerabilities are fixed? Do release pipelines verify the artifacts being deployed?

Asset ownership: Does every critical application have a technical owner? Can the organization identify affected workloads without relying on individual engineers' memory?

Vulnerability response: Is there a documented process for assessing urgent disclosures, assigning owners, setting deadlines, and validating fixes?

Detection and response: Do logs and security monitoring provide enough visibility to investigate potential exploitation? Are incident-response procedures clear if compromise is suspected?

Continuous improvement: Are findings from incidents translated into new controls, automated checks, or improved engineering practices?

This is where the real value of a security engineering program becomes visible.

The objective is not to eliminate every possible vulnerability. That is unrealistic. The objective is to build a system that can discover vulnerabilities, understand their impact, respond quickly, and learn from each event.

Final thoughts: Build a system that responds well to the next PHP2Shell

Critical vulnerabilities will continue to emerge. Some will affect third-party libraries. Others will affect application frameworks, operating systems, cloud services, or the runtimes on which our applications depend.

We cannot predict every disclosure, and we cannot prevent every vulnerability from reaching production.

What we can do is make our organizations better prepared.

Know what you run. Maintain a useful inventory of your dependencies and deployed workloads. Integrate security checks into development and release processes. Prioritize findings based on real risk. Use AI to accelerate investigation and remediation, but verify every fix. And, after the incident, close the gaps that made the response harder than it needed to be.

For security engineers, the goal should not be to respond heroically to every critical vulnerability.

It should be to build an SDLC that makes the next critical vulnerability easier to discover, faster to fix, and less likely to become a preventable incident.

That is the difference between having security tools and engineering security into the way software is built and operated.