DEV Community: Noor Yasser

PHP2Shell: Patch the PHP Runtime, Not Just Your App

Noor Yasser — Sun, 25 Oct 2026 16:49:30 +0000

Originally published on nooryasser.com.

PHP2Shell is the name used for two critical PHP runtime vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both sit below application code, inside PHP's request lifecycle and memory handling.

If you run PHP in production, the main action is simple: patch the PHP runtime and replace every running worker. Updating Laravel, WordPress, Drupal, Composer dependencies, Nginx, or a WAF does not patch the affected engine.

This article explains where the bugs live, which releases fix them, and how to prove that your production fleet actually changed. The vulnerability mechanics and versions come from the primary advisories. The rollout and investigation steps are defensive engineering recommendations.

Why these bugs are different from an application vulnerability

A PHP web request crosses several layers:

the web server or proxy accepts the request;
PHP allocates request state and initializes extensions;
application and framework code run;
PHP cleans up request memory;
a persistent worker may stay alive for the next request.

PHP2Shell breaks assumptions inside that native lifecycle.

A framework login check is too late to protect a bug that can execute while PHP is preparing or cleaning request state. Input validation and authentication still matter, but they are not substitutes for a fixed runtime.

CVE-2026-109618: unsafe recovery from memory exhaustion

The advisory describes an abrupt longjmp() exit after an allocation failure. Some internal request data may still be incomplete, but cleanup later treats it as valid. What should have been a clean memory-limit error can therefore become memory corruption.

The fix changes the failure model. PHP now uses a deferred soft limit handled at a VM safe point, plus a higher hard limit that terminates the process immediately.

This matters operationally after patching. A hard-limit termination may skip shutdown callbacks and can look like exit status 137. Do not classify every post-update worker restart as an attack. Use stderr, container events, kernel signals, and platform telemetry to identify the actual cause.

Also avoid putting the only copy of important business state in a shutdown callback. Durable work needs a recoverable state transition before the worker can disappear.

CVE-2026-109619: request state outlives its memory

The second bug is a use-after-free pattern.

Request-owned state can remain referenced after the request heap has been released. If an interruption skips a reset, the next request handled by the same persistent worker may consume stale state before normal initialization replaces it.

The published research identifies concrete PHP internals, including session ID state, unserializer bookkeeping, and fatal-error backtrace state. These are engine globals, not vulnerable columns in your application database.

Researchers demonstrated remote code execution and separate process-memory disclosure in tested deployments. That proves serious technical impact. It does not mean every PHP installation has the same reachable exploit chain or that every exposed server was compromised.

Keep three findings separate:

Vulnerable: an affected runtime and reachable configuration existed.
Attempted exploitation: logs or telemetry show crafted traffic consistent with the vulnerable path.
Confirmed compromise: host, process, or business evidence shows unauthorized impact.

Fixed upstream releases

The PHP security announcement lists these fixed releases:

PHP line	Fixed release
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 branches need special handling. PHP published minimal source backports for 7.4, 8.0, and 8.1, and some Linux distributions ship their own backported fixes.

That creates an important versioning trap: a distribution package may keep an older upstream base number while adding the security patch in the package revision.

For example, do not compare php -v with 8.3.36 and immediately decide that an Ubuntu package is vulnerable. Check the complete package revision against the security notice for your exact distribution release and repository.

“The package manager says latest” is not evidence unless the configured repository actually contains a fixed build.

Inventory the runtime that serves traffic

Start with read-only checks:

command -v php
php -v
php --ini
php -m
php -r 'printf("PHP=%s SAPI=%s\n", PHP_VERSION, PHP_SAPI);'

These commands describe the CLI binary you invoked. They do not prove that PHP-FPM, Apache mod_php, CGI, FrankenPHP, LiteSpeed, a container, or a serverless image uses the same runtime.

For every production service, record:

hostname and alternate origin;
PHP SAPI and complete version;
package source and vendor advisory;
FPM socket or Apache module;
container image digest;
worker or instance identity;
extension compatibility;
restart and verification status.

A common failure mode is a patched CLI beside an older FPM service. Another is a new image tag with old Pods still serving traffic.

A safe production patch workflow

1. Map the real exposure

Include alternate hostnames, preview environments, old virtual hosts, direct-origin access, replicas outside the main load balancer, scheduled jobs, and autoscaling templates.

2. Select a trusted fixed build

Match both CVEs to either a fixed upstream release or a vendor notice covering the exact package revision. Keep the runtime and native extensions compatible.

3. Prepare recovery

Back up configuration and application data. Keep a known-good patched artifact available. A rollback that restores the vulnerable runtime is not a safe recovery plan.

4. Exercise a canary

Test login, sessions, uploads, imports, checkout, APIs, queues, scheduled jobs, and error handling. Watch error rate, latency, memory, worker churn, and extension compatibility.

Do not send exploit payloads to production to “prove” the bug.

5. Replace the workers

Updating files on disk is not enough. Drain and restart or replace every affected PHP worker and replica.

For an installation that really uses Ubuntu's PHP 8.3 FPM service, the operational sequence might include:

sudo /usr/sbin/php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
sudo systemctl is-active php8.3-fpm

An active service only proves that it is running. Verify the package revision and the runtime reached through the actual serving path.

Restarting Nginx alone does not replace a separate FPM process. Apache mod_php requires replacing the Apache processes that loaded the module.

6. Verify the whole fleet

For containers, rebuild from a fixed base image, publish an immutable digest, roll it out, and confirm that no old digest remains in:

serving replicas;
Jobs and CronJobs;
standby regions;
deployment templates;
rollback targets;
autoscaling definitions.

A successful image build is not proof that production stopped running the old image.

What if you cannot patch immediately?

Temporary containment reduces specific paths; it does not provide a general fix.

The official guidance discusses measures such as disabling session upload progress before request parsing and, for PHP 8.5, disabling fatal-error backtraces. Administrative pool configuration matters because a setting inside application code may run after vulnerable initialization work.

Isolation may be the safer short-term choice: restrict access, disable unneeded upload paths at the frontend, or temporarily remove the affected service while the runtime is repaired.

Treat every workaround as an owned exception with a deadline. Do not let a containment setting become a permanent substitute for upgrading.

Why a WAF is not the patch

Cloudflare reported deploying default protections and observing attack traffic. That is useful defense in depth, but it is not proof that your origin runtime is fixed.

Check that all traffic actually traverses the protected hostname and that no direct origin, alternate domain, preview environment, or internal path bypasses it.

Managed cloud does not automatically answer patch ownership either. Some platforms update supported runtimes; container-based services commonly require the customer to rebuild and redeploy. Get evidence for the exact service you use.

Investigate without overstating the evidence

Amazon Threat Intelligence reported an attempt dated October 17, before public disclosure, followed by broader attempts. Its report also said it was unclear whether those attempts would have succeeded against real systems.

That distinction matters. Preserve relevant evidence from at least October 17 where available:

web and proxy request metadata;
PHP worker crashes and restart reasons;
unexpected child processes;
file changes;
outbound connections;
container and kernel events;
secrets-access anomalies.

An empty Laravel or CMS log does not prove that native request processing was safe. If credible compromise evidence appears, preserve evidence, rebuild from trusted artifacts, rotate affected credentials, and involve incident response.

Applying the patch prevents the repaired bug from being reused. It does not remove an existing foothold.

Completion checklist

Close the patch task only when:

every serving PHP runtime has a documented fix for both CVEs;
all old workers and container images are replaced;
normal business flows pass the canary;
the live SAPI and package revision are verified per instance;
vulnerable rollback and autoscaling artifacts are removed;
investigation findings have a separate owner and evidence record.

References

Read the complete source-backed guide, including vendor-specific package notes and the full reference list: PHP2Shell: where the PHP flaws are and how to patch.

Kubernetes Graceful Shutdown: Drain Traffic Before Your Process Exits

Noor Yasser — Sun, 18 Oct 2026 16:51:41 +0000

Kubernetes graceful shutdown coordinates SIGTERM handling, traffic draining, rollout capacity, and disruption controls into one production contract.

Original article: Kubernetes graceful shutdown: drain traffic before processes exit

A reliable Pod must stop accepting new work, give routing components time to converge, finish or safely release in-flight work, close connections, and exit before its single termination budget expires. Kubernetes can send signals and update endpoints, but it cannot complete a transaction, acknowledge a queue message, or make a side effect idempotent for your application.

This distinction matters during rollouts and node maintenance. A Deployment can look healthy while users still see connection resets, workers duplicate jobs, or containers end with forced SIGKILL.

Start with a shutdown contract

Treat shutdown as an application state machine with explicit invariants:

The instance changes from accepting to draining exactly once.
It rejects or redirects new long-running work after draining starts.
Work already acknowledged is completed, released with a lease, or made safe to retry.
Listeners, workers, buffers, and database clients reach a known state before exit.
Every cleanup step has a deadline shorter than the remaining Pod grace period.

The exact contract depends on the workload:

An HTTP API stops accepting new connections and waits for active requests.
A queue consumer stops polling before it waits for handlers.
A WebSocket service asks clients to reconnect, then closes within a bounded window.
A leader releases or expires its lease before exiting.

Do not hide these different semantics behind one generic delay. The shutdown path should also be idempotent: a second signal or callback must observe the existing drain instead of starting another flush or acknowledging the same job twice.

Understand the real termination timeline

When a Pod gets a deletion timestamp, multiple activities begin close together:

The kubelet starts the local termination flow.
If a preStop hook exists, it runs before the main process receives TERM.
The control plane marks the Pod as terminating and updates Service endpoint state.
The application drains work after receiving the signal.
Anything still running when the grace period expires is forcibly stopped.

The important detail is that the grace countdown starts before preStop. A 15-second hook inside a 60-second budget does not leave another 60 seconds for the application; it leaves roughly 45.

Kubernetes EndpointSlices expose terminating, serving, and ready conditions. A terminating endpoint is normally no longer ready for ordinary Service traffic, but external load balancers, Ingress controllers, service meshes, DNS caches, and keep-alive connections may converge at different speeds. Endpoint removal is necessary; it is not proof that no new packet can arrive.

Official reference: Pod termination flow and EndpointSlice conditions.

Make the process own graceful shutdown

set an internal draining flag and make readiness fail;
stop accepting new connections or queue messages;
tell long-lived clients to reconnect when the protocol supports it;
wait for in-flight work until a bounded deadline;
release leases, flush telemetry, and close database clients;
exit with a result that distinguishes clean completion from timeout.

The container's process 1 must actually receive and forward the stop signal. Shell wrappers that do not use exec, detached child processes, and custom supervisors can swallow or delay SIGTERM. Test the built container image, not only the framework's local development server.

Readiness is a traffic-admission signal, not a shutdown executor. Changing readiness to false helps remove the Pod from normal routing, but it does not close existing connections or finish current work.

Use preStop as a small propagation buffer

A short preStop hook can help when routing components need time to observe endpoint changes before the application exits. Keep it deterministic and small because its runtime is charged against terminationGracePeriodSeconds.

Avoid putting business cleanup into a large shell script that depends on DNS or an unauthenticated admin endpoint. Native application signal handling is easier to test and can apply workload-specific deadlines.

If the hook only waits for routing convergence, measure that delay. Copying a 20- or 30-second sleep from another manifest is cargo-cult reliability.

Official reference: Container lifecycle hooks.

Calculate one explicit grace budget

Size the termination period from measured components:

grace budget >=
  routing propagation buffer
  + longest accepted request or job slice
  + connection close time
  + durable flush or lease release
  + safety margin

Do not use average latency. Use a high percentile, the product deadline, and the retry contract. If requests may run for two minutes, a 30-second grace period cannot make shutdown graceful. Either shorten the request deadline, make the work resumable, transfer ownership, or reserve a larger budget.

Long grace periods are not free. Terminating Pods continue consuming CPU, memory, connections, and sometimes temporary rollout capacity. Often the better solution is a bounded unit of work and a faster checkpoint rather than an arbitrarily large timeout.

A PDB does not control your rollout

A PodDisruptionBudget limits concurrent voluntary disruptions performed through the Eviction API. kubectl drain respects it, so a PDB is useful for planned node maintenance and cooperating eviction clients.

It does not prevent involuntary failures such as node loss or a network partition. It also does not control a Deployment rolling update; rollout capacity is defined by the workload strategy.

Control	What it protects
minAvailable / maxUnavailable in a PDB	Voluntary evictions
maxUnavailable in a Deployment	Serving capacity removed during rollout
maxSurge	Temporary replacement capacity
minReadySeconds	A replacement must remain ready before counting as available
progressDeadlineSeconds	Detects a stalled rollout; it does not automatically roll back

A strict PDB cannot compensate for all replicas living on one node, and a perfect shutdown handler cannot help when the scheduler has no capacity for a replacement.

Official reference: Disruptions and PodDisruptionBudgets and Deployment rolling updates.

A complete starting manifest

The following example keeps a short propagation buffer while leaving most of a 45-second budget for the application:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 4
  minReadySeconds: 10
  progressDeadlineSeconds: 300
  selector:
    matchLabels:
      app: orders-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      terminationGracePeriodSeconds: 45
      containers:
        - name: api
          image: registry.example/orders-api:2026-10-18
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: http
            periodSeconds: 3
            timeoutSeconds: 1
            failureThreshold: 2
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 5"]
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: orders-api
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: orders-api

This manifest is a starting point, not a guarantee. The application still needs bounded SIGTERM handling, retry-safe work, and enough cluster capacity. Also verify that the image contains the shell and sleep; a distroless image often does not.

Observe shutdown as a first-class operation

Useful signals include:

graceful_shutdown_duration_seconds;
forced_shutdown_total;
in_flight_requests or active_jobs;
rejected_during_drain_total;
connection resets and rollout-time 5xx errors;
PDB disruptionsAllowed;
EndpointSlice terminating and serving conditions.

Correlate them with the deployment revision, node-drain events, container exit reason, and resource pressure. Exit code 137 alone is ambiguous: forced termination and memory pressure can both lead to it.

Test failure instead of trusting YAML

Before calling the design reliable:

Send requests that span the shutdown window and start a rollout.
Verify that accepted responses finish without resets.
Drain one node under load and confirm the PDB blocks an unsafe simultaneous eviction.
Make one Pod unhealthy and verify the selected unhealthy eviction policy.
Exceed the cleanup deadline deliberately and ensure the timeout is visible.
Test involuntary cases a PDB cannot prevent: node loss, network interruption, and insufficient replacement capacity.
For workers, kill the process after receiving a message but before acknowledgement and prove retry does not duplicate side effects.

Production checklist

Handle SIGTERM in process 1.
Stop new work before waiting for current work.
Make cleanup idempotent and deadline-aware.
Keep preStop short and count it inside the same grace budget.
Measure routing convergence and request duration.
Configure rollout capacity separately from the PDB.
Spread replicas across failure domains.
Exercise graceful and forced failures under load.

A shutdown is successful only when users see no unexplained errors and acknowledged work remains correct.

The expanded article, including additional decision guidance and references, is available at nooryasser.com.

Production RAG Is an Evidence Pipeline, Not a Vector-Database Demo

Noor Yasser — Fri, 09 Oct 2026 14:26:52 +0000

A production RAG system is not “put documents in a vector database and ask an LLM.” It is an evidence pipeline with two versioned paths: an offline path that parses, chunks, embeds, and indexes authorized content; and an online path that retrieves, reranks, assembles bounded context, and asks the model to answer only from that evidence.

This distinction matters because most real failures happen before generation. The parser drops a table, the chunk loses its heading, the tenant filter is missing, or a deleted source survives in the index. A fluent answer can hide all of those problems.

First decide whether RAG is the right tool

Use RAG when answers depend on large, changing, unstructured knowledge and provenance matters: policies, manuals, contracts, support histories, or technical documentation.

Use something simpler when the problem is simpler:

SQL for exact structured facts and transactional state.
Lexical search for known identifiers, error codes, names, or quoted phrases.
A deterministic API for permissions, account state, and actions.
Fine-tuning when the missing capability is behavior or style, not knowledge.
Full-context prompting when a small, stable corpus fits safely inside the model context.

The router that makes this choice is part of the product. Evaluate it like every other component.

Split indexing from query-time work

The offline path should be idempotent and resume-safe:

Store the original document and its version.
Extract structured text and preserve headings, pages, and source locations.
Create chunks using document structure.
Generate embeddings with an explicit model and pipeline version.
Write searchable points and payload indexes.
Mark the document searchable only after every required artifact is durable.

The online path owns the latency budget:

Authenticate the requester and derive tenant and ACL scope.
Classify or rewrite the query only when justified.
Run dense and lexical retrieval branches.
Fuse and rerank a bounded candidate set.
Hydrate canonical text through an authorized repository.
Build cited context under a deterministic token budget.
Generate an answer, validate citations, and abstain when evidence is insufficient.

Join both paths with stable identifiers such as tenant_id, document_id, document_version, chunk_id, source location, checksum, embedding model, and index version.

Chunk by meaning and structure

A single global chunk size is rarely a production strategy. Prefer:

headings and paragraphs for prose;
function or class boundaries for code;
rows plus headers for tables;
clauses for contracts;
turns for conversations.

A chunk should represent one retrieval idea while still carrying enough context to answer a useful sub-question. Large overlap is an expensive substitute for good boundaries because it multiplies embedding cost and returns near-duplicates.

Parent-child retrieval is useful when narrow chunks search well but the answer needs surrounding explanation: index the child, then hydrate its parent section or immediate neighbors after retrieval.

Treat embeddings as a versioned contract

An embedding belongs to a specific model, input mode, preprocessing pipeline, and output dimension. Changing any of those changes the vector space.

Store the model, dimensions, and pipeline version with every point. Build a new named vector or collection for migrations, backfill it, compare quality and latency, switch reads gradually, and keep a rollback window.

Never mark a document indexed until all intended chunks have the expected embedding version.

Model Qdrant around retrieval and isolation

A Qdrant collection should follow the embedding contract, not the number of business entities. Put filter and provenance fields next to the vector: tenant, document and version IDs, language, content type, ACL labels, timestamps, and source location.

Create payload indexes for fields used in filters. A field being present in payload does not automatically make filtering efficient.

For multitenancy, never accept a tenant filter directly from the public request. Derive it from authenticated scope and inject it into every retrieval branch, including dense, sparse, recommendation, and scroll endpoints.

Retrieve broadly, rerank narrowly

Dense retrieval catches semantic similarity. Lexical retrieval catches identifiers and exact terms. Hybrid retrieval runs both and fuses ranks to improve candidate coverage.

Treat fusion as candidate generation, not final context. Rerank only a bounded candidate set because rerankers are more expensive. Skip reranking when the initial candidates already meet the quality target.

Query rewriting can resolve pronouns or expand abbreviations, but preserve the original query and evaluate the rewrite independently. A generated rewrite can drift from user intent.

Build context as evidence

Context construction should be deterministic:

remove duplicate and near-duplicate chunks;
prefer the newest authorized version;
merge adjacent fragments only when they share a source;
cap evidence per document;
reserve tokens for instructions, user input, and the answer;
attach stable citation IDs to document versions and locations.

Treat retrieved documents as untrusted data. They may contain prompt-injection strings. Retrieved text must never override system rules or request tools.

const candidates = await retrieve({ query, scope, dense: 40, sparse: 40 });
const ranked = await rerank(query, deduplicate(candidates));
const hydrated = await repository.loadAuthorized(
  scope,
  ranked.map((item) => item.chunkId),
);

const context = buildContext(hydrated, {
  maxTokens: 7_000,
  maxPerDocument: 3,
  includeSource: ['documentId', 'version', 'page', 'section'],
});

return generateGroundedAnswer({
  query,
  context,
  requireCitations: true,
});

Those numbers are example budgets, not universal recommendations. Measure them against your corpus, model, and latency objective.

Evaluate every gate

A final-answer score is not enough. Measure:

retrieval recall@k;
ranking quality with MRR or nDCG;
tenant and ACL isolation;
reranker lift;
evidence precision;
citation validity;
supported-claim rate;
abstention quality;
p50 and p95 latency;
token, embedding, and reranking cost;
queue age and index freshness.

Run ablations on the same evaluation set: lexical only, dense only, hybrid, hybrid plus reranking, neighbor expansion, and contextualized chunks. Change one component at a time.

Production checklist

Before launch:

define which questions go to RAG, SQL, search, or tools;
version the parser, chunker, embeddings, and prompts;
index only complete document versions;
derive authorization filters from trusted identity;
create payload indexes for real filter fields;
enforce a deterministic context budget;
validate every citation;
reconcile deletions against vector points;
trace model and component versions;
maintain permission-aware evaluation data;
test cross-tenant retrieval and prompt injection.

The practical goal is not a clever demo. It is a system that fails closed, degrades predictably, and can explain which evidence produced every material claim.

For the full bilingual guide, architecture diagram, and official references, read the canonical article: Production RAG: from chunks to grounded LLM answers.

Prepared by Noor Yasser.