messagefoundry 0.2.13__tar.gz → 0.2.14__tar.gz

{messagefoundry-0.2.13 → messagefoundry-0.2.14}/CHANGELOG.md

@@ -6,6 +6,46 @@ All notable changes to MessageFoundry are documented here. The format follows
 
 ## [Unreleased]
 
+## [0.2.14] — 2026-07-01 — Early Access
+
+**Delta security-audit remediation.** A focused security audit of the surface added since the
+2026-06-10 full review (v0.2.0 → v0.2.13) surfaced seven verified findings; this release fixes all of
+them. No new critical, no SQL injection, no auth bypass, no RCE — the most serious was an
+unauthenticated memory-exhaustion DoS in the new default HL7 parser. Each fix ships with a regression
+test. See [`docs/reviews/DELTA-REVIEW-2026-07-01.md`](docs/reviews/DELTA-REVIEW-2026-07-01.md).
+
+### Security
+- **Bounded the built-in HL7 rich-text repetition escape** (DELTA-01/02;
+  [`_builtin_hl7.py`](messagefoundry/parsing/_builtin_hl7.py)). The tolerant built-in parser (now the
+  default hot-path backend, ADR 0054) expanded `\.inN\`-style repetition escapes with no cap, so a
+  ~15-byte inbound field (`\.in2000000000\`) allocated gigabytes synchronously on the event loop
+  **before the ACK** — an unauthenticated OOM/denial-of-service. The count is now clamped
+  (`MAX_ESCAPE_REPEAT = 512`), and a malformed count no longer raises out of a field read — that had
+  severed the connection and dropped a parseable message with **no disposition**, breaking the
+  count-and-log invariant.
+- **XML-DSig `verify()` now requires an explicit trust anchor** (DELTA-03;
+  [`parsing/xml/signature.py`](messagefoundry/parsing/xml/signature.py)). Called with neither `x509_cert`
+  nor `ca_pem_file`, it previously fell back to signxml's default of trusting **any** certificate that
+  chains to the host's system CA store (origin-blind verification); it now raises `ValueError`.
+  **Behavior change** for the opt-in `[xml]` codec — a caller must pin the expected signer or a partner
+  CA. No in-repo caller relied on the old default.
+- **FhirLookup SMART token endpoint is now egress-gated** (DELTA-04;
+  [`[egress].allowed_http`](docs/CONFIGURATION.md)). A `fhir_lookup` connection composed with
+  `with_smart_backend()` POSTs a signed `client_assertion` to its `smart_token_url`; that host was not
+  checked against the egress allowlist (only the FHIR base host was), so a crafted `smart_token_url`
+  could exfiltrate the assertion to an un-allowlisted host. The lookup and outbound arms now share one
+  gate ([ADR 0043](docs/adr/0043-fhir-read-lookup.md) §D3).
+- **Support bundle no longer discloses the store host/database; its log redaction was widened**
+  (DELTA-05/07; [`support/`](messagefoundry/support/)). The offline support bundle's `status.json`
+  carried the SQL Server `host/database` verbatim — it is now reduced to the backend kind (file basename
+  only for SQLite). The bundled-log redactor previously used a fixed HL7-segment allowlist with no
+  free-text name/DOB heuristics; it now delegates to the engine redactor
+  ([`messagefoundry.redaction`](messagefoundry/redaction.py)) for parity with stored-error redaction.
+- **Inbound HTTP listener rejects ambiguous framing** (DELTA-06;
+  [`transports/http_listener.py`](messagefoundry/transports/http_listener.py)). A duplicate
+  `Content-Length`, a duplicate `Transfer-Encoding`, or the two present together are now refused with
+  `400` per RFC 7230 §3.3.3 — closing an HTTP request-smuggling / desync surface behind a fronting proxy.
+
 ## [0.2.13] — 2026-07-01 — Early Access
 
 The **store connection-scale sizing** wave — right-size the server-DB connection pool to the measured

{messagefoundry-0.2.13 → messagefoundry-0.2.14}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: messagefoundry
-Version: 0.2.13
+Version: 0.2.14
 Summary: Open-source healthcare integration engine — route, transform, and validate messages across many formats and connection types
 Project-URL: Homepage, https://messagefoundry.org/
 Project-URL: Documentation, https://messagefoundry.org/

messagefoundry-0.2.14/docs/releases/DELTA-SECURITY-FIXES-MULTISESSION-PLAN.md

@@ -0,0 +1,197 @@
+# MessageFoundry — Delta Security-Fixes Multisession Plan (2026-07-01)
+
+**Scope.** Remediate the **seven verified findings** from the delta security audit
+([`docs/reviews/DELTA-REVIEW-2026-07-01.md`](../reviews/DELTA-REVIEW-2026-07-01.md)) — the code surface
+that landed since the 2026-06-10 full review (v0.2.0 → v0.2.13). No new features, **no ADRs** (these are
+bug fixes, not decision records). The six candidates the audit *refuted* are out of scope.
+
+**This is a plan, not a build.** Per the project convention, nothing is built until the owner gives an
+explicit "go".
+
+**Why it parallelizes cleanly.** The seven findings touch **five disjoint source-file sets** — there is no
+source-file overlap between lanes. The only shared files are `CHANGELOG.md` and the review doc's status
+column (handled in §D). So all five lanes can run **fully in parallel** with near-zero contention; Lane A
+just takes **merge priority** because it is the only High.
+
+**Autonomy: L1** — workers build + verify (full quartet) + commit **local**; the **owner** opens/merges PRs.
+Single-writer coordination ledger in AI memory. Worktree-per-lane off `origin/main` @ `0febba9`.
+
+---
+
+## A. Findings → lanes
+
+| Lane | Finding(s) | Severity | Fix in one line | Primary file(s) |
+|---|---|---|---|---|
+| **L-A hl7-parser-hardening** | DELTA-01, DELTA-02 | **High** + Medium | Clamp + guard the repetition-escape count in built-in unescape | `parsing/_builtin_hl7.py`, `parsing/peek.py` |
+| **L-B xml-dsig-anchor** | DELTA-03 | Medium | Require an explicit trust anchor in `verify()` (no OS-CA default-trust) | `parsing/xml/signature.py` |
+| **L-C fhir-lookup-egress** | DELTA-04 | Medium | Gate `smart_token_url` against `[egress].allowed_http` on the lookup arm | `pipeline/wiring_runner.py` |
+| **L-D support-bundle-disclosure** | DELTA-05, DELTA-07 | Low + Low | Strip store host/db-name from the bundle; align its redactor with the engine's | `support/bundle.py`, `support/redact.py` |
+| **L-E http-listener-framing** | DELTA-06 | Low | Reject ambiguous CL/TE framing in the request parser | `transports/http_listener.py` |
+
+Each lane = **one coherent PR**. L-A and L-D each fix two findings that share a file/theme, so they stay
+one PR apiece; the rest are one finding = one PR.
+
+---
+
+## B. Lane detail (worktree per lane off `origin/main` @ `0febba9`)
+
+> `scripts/worktree/new.ps1 -Name <lane>` (isolated checkout + branch + `.venv`); cleanup `remove.ps1`.
+> See [`docs/WORKTREES.md`](../WORKTREES.md). Every lane: **new behavior gets a test**, then the full quartet
+> green before the owner PRs it.
+
+### L-A — HL7 parser hardening (DELTA-01 High, DELTA-02 Medium) — **P0, merge first**
+- **Root cause (one line, one block):** `parsing/_builtin_hl7.py:527-528` —
+  `out.append(default_map[value[:3]] * int(value[3:]))` — the repetition count is **unbounded** (DELTA-01
+  DoS) **and** `int(value[3:])` is **unguarded** (DELTA-02 `ValueError`). Contrast the hex branch just below
+  (lines 534-539), which already wraps its `int(...)` in `try/except ValueError: continue`.
+- **Fix:**
+  1. Introduce a small module constant (e.g. `MAX_ESCAPE_REPEAT`, a few hundred) and, in the `.`-prefix
+     repetition branch, wrap the conversion + multiply in `try/except ValueError` and reject counts above the
+     cap. Treat an over-limit or non-numeric count as an **unmappable** sequence → `continue` (drop it),
+     matching the existing "log-and-discard" behavior for other unmappable escapes.
+  2. Defense-in-depth: broaden `parsing/peek.py` `_resolve_builtin` (~lines 189-192) to map `ValueError` to
+     `None` like it already does `IndexError`, so a stray conversion error can never escape a `Peek.field`
+     read.
+- **Tests:** unit — `\.in2000000000\` expands to a **bounded / dropped** result (no multi-GB allocation);
+  `\.inX\`, `\.in \`, `\.br9z\` do **not** raise and the field reads cleanly. Pipeline/integration — a
+  message whose `PID-3.1` carries a malformed count is still **persisted with a disposition** (`RECEIVED`),
+  proving the **count-and-log invariant** holds (DELTA-02's real bite). Use synthetic HL7 only.
+- **Verify:** this is the **default hot-path parser** — run the **full** suite (not a subset), and confirm
+  the parse-fallback guard + count-and-log paths behave. No new deps.
+
+### L-B — XML-DSig anchor enforcement (DELTA-03 Medium)
+- **Fix:** in `parsing/xml/signature.py` `verify()` (~lines 44-60), **raise** `XmlError`/`ValueError` when
+  **both** `x509_cert` and `ca_pem_file` are `None`, instead of forwarding to signxml's "trust any
+  system-CA cert" default. Update the docstring to state an anchor is **mandatory**. Mirror the explicit-key
+  posture already in `transports/signing.py`.
+- **Tests:** a document signed by an arbitrary system-trusted cert **fails** `verify()` when no anchor is
+  passed (now raises); a document verified **with** a pinned `x509_cert` / partner `ca_pem_file` still passes.
+- **Callout (owner sign-off):** this is an intentional **secure-by-default behavior change** — `verify()`
+  now requires an anchor. The audit's caller grep found **no in-repo consumer** relying on the old default
+  (only package `__init__` re-exports import it), so blast radius is a hypothetical external Handler. Flag it
+  in the PR / CHANGELOG as a breaking change for that opt-in codec.
+
+### L-C — FhirLookup egress gate (DELTA-04 Medium)
+- **Fix:** in `pipeline/wiring_runner.py` `check_fhir_lookup_allowed` (~lines 2831-2842), after validating the
+  FHIR base `url`, read `settings.get("smart_token_url")`; if set, require
+  `_http_egress_allowed(token_url, egress.allowed_http)` and honor `deny_by_default` — the exact check the
+  **outbound** arm already performs (~lines 3086-3097). **Factor a shared helper** so the read-side lookup and
+  write-side outbound gates stay in lockstep (they diverged, which is how this gap opened). This realizes
+  ADR 0043 §D3 ("`smart_token_url` must be checked against `[egress].allowed_http`").
+- **Tests:** a FhirLookup with an **un-allow-listed** `smart_token_url` is **rejected** at load (mirror the
+  existing outbound test); an allow-listed one loads.
+- **Note:** sole toucher of the large `wiring_runner.py` among these lanes; if a sibling wave lands there,
+  rebase and re-run the start / reload / dry-run guard tests.
+
+### L-D — Support-bundle disclosure (DELTA-05 Low, DELTA-07 Low)
+- **Fix DELTA-05:** in `support/bundle.py` (~line 137), **omit/redact** the SQL Server store **host** and
+  **database name** from `status.json` — the bundle's stated no-host/no-path contract. Keep the useful
+  non-identifying status (backend kind, health) but drop the DSN-derived host/db.
+- **Fix DELTA-07:** in `support/redact.py` (~line 27), replace the fixed segment allowlist with alignment to
+  the **engine redactor** (`messagefoundry/redaction.py`) — ideally **reuse** it rather than maintain a
+  weaker second redactor — so free-text name/DOB heuristics are applied to bundled logs.
+- **Tests:** bundle `status.json` contains **no** store host/db-name; the bundle log redactor scrubs the
+  free-text PHI patterns the engine redactor catches (parametrize against a synthetic sample).
+- **Note:** two `support/` files, one theme (off-box bundle info-disclosure) → one PR. PHI rule: build the
+  fixtures from **synthetic** data only.
+
+### L-E — HTTP listener framing (DELTA-06 Low)
+- **Fix:** in `transports/http_listener.py` (~line 180) reject **ambiguous framing** per RFC 7230 — a request
+  bearing both `Content-Length` and `Transfer-Encoding`, or **multiple/duplicate** `Content-Length` values →
+  respond `400` and close, rather than parsing one interpretation. (Self-desync is currently blunted by
+  `Connection: close`, so this is hardening the surface, not closing a live smuggle.)
+- **Tests:** a request with duplicate `Content-Length` or `CL`+`TE` is **rejected** (400), not parsed; a
+  well-formed request is unaffected.
+
+---
+
+## C. Land-order
+
+1. **L-A first** — the only High, and it is on the unauthenticated pre-ACK hot path. Merge before a release.
+2. **L-B / L-C / L-D / L-E** — parallel, any order; all lower severity and fully independent. No lane blocks
+   another (disjoint files).
+3. Each lane: **full quartet** green — `ruff format --check` + `ruff check` + `mypy` (strict) +
+   `pytest` (with `QT_QPA_PLATFORM=offscreen`) — **before** the owner opens the PR. Run the **whole** pytest
+   suite, never a subset (the leak-gate / forbidden-content jobs only fire on a full run).
+
+**Suggested session mapping** (they collapse to fit however many sessions you want to run):
+- *Max parallelism:* five worktrees, one per lane.
+- *Recommended (2–3 sessions):* one session owns **L-A** (priority, verify-heavy); a second session sweeps
+  **L-B → L-C** (both small logic + test); a third (or the second, sequentially) sweeps **L-D → L-E**.
+- *Minimum:* a single session does all five sequentially in one worktree, one PR at a time (still five PRs).
+
+---
+
+## D. Contention matrix
+
+| File(s) | Lanes | Resolution |
+|---|---|---|
+| **Source files** (`_builtin_hl7.py`+`peek.py`; `xml/signature.py`; `wiring_runner.py`; `support/*`; `http_listener.py`) | disjoint per lane | **No overlap.** No cross-lane rebasing of product code. |
+| **`CHANGELOG.md`** | all five | Each PR adds its own line (additive). Last-writer rebases, or the **owner consolidates** the five lines at merge. |
+| **`docs/reviews/DELTA-REVIEW-2026-07-01.md`** (status column) | all five | **Do not** have each lane edit the review doc (write contention). The **coordinator/owner** flips each finding's status to *fixed (PR #…)* **once**, after merge. |
+| **Test files** | per lane | Each lane adds tests in its subsystem's existing test module or a new one — disjoint. |
+
+---
+
+## E. Coordination rules
+
+1. **Worktree per lane**, branched off `origin/main` @ `0febba9`. **Never edit a sibling worktree.** Use the
+   lane's own `.venv` (`.\.venv\Scripts\Activate.ps1`) — the six other active worktrees share this repo's
+   history but **not** the checkout.
+2. **Single-writer coord ledger** in AI memory (one session writes live status; others read). One logical
+   lane per session. **This session does not own memory writes unless the owner confirms it** (parallel
+   sessions; last write wins).
+3. **Autonomy L1:** build + verify + commit **local**; the **owner** opens/merges PRs. Do **not** push, open a
+   PR, or merge without an explicit owner "go".
+4. **`git add` explicit paths** — the repo pre-tool hook blocks `git add -A` / `git add .`. Stage the exact
+   files.
+5. **Commit trailer:** **omit** the `Co-Authored-By: Claude` trailer — the CLA bot fails on it (project
+   convention; supersedes the older note in `MULTISESSION-PLAN-6.md`). One coherent layer per commit.
+6. **Auto-merge + CI gate:** branches off `0febba9` post-date the CI-gate roll-up, so no `git merge main`
+   catch-up is needed; still, rebase if `origin/main` advances before your PR merges.
+
+---
+
+## F. Build gotchas (checklist — apply per lane)
+
+1. **SPDX header** on every **new** `.py` (e.g. a new test module) — the header sweep only covered
+   pre-existing files. Editing an existing file needs none.
+2. **No new runtime deps expected** — all five are logic/validation changes. If a lane somehow needs one,
+   follow **DEP-1**: add to `pyproject.toml`, then re-lock from the **repo root** (`uv lock` / `uv export`),
+   never `uv export --directory`. Verify the package is real before adding (§7 of `CLAUDE.md`).
+3. **Crypto-inventory gate does NOT trip here:** L-B (`signature.py`/signxml) and L-C (SMART JWT signing)
+   touch **existing** modules already in `scripts/security/crypto_inventory_check.py`. The gate only fires on
+   a **new** `.py` importing `hashlib`/`hmac`/`secrets`/`ssl`/`cryptography`/`argon2` — none is introduced.
+4. **L-A is the default hot-path parser:** run the **full** suite and add a **pipeline-level** test that a
+   malformed-count message still records a disposition — the DELTA-02 fix must preserve **count-and-log** and
+   **at-least-once**, not just stop the crash.
+5. **PHI rule:** all fixtures are **synthetic** HL7/XML. Never real PHI; never customer host/IP/port/site
+   names in code, tests, or the CHANGELOG. L-D specifically asserts the *absence* of host/db-name — build its
+   fixtures with fake DSNs.
+6. **L-B behavior change** (`verify()` now raises without an anchor) — call it out in the PR and CHANGELOG as
+   an intentional secure-by-default break for the opt-in XML codec.
+
+---
+
+## G. Owner-gated / decision callouts
+
+- **Merge order & PRs (all lanes):** L1 autonomy — the owner opens and merges every PR. Recommended: merge
+  **L-A before the next release**; the rest can trail.
+- **L-B secure-by-default break:** owner sign-off that requiring an explicit anchor is acceptable (it is the
+  correct posture; the audit found no in-repo caller depending on the old default).
+- **L-D redactor unification:** owner call on whether L-D should **reuse** the engine redactor outright
+  (preferred) vs. only strengthen the bundle's local one — the former is cleaner but touches the shared
+  redaction seam.
+
+---
+
+## H. Definition of done (per lane)
+
+- The finding's fix is in place with a **regression test** that fails before / passes after.
+- Full quartet green on the lane's own `.venv`: `ruff format --check` · `ruff check` · `mypy` (strict) ·
+  `pytest` (offscreen, **full** suite).
+- One coherent local commit (no co-author trailer), explicit-path staged, ready for the owner to PR.
+- CHANGELOG line drafted; the review-doc status flip is left to the coordinator/owner (§D).
+
+**Aggregate done:** all five PRs merged; `docs/reviews/DELTA-REVIEW-2026-07-01.md` status column updated to
+*fixed (PR #…)* for DELTA-01 … DELTA-07 by the coordinator.

messagefoundry-0.2.14/docs/reviews/DELTA-REVIEW-2026-07-01.md

@@ -0,0 +1,262 @@
+# MessageFoundry — DELTA Security-Audit Report
+
+*Date: 2026-07-01*
+
+*Scope: the **delta** since the last full review (2026-06-10) — code ADDED or MODIFIED between roughly v0.2.0 and v0.2.13. Earlier code was already reviewed in [`docs/reviews/FULL-REVIEW-2026-06-10.md`](../reviews/FULL-REVIEW-2026-06-10.md) and is out of scope except where a pre-existing issue sits in a changed file and is materially exploitable. This is an authorized defensive audit: read-only, no runtime execution, synthetic data only, no customer-identifying data.*
+
+---
+
+## 1. Scope & Methodology
+
+This report covers only the code surface that changed in the review window. Delta scoping was established with `git log --since=2026-06-10` and `git show/diff` per file. The major feature landings audited (all in-window) are:
+
+- **Built-in tolerant HL7 parser** (ADR 0054, #655 / commit `2868571`) — now the **default** `Peek`/`Message` backend (`_backend.USE_BUILTIN=True`), running on the pre-ACK hot path.
+- **Inbound HTTP listener + custom RBAC + content search** (Plan-5 Wave 2, #624 / `de53154`).
+- **X12 strict (pyx12) + `[xml]` structured-codec layer** including XML-DSig (#619 / `417974e`).
+- **`fhir_lookup`, SMTP email, ops support-bundle / update-check** (Plan-5 Wave 1, #618 / `c729573`).
+
+**Methodology.** Nine parallel per-surface *finder* agents (HL7 core + binary carriage; structured-format codecs XML/X12/FHIR; egress/SSRF/outbound lookups; network listeners & transports; crypto/secrets/PHI redaction/de-identification; auth/RBAC/API; store/SQL; pipeline/config; supply-chain/infra) each enumerated candidate defects. Every candidate was then handed to an **independent adversarial verifier** operating default-to-refute: it re-traced reachability from attacker-influenceable input (inbound HL7/X12/DICOM/FHIR/XML/binary over MLLP/TCP/HTTP/DICOM listeners; file contents; connection config; outbound-lookup responses) to the sink, checked every intervening guard, and either CONFIRMED, marked PLAUSIBLE, or REFUTED with corrected severity. Only findings that survived verification appear below; notable refuted/deprioritized candidates are summarized in §5 for transparency. This synthesis merges duplicates and ranks by corrected severity then reachability.
+
+**Severity taxonomy** matches the house report: Critical / High / Medium / Low, assigned by realistic impact × reachability. Two of the seven findings carry a `PLAUSIBLE` verdict (real code defect, conditional reachability); the rest are `CONFIRMED`.
+
+---
+
+## 2. Executive Summary
+
+The delta introduces no new critical finding, no auth bypass, no SQL injection, and no remote-content RCE. The core ACK-after-commit and count-and-log invariants remain intact on the happy path. The **one materially serious new issue** is a resource-exhaustion DoS in the new default HL7 parser: because the built-in tolerant backend replicates python-hl7's unbounded repetition-escape expansion (`ch * count` with no cap) and is now invoked on the pre-ACK hot path via `summarize()`, a tiny attacker-controlled field value expands to multiple gigabytes synchronously on the asyncio event loop, freezing or OOM-killing the engine without authentication. A sibling malformed-count `ValueError` in the same branch is a lower-severity but real count-and-log break (a parseable message is dropped with no disposition).
+
+The remaining findings are on lower-reachability surfaces — an opt-in XML signature-verification footgun, a config-plane egress allowlist gap, an HTTP framing-ambiguity smuggling surface that requires a fronting proxy, and two operator-facing support-bundle disclosure/redaction gaps. None is reachable from raw inbound message data except the two HL7-core findings.
+
+### Severity counts
+
+| Severity | Count |
+|---|---|
+| Critical | 0 |
+| High | 2 |
+| Medium | 3 |
+| Low | 2 |
+| **Total** | **7** |
+
+### Health by surface (delta)
+
+| Surface | Health | Note |
+|---|---|---|
+| HL7 core parser + binary carriage | **needs attention** | New default built-in parser ports python-hl7's unbounded repetition expansion (DoS) and a malformed-count crash onto the pre-ACK hot path. |
+| Structured-format codecs (XML/X12/FHIR) | adequate | XML-DSig `verify()` is a secure-by-default footgun but opt-in; no wired sink. |
+| Egress / SSRF / outbound lookups | adequate | FhirLookup token-endpoint gate is fail-open on one arm; config-plane only. |
+| Network listeners & transports | adequate | New HTTP listener parser accepts ambiguous CL/TE framing; self-desync blocked by `Connection: close`. |
+| Crypto / secrets / PHI redaction | adequate | Support bundle leaks DB host/db-name and under-redacts free-text PHI vs. the engine redactor. |
+| Auth / RBAC / API | adequate | No new confirmed defect in-delta (see §5 refuted). |
+| Store / SQL | adequate | No new confirmed defect in-delta (see §5 refuted TOCTOU). |
+
+---
+
+## 3. Findings Summary Table
+
+| ID | Severity | Surface | Title | Location | Verdict |
+|---|---|---|---|---|---|
+| DELTA-01 | High | HL7 core | Unbounded HL7 escape-repetition expansion → pre-ACK memory-exhaustion DoS | `messagefoundry/parsing/_builtin_hl7.py:528` | CONFIRMED |
+| DELTA-02 | Medium | HL7 core | Malformed rich-text escape count raises uncaught `ValueError`, silently dropping a parseable message (count-and-log break) | `messagefoundry/parsing/_builtin_hl7.py:528` | CONFIRMED |
+| DELTA-03 | Medium | Structured codecs | XML-DSig `verify()` trusts any system-CA cert when no anchor is supplied | `messagefoundry/parsing/xml/signature.py:60` | PLAUSIBLE |
+| DELTA-04 | Medium | Egress/SSRF | FhirLookup SMART token endpoint bypasses `[egress].allowed_http` allowlist | `messagefoundry/pipeline/wiring_runner.py:2831` | CONFIRMED |
+| DELTA-05 | Low | Crypto/PHI | Support bundle `status.json` discloses SQL Server store host + database name | `messagefoundry/support/bundle.py:137` | CONFIRMED |
+| DELTA-06 | Low | Listeners | HTTP listener accepts ambiguous CL/TE framing (request-smuggling surface behind a proxy) | `messagefoundry/transports/http_listener.py:180` | PLAUSIBLE |
+| DELTA-07 | Low | Crypto/PHI | Support-bundle log redactor under-redacts vs. the engine redactor (fixed segment allowlist, no name/DOB heuristics) | `messagefoundry/support/redact.py:27` | PLAUSIBLE |
+
+*Note: DELTA-01 and DELTA-02 share the same file:line (`_builtin_hl7.py:528`, the repetition-escape branch) and root cause (the count/`int()` conversion). They are reported separately because they have distinct failure modes (memory-exhaustion DoS vs. uncaught-exception message loss) and severities, but both are fixed by the same one-block change; see the shared recommendation.*
+
+---
+
+## 4. Detailed Findings
+
+### DELTA-01 — Unbounded HL7 escape-repetition expansion in built-in unescape enables a pre-ACK memory-exhaustion DoS on the hot path
+
+- **Severity:** High (CONFIRMED, reachable from unauthenticated network input)
+- **CWE:** CWE-1284 / CWE-770 (improper validation of specified quantity / uncontrolled resource allocation)
+- **Location:** `messagefoundry/parsing/_builtin_hl7.py:528`
+
+**Description.** The new built-in HL7 unescape (ADR 0054, #655 — now the **default** tolerant backend, `_backend.USE_BUILTIN=True`) expands HL7 rich-text repetition escapes (`\.in<N>\`, `\.ti<N>\`, `\.sk<N>\`, `\.br<N>\`, …) with `default_map[value[:3]] * int(value[3:])` and applies **no cap** on the repetition count. A ~15-byte attacker-controlled field value such as `\.in2000000000\` allocates `'    ' * 2000000000` (~8 GB); a larger count pushes toward guaranteed OOM. This runs during a component/subcomponent leaf read (`extract_field` → `unescape`), which is **not** wrapped by the parse fallback guard (that guard wraps only `_builtin_hl7.parse` in `Peek.parse`). The engine's 16 MiB ingress size cap (`peek.enforce_size_limits`) measures the *raw* message length and cannot bound post-unescape expansion, so the tiny sequence sails through.
+
+**Attack scenario.** An attacker who can deliver an inbound HL7 message (MLLP/file/HTTP listener — partner-facing and unauthenticated) sends a well-formed message whose `PID-3.1` (or `PID-5.1` / `MSH-9.1`) contains `\.in2000000000\`. In `wiring_runner._handle_inbound`, after a successful `Peek.parse` and **before** the ACK, the ingress path evaluates `summary = summarize(peek)` (`summary.py:31/38/39` calls `peek.field("PID-3.1")` etc.), each a `comp=1` leaf read that invokes built-in `extract_field` → `unescape`. The multi-GB string is allocated synchronously on the event-loop thread, stalling every listener/worker/API call and driving the process toward OOM. Repeated messages amplify to a reliable engine-wide denial of service; a single large-count value can OOM-kill it outright.
+
+**Evidence.**
+```
+_builtin_hl7.py:527-528
+    elif value.startswith(".") and value[:3] in default_map:
+        out.append(default_map[value[:3]] * int(value[3:]))   # no upper bound on int(value[3:])
+```
+Reachable pre-ACK via `summary.py:31` `mrn = peek.field("PID-3.1")` and `wiring_runner.py:1729` `summary=summarize(peek)`. The fallback guard in `peek.py:141-151` wraps only `_builtin_hl7.parse`, not the field reads; `_resolve_builtin` (`peek.py:189-192`) catches only `IndexError`, so a resulting `MemoryError` propagates and crashes the task. The `summarize` call is a plain synchronous call (no `to_thread`/`run_in_executor`).
+
+**Verdict & confidence.** CONFIRMED; high confidence. The verifier independently traced the full path (unauthenticated listener → `_handle_inbound` on the event loop → default built-in backend → `enforce_size_limits` passes a ~15-byte input → pre-ACK `summarize` → leaf `unescape` → synchronous multi-GB allocation) and checked every guard. Impact is DoS only (no PHI disclosure/RCE), which is why this is high, not critical. Note the built-in faithfully replicates python-hl7's own unbounded `ch * count` (`hl7/util.py`), so the legacy fallback shares the flaw — but the delta made the built-in the default, always-on hot-path parser.
+
+**Recommendation.** Clamp the repetition count to a small sane maximum (e.g. reject/cap counts above a few hundred) **before** the `ch * count` multiplication, and/or bound total unescaped output length. The cap must live in built-in `unescape` itself (the upstream 16 MiB raw cap cannot mitigate a ~15-byte→gigabytes expansion). Treat an over-limit count as an unmappable sequence and drop it, matching the existing "log and discard" behavior for other unmappable escapes. This single fix also resolves DELTA-02.
+
+---
+
+### DELTA-02 — Malformed rich-text escape count raises an uncaught `ValueError` from built-in unescape, silently dropping a parseable message
+
+- **Severity:** Medium (CONFIRMED; corrected up from the finder's Low because it breaks the count-and-log invariant)
+- **CWE:** CWE-248 (uncaught exception) — with a downstream count-and-log invariant break
+- **Location:** `messagefoundry/parsing/_builtin_hl7.py:528`
+
+**Description.** In the same repetition-escape branch, `int(value[3:])` is unguarded. When `value[:3]` matches a valid 3-char rich-text prefix but the full value is not an exact key and the suffix is non-numeric — e.g. `\.inX\`, `\.in \`, `\.br9z\` — `int("X")` raises `ValueError`. Unlike the hex branch (`lines 534-539`, which wraps `int(...,16)` in `try/except ValueError: continue`), this `ValueError` is not caught inside `unescape`. It propagates out of `extract_field`; `Peek._resolve_builtin` (`peek.py:189-192`) catches only `IndexError`, so the `ValueError` escapes `Peek.field`. On the inbound path it fires inside `summarize(peek)` at `wiring_runner.py:1729`, reached **after** the `HL7PeekError`/`UnicodeDecodeError` guards and **before** `enqueue_ingress`, and is not wrapped by the parser fallback guard.
+
+**Attack scenario.** An attacker sends structurally valid inbound HL7 over MLLP with `PID-3.1` (or `PID-5.x`/`MSH-9`) = `\.inX\`. `Peek.parse` succeeds; `summarize`'s `PID-3.1` read raises `ValueError` before the message is persisted. The exception is caught only by the MLLP per-connection last-resort handler (`mllp.py:676-687`), which logs redacted and drops the TCP connection. Because the raise happens **before** `enqueue_ingress`, the message is neither persisted (no `RECEIVED`/`ERROR` row) nor ACK'd/NAK'd — the connection is simply severed and a parseable healthcare message is lost with no disposition, directly violating the project's count-and-log invariant ("every received message is persisted before the ACK; nothing is accepted-and-dropped").
+
+**Evidence.**
+```
+_builtin_hl7.py:528   ... * int(value[3:])         # no try/except (contrast hex branch 534-539)
+peek.py:191           except IndexError:            # ValueError not mapped to None
+summary.py:31         mrn = peek.field("PID-3.1")   # unconditional pre-ACK read
+wiring_runner.py:1729 summary=summarize(peek)       # evaluated before enqueue_ingress
+```
+
+**Verdict & confidence.** CONFIRMED; high confidence. Correction to the finding: the finder's `\.in\` (empty-count) example does **not** trigger the bug — `value=".in"` is caught by the earlier exact-key match. Real triggers are a valid 3-char prefix followed by a non-numeric/space suffix (`\.inX\`, `\.in \`, `\.br9z\`). Severity raised from Low to Medium because the failure is not a benign crash: it drops the connection **and** loses the message with no disposition (a "do-not-break" invariant), driven by trivially attacker-controlled inbound HL7 on the default parser. Not higher because engine/listener/other-connection stability is unaffected and the sender can reconnect.
+
+**Recommendation.** Wrap the `int(value[3:])` conversion and the subsequent multiplication in `try/except ValueError`, dropping the sequence on failure (matching python-hl7's log-and-discard intent and the built-in's own hex-branch handling). Additionally broaden `peek._resolve_builtin` to map `ValueError` to `None` like `IndexError`. The DELTA-01 count-clamp fix should be applied in the same block.
+
+---
+
+### DELTA-03 — XML-DSig `verify()` trusts any system-CA cert when no anchor is supplied (signxml default-trust)
+
+- **Severity:** Medium (PLAUSIBLE; corrected down from High — opt-in codec, not a wired sink)
+- **CWE:** CWE-347 (improper verification of cryptographic signature)
+- **Location:** `messagefoundry/parsing/xml/signature.py:60`
+
+**Description.** `verify()` forwards `x509_cert` and `ca_pem_file` straight to signxml's `XMLVerifier.verify()`, and both parameters default to `None` (`lines 47-48`). When a caller invokes `verify(document)` with neither anchor, signxml applies its documented default: it trusts **any** valid XML-DSig signature whose embedded `X509Certificate` chains to the host's system CA trust store. signxml's own docs warn: "the default behavior is to trust any valid XML signature generated using a valid X.509 certificate trusted by your system's CA store. This means anyone can get an SSL certificate and generate a signature that you will trust." The docstring frames the anchors as optional ("Pass `x509_cert` … or `ca_pem_file`"), and there is no guard rejecting the both-`None` case, so a Handler author following the API silently gets origin-blind verification returning `verified=True` for an attacker-forged signature.
+
+**Attack scenario.** An attacker forges a signed inbound XML/SOAP clinical message: they tamper with the body (alter a patient identifier or order), strip the legitimate enveloped signature, obtain any free domain-validated certificate for a domain they control, re-sign the modified document, and embed the cert in `ds:KeyInfo/X509Certificate`. A Handler that calls `verify(document)` without pinning `x509_cert` or a partner CA receives `XmlSignatureResult(verified=True)`, so the engine treats the forged message as authentic and routes/transforms it.
+
+**Evidence.**
+```
+signature.py:44-48  def verify(document, *, x509_cert=None, ca_pem_file=None)
+signature.py:60     verifier.verify(root, x509_cert=x509_cert, ca_pem_file=ca_pem_file)
+```
+No guard rejects the both-`None` call; signxml (pinned 5.0.1) then falls back to trusting any system-CA-trusted embedded cert.
+
+**Verdict & confidence.** PLAUSIBLE; high confidence in the defect, low in active reachability. The code defect and signxml behavior are real and accurately described — a genuine secure-by-default failure, invited by the docstring. However, an exhaustive caller grep shows the only importers of `parsing.xml.verify` are package `__init__` re-exports; nothing in `pipeline/`, `transports/`, or any automatic message path invokes it. Per ADR 0004 the XML codec is payload-agnostic and called on demand by a code-first Handler, never pushed through the pipeline. So attacker-influenceable input reaches this sink only if an adopter writes a custom Handler that calls `verify(document)` without pinning an anchor **and** treats `verified=True` as an authenticity gate. That misuse is plausible (and invited) but is not present in-repo and not automatically reachable — hence PLAUSIBLE and a downgrade from High to Medium.
+
+**Recommendation.** Require an explicit trust anchor: raise (`XmlError`/`ValueError`) when both `x509_cert` and `ca_pem_file` are `None`, so a caller must pin the expected signer or a partner CA. Do not rely on signxml's implicit "trust anything the OS trusts" default. Update the docstring to state an anchor is mandatory, and add a test asserting a document signed by an arbitrary system-trusted cert does **not** verify without an explicit anchor. This mirrors the explicit-key enforcement already present in `transports/signing.py`.
+
+---
+
+### DELTA-04 — FhirLookup SMART token endpoint bypasses the `[egress].allowed_http` allowlist (client_assertion exfil / SSRF)
+
+- **Severity:** Medium (CONFIRMED; config-plane reachability, not network input)
+- **CWE:** CWE-918 (server-side request forgery) / egress-control fail-open
+- **Location:** `messagefoundry/pipeline/wiring_runner.py:2831`
+
+**Description.** `check_fhir_lookup_allowed()` gates only `settings['url']` (the FHIR base host) against `[egress].allowed_http`. A FhirLookup spec can compose `with_smart_backend()` (`transports/smart.py:262-263,304`, which explicitly accepts a `FhirLookupSpec`), which sets `smart_token_url`. `FhirLookupExecutor.__init__` (`transports/fhir.py:561`) then builds a `SmartBackendTokenProvider` from that `smart_token_url` and POSTs a signed `client_assertion` JWT (a credential-minting request) to it at read time. Unlike the outbound egress path, which explicitly gates `smart_token_url` (`wiring_runner.py:3086-3097`, with the comment: "Left ungated, a crafted smart_token_url would exfiltrate the assertion to an unlisted host (a fail-open hole)"), the FhirLookup path never checks the token endpoint host. The exact fail-open the outbound arm closes is left open on the read-side lookup arm. ADR 0043 §D3 explicitly states the FhirLookup's `smart_token_url` "must be checked against `[egress].allowed_http`" — so this is a documented, intended control the implementation fails to apply.
+
+**Attack scenario.** An operator (or a config/GUI-edit path, or a compromised `env()` value) declares a FhirLookup whose FHIR base `url` is allow-listed but whose `smart_token_url` points at an attacker/unlisted host. `deny_by_default` + `allowed_http` provides no protection: the executor mints and POSTs the signed `client_assertion` to the un-allowlisted token endpoint, exfiltrating the assertion and defeating the egress control the outbound path enforces. The connection loads without error because only the FHIR base host is validated.
+
+**Evidence.**
+```
+wiring_runner.py:2831-2842  check_fhir_lookup_allowed validates only url = str(settings.get("url","")); never reads smart_token_url
+wiring_runner.py:3086-3097  outbound branch: token_url = dest.settings.get("smart_token_url"); if token_url and not _http_egress_allowed(...): raise WiringError(...)
+transports/fhir.py:561      FhirLookupExecutor consumes smart_token_url via token_provider_from_settings(s)
+transports/smart.py:181-191 SmartBackendTokenProvider._fetch_token POSTs the client_assertion to self.token_url
+```
+
+**Verdict & confidence.** CONFIRMED; high confidence. The sole egress gate for FhirLookups omits the token-endpoint check that the sibling outbound arm enforces against exactly this threat, and `SmartBackendTokenProvider` performs no allowlisting of its own — so the only place the check could live is `check_fhir_lookup_allowed`, which omits it. Reachability is config-plane (a FhirLookup spec / `connections.toml` / poisoned `env()`), not raw network input — so not High. But containing misconfigured/compromised egress destinations is the entire purpose of the `deny_by_default` allowlist, and the gap lets a signed `client_assertion` credential be POSTed to an un-allowlisted host (credential exfil + SSRF POST primitive). Replay value of the leaked assertion is limited because `aud` defaults to the (attacker) token URL, but the control bypass and exfil are real — Medium is correct.
+
+**Recommendation.** In `check_fhir_lookup_allowed()`, after validating the FHIR base `url`, apply the same `smart_token_url` host check the outbound branch uses (read `settings.get("smart_token_url")`; if set, require `_http_egress_allowed(token_url, egress.allowed_http)`) and honor `deny_by_default`. Factor the outbound token-endpoint gate into a shared helper so read-side and write-side stay in lockstep. Add a test asserting an un-allowlisted `smart_token_url` on a FhirLookup is rejected (mirroring the outbound test).
+
+---
+
+### DELTA-05 — Support bundle `status.json` discloses the SQL Server store host and database name
+
+- **Severity:** Low (CONFIRMED; corrected down from Medium — operator-shared vector, no secrets/PHI)
+- **CWE:** CWE-200 (exposure of sensitive information)
+- **Location:** `messagefoundry/support/bundle.py:137`
+
+**Description.** `build_bundle()` writes `status.json` straight from `SystemStatus.model_dump()` with no redaction (`bundle.py:202-203`). `status_snapshot` → `_db_info` populates `DbInfo.path` from `store.db_status().path` (`bundle.py:137-146`). For the SQL Server backend, `MsSqlStore.path` is `f"{settings.server}/{settings.database}"` (`sqlserver.py:392`) — the raw ODBC server host (`hostname\instance` or IP) and database name. So the operator-emailed support zip carries the customer's DB server host and database name. This directly contradicts the module's own PHI contract, which promises the bundle carries "never a settings value, host, path" (`bundle.py:11-12`) and "no secrets" (`bundle.py:19`) — enforced for `config_summary` (which deliberately omits hosts) but not for `status_snapshot`. It is also contrary to the project rule that customer-identifying host/IP data must not leave the box. (For the SQLite backend the same field carries the local DB file path, which can embed an org/site name.)
+
+**Attack scenario.** An operator runs `messagefoundry support-bundle` against a SQL Server deployment and emails/uploads the zip to third-party support or attaches it to a ticket, relying on the bundle's explicit "no host/path" promise. `status.json` exposes the internal DB server hostname/instance (or IP) and database name — customer-identifying infrastructure detail the bundle claims it never includes — to anyone who receives the bundle.
+
+**Evidence.**
+```
+bundle.py:137-146   return DbInfo(path=db.path, ...)
+sqlserver.py:392    self.path = f"{settings.server}/{settings.database}"
+bundle.py:202-203   members["status.json"] = json.dumps(status, ...)   # no redaction pass
+bundle.py:11-12     contract: bundle omits "never a settings value, host, path"
+```
+
+**Verdict & confidence.** CONFIRMED; high confidence. The self-contradicting-contract leak is fully traced and real. The disclosed value is operator configuration (not attacker-supplied message input), so it is not reachable from untrusted message data; the vector is a trusted operator voluntarily sharing the zip. No secrets, credentials, or PHI are leaked — the connection-string password is not part of `settings.server`/`settings.database`; only reconnaissance-value host/instance/IP + DB name. This clears "info" (it leaks the customer-identifying host class the project forbids leaving the box) but is Low, not Medium, given no secrets/PHI and the voluntary-sharing dependency.
+
+**Recommendation.** Before serializing status into the bundle, drop or redact `DbInfo.path` (replace with the backend type only, or a coarse `<redacted>` descriptor). Alternatively have `db_status()` expose a backend label for bundle use. Add a regression test asserting `status.json` contains no host/path token.
+
+---
+
+### DELTA-06 — HTTP listener accepts ambiguous framing headers (duplicate Content-Length, CL + obfuscated Transfer-Encoding) — request-smuggling surface behind a fronting proxy
+
+- **Severity:** Low (PLAUSIBLE; conditional on a fronting proxy, this server cannot self-desync)
+- **CWE:** CWE-444 (inconsistent interpretation of HTTP requests / request smuggling)
+- **Location:** `messagefoundry/transports/http_listener.py:180`
+
+**Description.** The hand-rolled header parser in `_read_request()` stores headers last-wins (`headers[name.strip().lower()] = value.strip()`, `line 183`) and never rejects duplicate `Content-Length` headers nor the simultaneous presence of `Content-Length` and `Transfer-Encoding`. It refuses `Transfer-Encoding` only when the (last-wins, lowercased) value equals exactly `"chunked"` (`line 192`); an obfuscated TE value (e.g. `Transfer-Encoding: chunked, identity`, `Transfer-Encoding:\tchunked`, or a duplicated TE header whose last value is not exactly `"chunked"`) is silently ignored and the request is framed by `Content-Length` (`lines 197-207`). RFC 7230 §3.3.3 requires rejecting a message with both CL and TE and rejecting/ignoring conflicting/duplicate `Content-Length`.
+
+**Attack scenario.** An operator fronts partner traffic with a reverse proxy (TLS termination / load balancing) — a topology ADR 0023 §3 and ADR 0002 (WP-15) explicitly support. An attacker crafts a request with two `Content-Length` headers, or a `Content-Length` plus an obfuscated `Transfer-Encoding` the proxy honors as chunked but this backend ignores. The proxy and backend disagree on message boundaries, enabling classic HTTP request smuggling / queue poisoning against the pipeline in the fronted deployment.
+
+**Evidence.**
+```
+http_listener.py:183  headers[name.strip().lower()] = value.strip()          # last-wins, no dup detection
+http_listener.py:192  if headers.get("transfer-encoding","").lower() == "chunked":   # only exact-match rejected
+http_listener.py:197  if cl_raw is not None: ...                              # CL used even if a TE header is also present
+```
+
+**Verdict & confidence.** PLAUSIBLE; medium confidence. All four technical claims verified against the new code (`de53154`). The attacker-influenceable raw HTTP request reaches this parser directly. Crucially, this server **cannot desync itself**: `_serve_one` reads exactly one request per socket, responds `Connection: close` (`build_response`), and closes — there is no keep-alive/pipelining, so any leftover smuggled bytes are discarded on close, and the most damaging queue-poisoning variant is blunted. The residual risk is a proxy↔backend framing disagreement in the supported fronted topology, whose impact depends on specific upstream proxy behavior. Real spec-compliance defect, deployment-conditional impact, no direct self-exploitation — Low.
+
+**Recommendation.** Reject any request carrying both `Content-Length` and `Transfer-Encoding` (400); detect and reject a duplicate `Content-Length` (track seen names in the parse loop rather than overwriting at line 183); and reject any `Transfer-Encoding` whose token list contains `chunked` in **any** position (not only exact-string match at line 192). Low-cost hardening even though this server cannot self-desync, because the fronting-proxy topology is explicitly blessed.
+
+---
+
+### DELTA-07 — Support-bundle log redactor under-redacts vs. the engine's own redactor (fixed segment allowlist, no name/DOB heuristics)
+
+- **Severity:** Low (PLAUSIBLE; primary redaction happens upstream, residual is a narrow non-logging-stdout edge)
+- **CWE:** CWE-359 (exposure of private personal information)
+- **Location:** `messagefoundry/support/redact.py:27`
+
+**Description.** `support/redact.py` is the redactor applied to the app-log tail carried in the support bundle (`bundle.py:171`). Its HL7 catch (`_HL7_SEGMENT`, `lines 27-29`) matches only a hard-coded enumeration of segment ids (`MSH|PID|PV1|OBX|OBR|EVN|NK1|ORC|IN1|AL1|DG1|GT1|SPM|MSA|ERR|ED`). It omits free-text-bearing segments such as `NTE`, `TXA`, `RXA`/`RXR`, `PR1`, `IN2`, and any custom Z-segment, and it has no free-text name/DOB heuristic. By contrast the engine's exception-path redactor (`redaction.py:35`) matches **any** segment id via `[A-Z][A-Z0-9]{2}` and additionally scrubs delimiter-free date runs and multi-token name runs (`redaction.py:47-58`). A log line carrying e.g. `NTE|1||patient JANE DOE dob 1980-05-05` is fully redacted by `redaction.py` but passes through `support/redact.py` untouched.
+
+**Attack scenario.** A dependency or a non-`safe_exc` log site emits content to stdout/stderr **outside** the logging framework (direct `print`, an interpreter traceback on a hard crash, subprocess stderr) that echoes an HL7 `NTE`/Z-segment or a free-text `LAST FIRST dob YYYY-MM-DD` fragment. NSSM captures that un-redacted line into the file the bundle reads. An operator generates a support bundle; `support/redact.py` does not match that segment/pattern, so the PHI fragment ships in `app-log.txt` inside the off-box zip.
+
+**Evidence.**
+```
+support/redact.py:27-29   fixed list (MSH|PID|PV1|OBX|OBR|EVN|NK1|ORC|IN1|AL1|DG1|GT1|SPM|MSA|ERR|ED); no _NAME_RUN/_DATE_RUN
+redaction.py:35           _HL7_SEGMENT = re.compile(r"\b([A-Z][A-Z0-9]{2})\|[^\r\n]*")
+redaction.py:47-58        date/name heuristics
+bundle.py:171             return redact_log_text(...)
+```
+
+**Verdict & confidence.** PLAUSIBLE; medium confidence. The code gap and regex behavior were reproduced (NTE/Z-segment/name/DOB runs redacted by `redaction.py`, untouched by `support/redact.py`). But the finder's headline WARNING-echo scenario is already mitigated: the engine adds no file handlers (`logging_setup.py:8`); NSSM captures the already-redacted stdout stream (strong `RedactionFilter` on the root handler, `logging_setup.py:213/271-276`), and child/third-party loggers propagate to root — so anything emitted via the logging framework is scrubbed by the strong redactor **before** reaching the file, and `support/redact.py` merely re-processes already-clean text. The only genuine bypass is content written to stdout/stderr outside the logging framework, and no engine path was found emitting message content that way. A real defense-in-depth reduction over a narrow residual, not a traced attacker→unredacted-sink path — Low.
+
+**Recommendation.** Reuse `messagefoundry.redaction.redact` (or broaden `_HL7_SEGMENT` to `[A-Z][A-Z0-9]{2}` and add the `_DATE_RUN`/`_NAME_RUN` passes) so the bundle's log redactor is at least as strong as the engine's exception-path redactor — the off-box bundle is the higher-consequence surface.
+
+---
+
+## 5. Refuted / Deprioritized Candidates
+
+These candidates were investigated and did **not** survive adversarial verification, or were real code observations without a materially exploitable security consequence in the delta. Summarized for transparency; they are not open findings.
+
+- **FHIR JSON parse leaks uncaught `RecursionError` on deeply nested payloads** (structured-codecs). Technically real: `json.loads` on ~50k+ nested arrays raises `RecursionError`, which is neither `ValueError` nor `JSONDecodeError`, so it escapes the codec's typed `except` (`peek.py:69`, `resource.py:78`). **Refuted as security:** `FhirPeek.parse` is not on the automatic ingress hot path (only HL7 `Peek.parse` is), and every reachable caller sits inside a worker with a broad `except Exception` that dead-letters — and `RecursionError` **is** an `Exception`, so it is caught and cleanly dead-lettered. No crash, no DoS, no info leak. Remaining defect is a contract/robustness issue (typed error promised, untyped leaked), not a vulnerability.
+
+- **Inbound HTTP listener success/health responses drain unbounded — slow-read DoS** (listeners). Code observation correct: `_respond()` does a bare `await writer.drain()` with no timeout, unlike `_write_safely()`. **Refuted:** every response through `_respond()` is a few hundred bytes at most (`{"status":"ok"}`, a short 202 receipt), far below the 64 KiB high-water mark, so `drain()` returns immediately regardless of the peer's read behavior; `Connection: close` + one-request-per-socket prevents buffer growth; `message_id` is an internal id, not attacker-inflatable. The request-side slow-read is already bounded by `receive_timeout`. Missing write timeout is a robustness parity nit, not a demonstrable DoS.
+
+- **Retention document-strip TOCTOU on the in-flight guard** (store/SQL). Real structural TOCTOU: the in-flight guard is applied at candidate `SELECT` time but not re-checked before the write-back `UPDATE`. **Refuted:** the premise that stripping `messages.raw` can corrupt an in-flight replay is false — the staged pipeline re-derives from each queue row's **own** encrypted payload (`queue.payload`, per-handler `raw_payload`), never from `messages.raw`; `replay()` re-queues existing rows and never reads `messages.raw`. The strip mutates only the canonical display/audit copy. No delivery-integrity or security consequence. (The code even documents this invariant at `store.py:5125-5127`.)
+
+- **Directory-disabled AD account keeps live engine sessions until timeout** (auth/RBAC). Real CWE-613 condition in the abstract. **Deprioritized/out-of-delta:** the exact sink lines (`service.py:691-694`) were introduced 2026-06-07, **before** the review window, and the in-window commits touching `service.py` did not modify the AD liveness/disabled-resync logic. Not reachable from message input (session-lifecycle policy gap). Already documented, accepted, and compensated: `SECURITY.md` residual (2) and `CISO-REVIEW.md #9`, with an existing admin bulk session-revoke. Duplicate of a known-accepted residual; window capped by idle/absolute timeouts.
+
+- **`ai:assist` authorization is advisory only (client-side enforcement)** (auth/RBAC). `GET /ai/policy` is intentionally not behind `require()` and returns an advisory bit. **Refuted:** there is no server-side AI *action* endpoint to fail open against — the MVP IDE assistant talks to an external LLM directly, the engine is clamped to `code_only` and never in the AI data path. Intentional, documented design (docstring + CISO register), and the `/ai/policy` logic predates the review window. Architectural observation, at most info.
+
+- **Custom roles may grant `CONFIG_DEPLOY`, not in the escalation-forbidden set** (auth/RBAC). Facts accurate (`CUSTOM_ROLE_FORBIDDEN_PERMISSIONS` omits `CONFIG_DEPLOY`), delta code. **Refuted:** ADR 0045 explicitly resolved this — `CONFIG_DEPLOY`/`SERVICE_CONFIGURE` are classified "privileged-but-not-escalating" and deliberately "stay assignable." The forbidden set is escalation primitives only; `CONFIG_DEPLOY` cannot grant more privilege than held (config reload does not touch the roles table). No new capability (an admin can already assign the built-in `DEPLOYMENT` role), and `/config/reload` is step-up-gated, path-confined, optionally dual-control, and audited. A design-intent disagreement, not a reachable vulnerability.
+
+---
+
+## 6. Coverage & Limitations
+
+**Surfaces covered (delta since 2026-06-10).** Nine parallel finder passes covered: HL7 core parser + binary carriage; structured-format codecs (XML / X12 / FHIR); egress / SSRF / outbound lookups (`db_lookup`, `fhir_lookup`, SMART token provider); network listeners & transports (new HTTP listener, MLLP, file); crypto / secrets / PHI redaction / de-identification (support bundle, redactors); auth / RBAC / API (custom RBAC, `ai:assist`, AD sessions); store / SQL (retention strip, SQL Server); pipeline / config; and supply-chain / infra. Reachability was traced from attacker-influenceable inputs — inbound HL7/X12/DICOM/FHIR/XML/binary over MLLP/TCP/HTTP/DICOM listeners, file contents, connection config (`connections.toml` / `env()`), and outbound-lookup responses — to each candidate sink, reading callers and callees.
+
+**Out of scope.** Code unchanged since 2026-06-10 (already covered by the prior full review) was not re-audited except where a pre-existing issue sits in a changed file and is materially exploitable. Pre-existing issues confirmed to predate the window (e.g. the AD-session liveness gap in §5) were deprioritized as out-of-delta. No re-litigation of the prior report's 78 findings.
+
+**Read-only / no-runtime caveat.** This audit was strictly read-only: no repo files were edited, the engine was never run, and no exploit was executed against any live system. Proof-of-concept payloads (e.g. `\.in2000000000\`) are inert text in the findings. No real PHI, credentials, or key/secret files were read; no customer-identifying data (real IPs, ports, partner/hospital names, site codes) appears anywhere in this report. Findings are grounded in concrete `file:line` evidence; DoS/expansion magnitudes were reasoned from the code and interpreter behavior, not measured against a running instance. `PLAUSIBLE` verdicts denote a verified code defect whose exploitability is conditional (opt-in Handler use for DELTA-03; a fronting proxy with divergent framing for DELTA-06); they warrant fixing but were not demonstrated end-to-end in a live deployment.