DEV Community: JacivaldoCarvalho

PHP2Shell: When the Vulnerability Is in the Runtime, Not Just the Application

JacivaldoCarvalho — Fri, 23 Oct 2026 21:16:00 +0000

What two critical PHP vulnerabilities teach us about SBOMs, containers, DevSecOps, and automated security patching.

In application security, we often focus our efforts on source code analysis, dependency management, and API protection.

But what happens when the vulnerability exists in the runtime responsible for executing the application itself?

On October 21, 2026, the PHP project released emergency security updates addressing two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.

Both received a CVSS v4.0 score of 9.2 and may allow unauthenticated remote code execution (RCE), depending on the conditions required for exploitation.

This incident highlights an important security challenge: an application can have secure code and still be vulnerable because of the infrastructure running it.

1. The Technical Problem: Vulnerabilities in the PHP Core

Unlike common vulnerabilities found in frameworks, libraries, or plugins, PHP2Shell involves internal mechanisms responsible for processing HTTP requests.

The two vulnerabilities have distinct characteristics:

CVE-2026-109618 — Memory corruption during allocation failure handling.

Under certain out-of-memory conditions, PHP may interrupt request processing without properly restoring its internal state. Subsequent cleanup operations may then access uninitialized memory structures.

CVE-2026-109619 — Reuse of invalid global state.

The runtime may retain references to memory regions associated with previous requests. When this state is not properly reinitialized, subsequent requests may access memory that has already been freed.

Potential consequences include remote code execution, sensitive information disclosure, and service disruption.

The risk is not limited to a specific application.

Environments using PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, or LiteSpeed may be exposed, depending on their versions and configurations.

This means that fixing application code alone does not eliminate the vulnerability.

2. Why Updating Dependencies Is Not Enough

Consider an API developed with Laravel and deployed inside a Docker container.

The development team uses static analysis, automated testing, dependency scanning, and CI/CD pipelines.

Even with these practices in place, the base container image may still contain a vulnerable PHP version.

The execution stack extends far beyond application code:

PHP / Laravel Application
        |
Composer Dependencies
        |
PHP Runtime
        |
System Libraries
        |
Container Base Image
        |
Operating System / Host
        |
Cloud Infrastructure

A vulnerability in any of these layers can compromise the security of the service.

For this reason, security must cover the entire execution environment.

This is where Software Supply Chain Security becomes essential.

3. SBOM: Understanding Your Components Before Applying Fixes

A Software Bill of Materials (SBOM) is a structured inventory of the software components used in an application.

It can document packages, libraries, versions, and component identification information.

When a critical vulnerability is disclosed, the operational question is no longer simply:

"Which applications use PHP?"

Instead, it becomes:

"Which applications, containers, and servers are running vulnerable PHP versions, which are exposed to the internet, and which services depend on them?"

Tools such as Syft, Trivy, and Grype help automate this process.

A defensive example using Syft:

syft my-api:latest -o cyclonedx-json > sbom.json

This command generates an inventory of the components identified in the container image.

Next, we can perform a vulnerability scan:

trivy image my-api:latest

These checks help identify potentially affected components, but they do not replace validation against official vendor security advisories.

It is also important to remember that Linux distributions may apply security fixes through backporting, preserving version numbers that may still appear outdated.

Therefore, vulnerability assessments must consider both the origin of the packages and their actual patch status.

4. Containers Do Not Eliminate Runtime Vulnerabilities

A common misconception is that using Docker automatically makes an application secure.

Containers provide isolation mechanisms, but they do not fix vulnerabilities in the components running inside them.

If an image contains a vulnerable runtime, creating new containers from that image simply reproduces the problem.

Figure 1: Multiple containers created from the same vulnerable image inherit the affected PHP runtime. Container isolation does not fix vulnerabilities in the underlying software components.

For PHP2Shell, the PHP project released the following patched versions:

PHP Branch	Patched Version
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Older, unsupported versions require additional attention, migration, or security patches maintained by specific vendors.

One defensive approach is to update the base image to a patched runtime version:

FROM php:8.4.27-fpm

WORKDIR /var/www/html

COPY . .

CMD ["php-fpm"]

This example illustrates a runtime update but is not intended to represent a complete production-ready Dockerfile.

After updating the runtime, the image must be rebuilt, tested, and deployed to replace existing containers.

A basic workflow could look like this:

docker build --pull --no-cache -t my-api:patched .
docker run --rm my-api:patched php -v
trivy image my-api:patched

In production environments, verified images should be used, preferably pinned by digest. The exact artifact validated during testing should then be promoted to production.

In Kubernetes, the process also requires verifying that Pods are actually running the updated image.

Updating an image in the container registry without replacing running workloads does not guarantee that the vulnerability has been eliminated.

5. DevSecOps: Turning Security Patching into an Automated Process

Incidents such as PHP2Shell demonstrate that response speed is an essential part of operational security.

A DevSecOps strategy can organize the remediation process into a structured workflow:

Inventory → Detection → Prioritization → Remediation → Validation → Monitoring

Within a CI/CD pipeline, these activities can be automated.

For example:

Git Repository
      |
CI Pipeline
      |
Container Image Build
      |
SBOM Generation
      |
Vulnerability Scanning
      |
Automated Testing
      |
Security Policies
      |
Container Registry
      |
Controlled Deployment
      |
Observability

A security policy may prevent images containing known critical vulnerabilities from being promoted, while considering exposure criteria, approved exceptions, and patch availability.

Automation can also create dependency update requests and execute regression tests.

However, automated remediation should not mean uncontrolled deployment.

Runtime updates may introduce compatibility issues.

For this reason, security pipelines should include functional validation, health checks, progressive deployments, and rollback strategies.

The goal is to reduce the exposure window without compromising service availability.

6. A WAF Is a Protection Layer, Not a Permanent Fix

During the PHP2Shell disclosure, vendors such as Cloudflare and AWS published guidance and protective measures to reduce exposure to exploitation attempts.

These measures are particularly valuable when updating every affected system requires additional time.

However, the PHP project made it clear that no complete mitigation can replace patching the vulnerable runtime.

This distinction is essential:

Web Application Firewall (WAF): Helps block potentially malicious traffic patterns.
Security patching: Fixes the vulnerability in the affected component.
Observability: Enables monitoring of exploitation attempts, errors, and abnormal behavior.
Incident response: Establishes procedures when there are indications of compromise.

These controls complement one another.

None should be treated as a universal replacement for the others.

Security should be part of the development process from the very first git init.

Security should not begin when a vulnerability is discovered or when an application reaches production. It must be considered from the earliest stages of development, integrated into architecture decisions, dependency management, CI/CD pipelines, infrastructure provisioning, and runtime maintenance.

This is the foundation of Security by Design and the DevSecOps mindset: security is not a final checkpoint, but a continuous responsibility throughout the entire software lifecycle.

Because security should start with git init, not with a critical CVE.

7. The Role of DevOps and SRE During a Critical Vulnerability

For DevOps and Site Reliability Engineering (SRE) teams, the challenge does not end when the security team identifies a vulnerability.

Teams must determine which services are affected, assess the potential impact, and apply fixes safely.

A structured response may include:

Identification: Locate servers, containers, and images running affected versions.

Prioritization: Evaluate internet exposure, service criticality, and potential exploitation paths.

Containment: Apply temporary network and WAF controls when appropriate.

Remediation: Update packages and images, rebuild artifacts, and replace affected workloads.

Validation: Run tests, verify runtime versions, and monitor operational indicators.

Investigation: Analyze logs, events, and evidence of potential compromise. Applying a patch removes the known vulnerability, but it does not automatically resolve the consequences of a previous intrusion.

From an SRE perspective, the response must balance security and reliability.

Metrics such as time to identification, time to remediation, inventory coverage, and deployment success rate help assess operational maturity.

It is also important to establish emergency patching procedures that do not depend exclusively on regular maintenance windows.

8. Automated Patching: Moving from Reaction to Prevention

The most important lesson from PHP2Shell goes beyond the two vulnerabilities themselves.

It highlights the need to transform security into a continuous operational capability.

A mature organization should be able to answer questions such as:

Which vulnerable components are currently running in production?
Which container images and services depend on those components?
Is a patched version available?
Which workloads need to be rebuilt?
How can the fix be validated without causing downtime?
How can we demonstrate that every affected environment has been updated?

Combining asset inventories, SBOMs, vulnerability scanners, CI/CD pipelines, security policies, and observability makes it possible to build this capability.

AI-powered tools can also assist with vulnerability classification and the preparation of remediation changes.

However, decisions with operational impact must follow authorization policies, testing requirements, and audit mechanisms.

Automation should strengthen response capabilities, not eliminate the controls required to operate critical systems safely.

Conclusion

PHP2Shell demonstrates how vulnerabilities in foundational software components can affect applications regardless of the quality of their source code.

For DevOps and SRE professionals, this incident reinforces five key principles:

Application security also means runtime security.
Containers must be continuously updated and verified.
SBOMs and asset inventories are essential for identifying exposure.
DevSecOps pipelines should incorporate vulnerability detection and remediation.
Observability and automation must be part of the operational security response.

The challenge is not simply discovering a vulnerability. It is knowing where it exists, understanding its impact, and being able to fix it quickly, verifiably, and safely.

This is one of the fundamental challenges of applying Site Reliability Engineering principles to modern cybersecurity.

Technical References

PHP Project: Security Advisory — CVE-2026-109618 and CVE-2026-109619 (October 21, 2026). https://www.php.net/
Docker: Security Update on PHP2Shell: Impact for Docker Customers (October 22, 2026). https://www.docker.com/blog/security-update-on-php2shell-impact-for-docker-customers/
Cloudflare: Cloudflare deploys protections against php2shell vulnerability (October 21, 2026). https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
AWS Security Blog: Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (October 21, 2026). https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/
Red Hat: RHSB-2026-013 — PHP request handling memory corruption. https://access.redhat.com/security/vulnerabilities/RHSB-2026-013

Building JC SRE NetProbe: A Python CLI for Network Health Checks, DevOps, and SRE

JacivaldoCarvalho — Fri, 23 Oct 2026 03:40:13 +0000

Introduction

As a Telecommunications Engineer interested in Networking, DevOps, and Site Reliability Engineering (SRE), I've always been fascinated by how different layers of network infrastructure work together to deliver reliable services.

When an application becomes unavailable, the problem isn't necessarily the application itself.

It could be a DNS resolution issue, a TCP connection failure, an expired TLS certificate, or an HTTP service returning an unexpected response.

Understanding where the failure occurs is an important part of troubleshooting.

With that in mind, I built JC SRE NetProbe, an open-source Python command-line tool designed to simplify network connectivity checks and basic service health diagnostics.

🔗 GitHub: https://github.com/jacivaldocarvalho/jc-sre-netprobe

What is JC SRE NetProbe?

JC SRE NetProbe is a lightweight Python package that provides network diagnostic utilities through a command-line interface (CLI) and a Python API.

The project brings together several common network checks into a single tool, making it useful for telecommunications professionals, network engineers, DevOps teams, and SRE practitioners.

Its main capabilities include:

TCP connectivity checks with latency measurement
DNS resolution checks
HTTP/HTTPS endpoint health checks
IPv4 and IPv6 network information
TLS certificate validation and expiration information
Configurable timeouts
Structured JSON output
Exit codes designed for automation

The goal is straightforward: make network troubleshooting easier to execute, understand, and automate.

Why I Built It

In network operations and infrastructure troubleshooting, engineers often need to perform multiple checks to identify why a service is unavailable.

For example, consider an API endpoint that suddenly stops responding.

Several questions immediately come to mind:

Is the hostname resolving correctly?
Can a TCP connection be established?
Is the TLS certificate valid?
Is the HTTP endpoint responding as expected?

Each question investigates a different part of the service delivery process.

I wanted to create a Python tool that could perform these checks consistently while also providing structured results suitable for scripting and automation.

JC SRE NetProbe is a practical project that connects my telecommunications background with software development and SRE practices.

Getting Started

JC SRE NetProbe requires Python 3.11 or newer.

Install the package using pip:

pip install jc-sre-netprobe

Once installed, the CLI is available directly from your terminal.

1. Checking TCP Connectivity

To verify whether a remote service accepts TCP connections:

jc-sre-netprobe tcp github.com 443

This checks connectivity to GitHub on TCP port 443.

TCP connectivity checks are useful when investigating service availability, firewall restrictions, and network connectivity problems.

2. Checking DNS Resolution

DNS plays a critical role in connecting applications to network services.

To check hostname resolution:

jc-sre-netprobe dns github.com

This helps determine whether a hostname can be resolved before investigating higher-level protocols.

3. Checking HTTP/HTTPS Services

A successful TCP connection doesn't necessarily mean that an application is healthy.

To perform an HTTP health check:

jc-sre-netprobe http https://github.com

This provides an application-layer check of the endpoint.

4. Inspecting TLS Certificates

TLS certificates are essential for secure communication.

Expired or invalid certificates can cause application failures even when the underlying network is operational.

To inspect a server's TLS certificate:

jc-sre-netprobe tls github.com

You can also configure a timeout:

jc-sre-netprobe tls github.com --timeout 3

5. Working with IPv4 and IPv6 Networks

The tool also provides network information for IPv4 and IPv6 address ranges.

For example:

jc-sre-netprobe network 192.168.1.0/24

This functionality can be useful when working with IP addressing and network infrastructure.

Designed for Automation

One of the important aspects of JC SRE NetProbe is its ability to integrate with scripts and operational workflows.

JSON Output

For example:

jc-sre-netprobe --json tls github.com

Structured output makes it easier to consume results programmatically and integrate checks into other tools.

Operational Exit Codes

The CLI uses exit codes that can be interpreted by automation systems.

Exit Code	Meaning
0	Target is healthy or check succeeded
1	Target is unhealthy or unavailable
2	Invalid CLI usage or input

For example:

jc-sre-netprobe tcp github.com 443
echo $?

This behavior makes the tool useful in shell scripts, CI/CD pipelines, and operational checks.

Using JC SRE NetProbe with Python

In addition to its CLI, the package provides a Python API.

For example, a TCP connectivity check can be performed directly from Python:

from jc_sre_netprobe import tcp_check

result = tcp_check("github.com", 443)

print(result)

TLS checks are also available:

from jc_sre_netprobe import tls_check

result = tls_check("github.com")

print(result)

This allows developers to reuse the network probing functionality inside their own applications and automation scripts.

Development and Code Quality

Beyond implementing network checks, I wanted this project to follow good Python development practices.

The repository includes:

Ruff for linting
Mypy for static type checking
Pytest for automated testing
Coverage for test coverage analysis
GitHub Actions for CI/CD
PyPI Trusted Publishing for package releases

The CI pipeline validates the project against Python 3.11, 3.12, and 3.13.

These practices help make the project more maintainable and provide a foundation for future improvements.

Networking Meets Site Reliability Engineering

One of the aspects I enjoy most about this project is how it connects traditional networking concepts with modern SRE practices.

In telecommunications and network engineering, troubleshooting frequently involves understanding protocols, connectivity, addressing, and service behavior.

In SRE, these same concepts are essential for investigating reliability and availability.

JC SRE NetProbe brings these perspectives together through lightweight black-box checks.

It isn't intended to replace comprehensive monitoring and observability platforms. Instead, it provides focused diagnostic utilities that can complement existing operational workflows.

What's Next?

I plan to continue improving JC SRE NetProbe as I explore new ideas in network automation, Python development, DevOps, and SRE.

Some areas worth exploring include additional diagnostic capabilities, improved automation integrations, and more examples of real-world usage.

As an open-source project, feedback, suggestions, and contributions are welcome.

Final Thoughts

Building JC SRE NetProbe has been an opportunity to combine my telecommunications engineering background with my interest in software development and infrastructure reliability.

I believe that building practical tools is one of the best ways to deepen technical knowledge while contributing something useful to the community.

If you work with networking, telecommunications, DevOps, or SRE, I'd love to hear your thoughts.

What network diagnostic checks do you use most frequently in your daily work?

Feel free to explore the repository, open an issue, or contribute.

⭐ GitHub: https://github.com/jacivaldocarvalho/jc-sre-netprobe

Thanks for reading!

Jacivaldo Carvalho

Telecommunications Engineer | Networking | DevOps | SRE