~0x64616E69656C
project 03 · response-aware edge security · independent research

The patch is the fix.
What can the edge stop
in the meantime?

The gap between a disclosed vulnerability and a deployed fix is a security problem of its own. This research asks what an nginx-based edge can prevent, which unexpected application outcomes it can detect, and what it can still contain — without making ordinary HTTP/2 and HTTP/3 traffic expensive or fragile.

R0 complete / 2026-10-22
Scoped detection PASS with stock nginx and no new filter.
No pre-delivery detection, containment, H2/H3 validation or production claim.
read R0 results ↗ the motivation ↓ research paths ↓
Prevent · Detect · Contain · VerifyR0 / HTTP/1.1 complete · H2 + H3 untested
01 / MISSION

Protection during
the patch window.

The upstream fix removes the vulnerability. Edge-side measures cannot replace it. But while that fix is being prepared, deployed or verified, the surrounding system may still be able to reduce exposure, reveal unintended outcomes or limit further damage.

FIELD LESSON / PHP2SHELL · OCTOBER 2026

An ordinary response can follow an extraordinary failure.

Runtime compromise may happen before nginx sees response headers. A reused PHP worker can also carry unsafe state from one request into the next. Neither a normal-looking 200 nor a quiet access log proves that execution was safe.

Process lineage monitors may reveal a web worker spawning an unexpected program, but an alert after execution cannot prevent that execution. The aim is to identify which earlier or later protection boundary is actually available.

OPERATING PRINCIPLE
Prevent what can be prevented.
Detect what can be observed.
Contain what can still be contained.

Never confuse mitigation with remediation. Never describe an attempted stop as proof that nothing escaped. A measured finding of no useful new mechanism is a valid outcome.

02 / BOUNDARY

Read the transaction.
Know the limits.

Request admission remains the first place to reject known-invalid work. Response-aware research looks further, without pretending a response tells us everything the application did.

01 / ADMISSION

What entered?

Route, method, declared trust context and request budgets. Restrict reachable inputs where a useful, safe policy exists.

02 / ORIGIN

What happened?

Computation, code execution or other side effects may precede any response. State and causality can span multiple requests.

03 / RESPONSE

What was visible?

Upstream versus final status, headers and bounded signals at a specific response-filter stage.

04 / COMMIT

What was submitted?

Which headers or bytes entered downstream filters, TLS/QUIC or socket output? Replacement may already be too late.

05 / CLIENT

What arrived?

Only a controlled client can verify received and decrypted bytes. A reset cannot retract data already processed.

The hard limit: blocking a response does not roll back origin-side effects. A normal HTTP response does not exclude server compromise. A successful stream abort is not proof that no data was delivered.
The response is evidence.
Not necessarily the truth.R0 demonstrates why ordinary response metadata and a completed server log cannot establish application safety or verified client delivery.
03 / QUESTIONS

Six questions before
one new mechanism.

Define observable invariants and honest failure cases before introducing a filter, a daemon, a challenge or a blocking rule. A mismatch is evidence for investigation, not proof of exploitation.

Q01 / EXPECTATION

What should have happened?

Can a route or operation state its expected status, content type, redirect behavior and size bounds without classifying legitimate variation as suspicious?

R0 / SYNTHETIC ORACLE TESTED
Q02 / CONTRADICTION

What is meaningfully unexpected?

Can a denied route returning 200, an unexpected privileged view or an oversized error be recognized without mistaking the signal for exploit success?

R0 / STATUS + SIZE ONLY
Q03 / VISIBILITY

What does nginx actually know?

Compare request and log variables, header/body filter visibility and a controlled client. Explicitly account for internal redirects, upstreams and cross-request blind spots.

R0 / LOG-PHASE VERIFIED
Q04 / COMMIT POINT

When is a stop already too late?

Separate origin-side effects, response replacement, stream cancellation and verified client receipt. Which bytes can still be withheld without unbounded buffering?

OPEN / CAUSALITY
Q05 / COST

What does protection cost everyone else?

Measure CPU, memory per stream, TTFB, buffering amplification, flow control, backpressure and fairness against an unchanged nginx baseline.

OPEN / PRECISE COST
Q06 / EVIDENCE

What can be proven privately?

Prefer classed route/response metadata and synthetic markers. Do not retain bodies, credentials, raw queries, client identifiers or private application payloads.

R0 / BOUNDED EVIDENCE
Known blind spot: an application may execute unintended code or corrupt persistent worker state and still return an entirely ordinary response. An observation-only mechanism must never imply otherwise.
04 / APPROACH

Detection first.
Containment must earn its cost.

Three possible research paths share the same evidence model, but solve different problems. Their existence does not imply an authorized implementation, a product feature or an operational policy.

A / RESPONSE-AWARE DETECTION

Know what was observable.

R0 validated a bounded expected/observed contract with stock nginx maps, log-phase metadata and an independent client. The result is retrospective, limited to tested status and declared-size signals, and required no response filter.

R0 / full findings ↗
R0 PASS / SCOPED
B / INLINE CONTAINMENT

Stop what is still in flight.

Long-term goal: in isolated synthetic experiments, attempt a hard abort of the affected response or stream. Measure exactly when it happened, which bytes reached the client and what normal traffic paid for it.

LATER / UNPROVEN
C / OUT-OF-BAND RESPONSE

Limit what happens next.

Explore independent host/process observation and bounded reactions when inline response control is too expensive or too late. A daemon may limit later damage; it cannot retract output or execution already completed.

ALTERNATIVE / OPEN
Experimental intervention: if a later task authorizes B, start with hard aborts, not challenge pages or response rewriting. Production behavior remains undecided. An external decision that holds the response inline is still a form of B — with its own latency and failure budget.

Protocol-independent questions. Protocol-specific proof.

R0 COMPLETE / HTTP/1.1 CONTROL

Oracle tested.

23 synthetic cases, 138 primary requests and independently verified client outcomes established a bounded detection baseline. This is not the target transport architecture.

THEN / HTTP/2 VALIDATION

Preserve the meaning.

Apply the same response contract to multiplexed streams. Independently test cancellation, flow control, backpressure and effects on neighboring streams.

THEN / HTTP/3 VALIDATION

Prove it over QUIC.

Repeat the semantic checks under QUIC stream and packet behavior. A server reset and client-observed receipt must not be conflated; H2 results do not automatically transfer.

R0 exercised normal, invalid-route, restricted-view, oversized-error and streaming cases, plus legitimate redirects, HEAD, 204/304, partial content, cache/proxy and internal redirect controls. All required controls were covered. No live traffic, private data, exploit reproduction or response-blocking test was run.

05 / FIRST RESULT

One bounded test.
Zero new filters.

The first experiment is complete. The source-audit decision “NO NEW MECHANISM” survived an isolated, synthetic HTTP/1.1 A/B validation — for the response-contract signals actually tested.

R0 / DETECTION A · 2026-10-22 · PASS

Stock nginx was enough for R0.

Built-in maps and bounded access logging detected all injected status and declared-size contradictions. The controlled client observed matching response semantics in both arms. No nginx, BoringSSL or response-filter change was needed.

138primary requests
23cases / 3 repetitions
9 / 9injected signals detected
69 / 69A/B client comparisons matched
Critical limit: nginx logged request_completion=OK for a deliberately truncated chunked response that the client verified as incomplete. A separate synthetic origin-side effect produced an entirely ordinary response and no anomaly. Detection was retrospective; H2/H3, containment and precise overhead remain untested.
R0 methodology, evidence & limits ↗Not an exploit detector or deployed protection.
06 / CONTEXT

Field lessons.
Upstream facts.
Isolated research.

Operational incidents motivate the questions; authoritative advisories and nginx source establish the technical constraints. nxTLS offers measurement discipline, not an automatic integration path.

Measure what escaped.
Not merely what was stopped.An output abort proves an action, not prevention of origin-side effects or absence of client receipt.
R0 / Detection A138-request stock-nginx baseline, 9/9 injected contradictions, delivery and side-effect blind spots, open cost gates↗ Project 02 / nxTLSPinned nginx and BoringSSL upstreams, narrow experiment boundaries and HTTP/2 / HTTP/3 research↗ Project 04 / EdgeAdmission controls, bounded work, trust boundaries and operational security lessons↗ nxTLS / EvidenceRelated H2, HPACK, early-flush and QUIC methods; separate from this project and its decisions↗ PHP / AdvisoryPHP2Shell-era stale worker state: why a single HTTP response cannot tell the whole story↗ process-watcherExternal process-lineage observation and reaction as inspiration, not a preventive guarantee↗ Cloudflare / 2026Full-transaction WAF research: request/response correlation and distinct detection/mitigation phases↗ nginx / UpstreamRequest lifecycle, filter order, output buffering and request finalization↗