@blamejs/blamejs-shop 0.5.5 → 0.5.6

package/lib/vendor/blamejs/CHANGELOG.md

@@ -6,8 +6,76 @@ Pre-1.0 the surface is intentionally evolving — every release may
 change something operators depend on. Read each entry before
 upgrading across more than a few patches at a time.
 
+## v0.16.x
+
+- v0.16.2 (2026-07-03) — **Security hardening across the mail, OAuth/SAML, ACME, keychain and router primitives — six fail-open / injection / bypass fixes and seven correctness fixes — alongside a large expansion of the automated test suite.** This patch closes a batch of security and correctness defects surfaced while substantially expanding the test suite across the framework's mail-authentication, federated-identity, ACME, keychain, backup, CLI and router primitives. The security fixes: SPF evaluation no longer throws (and thus can no longer be laundered into a temperror that a permissive inbound policy accepts) on a malformed `ip4:` CIDR mask; the Authentication-Results builder now refuses CR/LF/NUL in the `version` field, closing the last header-injection gap left by the earlier mail-header sweep; `res.redirect` now rejects a horizontal TAB (which user agents strip before URL parsing, turning `/\t/evil.example` into a protocol-relative redirect to an attacker origin); the OAuth refresh-token one-time-use replay gate now treats any truthy `seen()` result as seen (a Redis `1` / SQL `COUNT` no longer slips a stolen refresh token past a `=== true` compare) — with the same normalization applied to its sibling replay checks; SAML Single-Logout over HTTP-POST/SOAP now fails closed (throws) when a verification key is supplied without its algorithm, matching the redirect binding instead of silently skipping signature verification; and the OAuth authorization-URL / PAR builders now refuse operator `extraParams` that collide with framework-managed parameters (`redirect_uri`, `state`, `code_challenge`, …). The correctness fixes: concurrent keychain file-store writes are serialized under the existing file lock (no more lost bindings); TLS-RPT submission reads the real `statusCode` (successful reports are no longer misreported as failures); ACME account key-rollover stops double-encoding its inner JWS payload (rollover was always rejected by the CA); the response-schema validator now also validates JSON bodies sent via `res.end`; keychain `remove` validates a relative fallback path like `store`/`retrieve`; `bundleAdapterStorage` honors the ambient compliance posture like `create`; and a refused `dev --ignore` pattern now returns exit code 2 instead of rejecting the CLI promise. **Fixed:** *Concurrent keychain file-store writes no longer drop bindings* — `store` and the file-remove path performed an unlocked read-modify-write of the fallback file, so two concurrent stores could each read the pre-update document and the later write would clobber the earlier binding. Both read-modify-write sequences are now serialized under the file's existing lock. · *TLS-RPT submission reads the response `statusCode`* — `tlsRpt.submit` read `status` from the HTTP client response, but the client resolves `statusCode`, so a successful (2xx) report POST was reported as `{ ok: false, error: 'HTTP undefined' }`. It now reads `statusCode`, so delivered reports are distinguished from rejected ones. · *ACME account key-rollover no longer double-encodes its inner JWS payload* — `accountKeyRollover` passed an already-stringified payload to a signer that stringifies internally, so the inner keyChange JWS payload encoded a JSON string instead of the JSON object and every rollover was rejected by the CA (RFC 8555 §7.3.5). The payload is now passed once. · *Response-schema validator also validates `res.end` JSON bodies* — The response validator wrapped only `res.json`, so a handler shipping an invalid body via `res.end(JSON.stringify(...))` escaped validation despite the documented contract. JSON-shaped `res.end` bodies are now validated on the same path. · *keychain `remove` validates a relative fallback path like `store`/`retrieve`* — `remove` checked file existence before validating the fallback path, so a relative path silently no-op'd instead of throwing the config error that `store`/`retrieve` raise. It now validates first, consistent with the other file-fallback paths. · *`bundleAdapterStorage` honors the ambient compliance posture* — `bundleAdapterStorage` only refused an unencrypted strategy when an explicit posture was passed, unlike `create`, which reads the ambient `b.compliance` posture and refuses `encrypt:false` under HIPAA. `bundleAdapterStorage` now falls back to the ambient posture, closing the asymmetry. · *`dev --ignore` pattern refusal returns exit code 2* — A `dev --ignore` pattern that exceeded the length cap or was refused by the regex guard threw out of the CLI promise instead of writing to stderr and returning exit code 2 like every other CLI validation failure. It now returns the standard non-zero exit. **Security:** *SPF `ip4:` with a malformed CIDR mask fails closed instead of throwing (fail-open)* — `_ipv4InCidr` lacked the finite-mask guard its IPv6 sibling has, so an `ip4:` mechanism with a non-numeric prefix (e.g. `ip4:192.0.2.0/`) reached `BigInt(32 - NaN)` and threw an uncaught `RangeError` out of `b.mail.spf.verify` / `b.mail.inbound.verify`. Upstream mail handling catches that throw as a temperror, and an inbound policy configured to accept on temperror would then admit a sender that should have been evaluated. SPF now returns a `permerror` result for a malformed mask, honoring the primitive's documented never-throw-on-message-content contract. · *Authentication-Results builder refuses CR/LF/NUL in the `version` field (header injection)* — `b.mail.authResults.emit` validated the `authserv-id` against control characters but not the operator-supplied `version`, which is interpolated onto the `Authentication-Results:` header line — the last field left unguarded by the earlier mail-header CRLF sweep. A `version` containing CRLF could smuggle an arbitrary header. It is now refused with a typed error, like every other field on that line. · *`res.redirect` rejects horizontal TAB (open-redirect / same-origin bypass)* — The redirect target's control-character guard rejected CR/LF/NUL but not TAB (0x09). Node permits a TAB in a header value, but the WHATWG URL parser strips ASCII TAB/LF/CR from a URL before resolving it, so a `Location: /\t/evil.example` collapses to the protocol-relative `//evil.example` and navigates to the attacker origin — bypassing the same-origin/allowlist heuristic. TAB is now rejected alongside CR/LF/NUL. · *OAuth refresh-token replay gate treats any truthy `seen()` result as seen (fail-open)* — The legacy `seen(refreshToken)` replay gate compared the callback's return with `=== true`, but the documented contract is that it returns a truthy value when the token was presented before. A store returning a truthy non-`true` value — a Redis `EXISTS`/`SISMEMBER` `1`, a SQL `COUNT` — slipped a replayed (stolen) refresh token past the one-time-use gate. Any truthy result now counts as seen; the same normalization was applied to the sibling replay checks in the module. · *SAML Single-Logout over HTTP-POST/SOAP fails closed on a key without its algorithm* — The POST and SOAP SLO parsers gated signature verification with an OR condition and the verify helper early-returned when the algorithm was absent, so supplying a verification key without `idpVerifyAlg` silently accepted a forged, unsigned LogoutRequest — while the HTTP-Redirect binding failed closed. All four SLO parse paths now route through one config check that throws when a key is supplied without its algorithm. · *OAuth authorization-URL / PAR builders refuse `extraParams` that collide with managed parameters* — `authorizationUrl` and `pushAuthorizationRequest` merged operator `extraParams` with `URLSearchParams.set`, which replaces — so an `extraParams` entry for `redirect_uri`, `state`, or `code_challenge` overwrote the framework-generated value while the call still returned the framework's `state`/PKCE verifier, diverging the returned session seed from the emitted URL. Reserved parameter keys in `extraParams` are now refused with a typed error at both builders.
+
+- v0.16.1 (2026-07-03) — **Every source file now carries an SPDX license + copyright header; the wiki example emits its full HSTS when it runs behind a TLS-terminating reverse proxy; and a good-first-issue on-ramp lands for new contributors.** This patch stamps a per-file `SPDX-License-Identifier: Apache-2.0` and a copyright line onto every first-party source file, so the license of any single file is unambiguous when it is read, audited, or vendored in isolation. The project stays Apache-2.0 — this is a clarity change, not a license change, and vendored third-party files under lib/vendor/ keep their own upstream headers. The wiki example now passes its trusted-proxy CIDRs to the securityHeaders middleware: a deployment behind a TLS-terminating reverse proxy (Caddy or nginx) that forwards `X-Forwarded-Proto: https` now emits the framework's strong HSTS (two-year max-age, includeSubDomains, preload) instead of suppressing it on the plain-HTTP hop from the proxy — the wiki e2e asserts both the proxied-https and the direct-http cases. CONTRIBUTING gains a good-first-issue on-ramp so new contributors have a clear, small first step. **Added:** *Per-file SPDX license and copyright headers* — Every first-party source file now begins with `// SPDX-License-Identifier: Apache-2.0` and a copyright line, so the license and holder of any individual file are explicit when it is read or extracted on its own. No license change — the project remains Apache-2.0. Vendored files under `lib/vendor/` are untouched and retain their upstream license headers. **Changed:** *Good-first-issue on-ramp for new contributors* — CONTRIBUTING now points new contributors at issues labelled `good first issue` — small, self-contained tasks (a doc or wiki-example fix, a test for an uncovered branch) that are the easiest first step into the codebase. **Security:** *Wiki example emits its full HSTS behind a TLS-terminating reverse proxy* — The wiki example app now hands its trusted-proxy CIDRs to `securityHeaders`, so behind Caddy or nginx forwarding `X-Forwarded-Proto: https` it emits `Strict-Transport-Security: max-age=63072000; includeSubDomains; preload` rather than dropping HSTS on the internal HTTP hop from the proxy. Operators modelling their own app on the example inherit the fix by declaring their proxy CIDRs via `WIKI_ADMIN_TRUSTED_PROXIES` (the production compose already defaults to the private ranges). The framework's `securityHeaders` primitive is unchanged; this closes a wiring gap in the example.
+
+- v0.16.0 (2026-07-03) — **Raises the minimum Node.js engine to 24.18.0; the status-list verifier now binds the token type against a typ-confusion replay; and CI supply-chain pinning is consolidated behind committed dev/example lockfiles, `npm ci`, and a single aggregating pin tool that closes the OpenSSF Scorecard pinned-dependency gaps.** This minor raises the supported Node.js floor from 24.16.0 to 24.18.0 — operators must run Node 24.18.0 or newer (24.17.0 was a security release; 24.18.0 bundles SQLite 3.53.1 and a backup-path fix, and guarantees the native OpenSSL 3.5 SLH-DSA surface). b.auth.statusList.fromJwt now enforces RFC 8725 §3.11 by binding the JWS header typ to the "statuslist+jwt" that toJwt stamps, so a token minted for another purpose can't be replayed as a status list. The build's supply-chain pinning is reworked so OpenSSF Scorecard sees pinned installs everywhere it can: the dev-tool, example, and fuzz manifests now ship committed lockfiles and CI installs them with `npm ci` (Scorecard keys pinning on the `ci` verb, not on an `@version` specifier), the vendored fuzz toolchain and the oss-fuzz base image are pinned, and a new scripts/pin-all.js aggregates every pin — regenerating all lockfiles, pinning the GitHub Action SHAs, and syncing the Docker base-image digests in one `--fix`, with a `--check` gate wired into CI and the release flow so no pin can silently drift. The committed lockfiles are dev/example-only and excluded from the published tarball; the zero-npm-RUNTIME-deps rule is unchanged. **Added:** *scripts/pin-all.js — aggregated supply-chain pin tool* — One command re-pins every supply-chain segment: `--fix` regenerates the committed lockfiles (root / examples/wiki / fuzz), pins the GitHub Action SHAs, and syncs the Docker base-image digests; `--check` (wired into CI and the release flow) verifies the lockfile and digest segments — including each lockfile's package version — are in sync and fails closed on drift. Contributor tooling — it does not ship in the tarball. · *Project-governance and assurance documentation; OpenSSF Best Practices silver badge* — Adds a ROADMAP.md (documented direction plus an explicit out-of-scope list), a Developer Certificate of Origin policy in CONTRIBUTING.md (contributions carry a Signed-off-by; releases sign off through the release tooling), and an explicit security assurance case in SECURITY.md (a top security claim decomposed into evidence-backed sub-claims, with a residual-risk statement). The project earned the OpenSSF Best Practices silver badge, linked from the README. **Changed:** *Minimum Node.js engine raised to 24.18.0* — engines.node is now >=24.18.0 (was >=24.16.0). Operators must run Node 24.18.0 or newer. 24.17.0 was a security release and 24.18.0 bundles SQLite 3.53.1 plus a backup-keepalive fix; the floor also guarantees the native OpenSSL 3.5 SLH-DSA sign/verify surface. CI, the release container, and the docs are updated to the new floor. · *Supply-chain pinning consolidated behind committed lockfiles + `npm ci` + one aggregating pin tool* — The root dev-tool (esbuild, postject), examples/wiki, and fuzz (jazzer.js) manifests now ship committed package-lock.json files, and CI installs them with `npm ci` instead of `npm install pkg@version` — OpenSSF Scorecard's Pinned-Dependencies check treats only the `npm ci` verb as pinned, so this is what actually clears those alerts (an exact `@version` specifier does not). The vendored fuzz toolchain is pinned to an exact jazzer version and the oss-fuzz base image is digest-pinned (mirroring the Dependabot-tracked .clusterfuzzlite digest). A new scripts/pin-all.js aggregates every pinning segment — it regenerates all committed lockfiles, pins the GitHub Action SHAs (via check-actions-currency), and syncs the Docker base-image digests in one `--fix`; a `--check` mode runs in CI and scripts/release.js so a stale lockfile or drifted digest fails closed. The committed lockfiles are dev/example-only, excluded from the published tarball's files allowlist; the zero-npm-RUNTIME-deps rule is unchanged. **Security:** *Status-list verification binds the token type (RFC 8725 §3.11 typ-confusion)* — b.auth.statusList.fromJwt now passes expectedTyp "statuslist+jwt" to the JWT verifier, matching the typ that b.auth.statusList.toJwt stamps and every sibling verifier enforces. A token minted for another purpose — even one that happens to carry a status_list.lst claim — is now refused on the type binding before the claim is read, closing the typ-confusion class where such a token could be replayed as a status list.
+
 ## v0.15.x
 
+- v0.15.68 (2026-07-02) — **A security-hardening release: mail delivery-status / return-receipt / ARC builders reject CR, LF, and NUL in header-line fields (header injection); the XML canonicalizer's nesting cap now actually fires (stack-overflow DoS on deeply-nested SAML/WebDAV input); and the Idempotency-Key replay cache is scoped to the authenticated principal (cross-actor response disclosure) — plus archive/SRS byte hardening.** b.mail composes RFC 3464 delivery-status notifications (b.mail.send.deliver(...).buildDsn, b.mailBounce.dsn.build), RFC 8098 message-disposition notifications (b.mailMdn.build), and RFC 8617 ARC signatures (b.mail.arc.sign) by interpolating operator- and peer-supplied values — recipient addresses, the reporting-MTA name, the remote server's 5xx diagnostic reply, and the ARC authserv-id / domain / selector — into `Name: value` header lines. A value containing a CR or LF let a hostile original sender (whose message is being bounced) or a malicious peer MX (whose 5xx reply is echoed into the DSN) inject an extra header or forge an additional multipart/report part. Structured fields (addresses, MTA names, identifiers) are now rejected outright, and the free-text 5xx diagnostic — which is legitimately multi-line — is folded to a single line. The same class is closed in two adjacent places: tar and zip entry names refuse CR/LF (a bare LF in an over-long tar name flowed into the POSIX pax extended header, where a crafted name could forge a `path=` record that overrides the ustar name and escapes the extraction directory), and SRS envelope-from rewriting refuses control characters in the address it re-emits as a MAIL FROM. A new b.safeBuffer.assertHeaderSafe primitive centralizes the reject-CR/LF/NUL check every header builder now composes. **Added:** *b.safeBuffer.assertHeaderSafe(value, label, ErrorClass, code)* — Throws when a string bound for a CRLF-delimited protocol line contains CR, LF, or a NUL byte, in the caller's own error domain. Structured header fields (addresses, domains, identifiers, MTA names) compose it to reject. · *b.safeBuffer.foldHeaderText(value, replacement?)* — Folds free-text bound for a header line onto one line — replaces every CR and LF with the replacement (default a space) and removes every NUL. Used for values that may legitimately wrap, such as a multi-line SMTP 5xx reply echoed into a DSN diagnostic line, where rejecting would be too strict; unlike a plain CR/LF strip it also removes NUL, which is never valid in a header value and is treated specially by downstream mail parsers. **Changed:** *Refreshed the vendored public-suffix list and the pinned CI action SHAs* — The vendored Mozilla Public Suffix List (which backs registrable-domain boundaries in b.guardDomain and cookie-scope checks) is refreshed to its current upstream revision, and the SHA-pinned GitHub Actions in the release and scanning workflows are bumped to their latest upstream releases. No operator action required. · *Concurrent DNS cache misses are coalesced into a single upstream lookup* — b.network.dns.resolver now single-flights in-flight queries: when several callers miss the cache for the same name at once, one upstream lookup is issued and the others await its result, instead of each firing its own request (a cache stampede that amplified load on the upstream resolver). Each caller still applies its own DNSSEC validate gate against the shared answer. **Security:** *Delivery-status notifications refuse header-injecting fields; the 5xx diagnostic is folded* — b.mail.send.deliver(...).buildDsn and b.mailBounce.dsn.build build an RFC 3464 multipart/report message from the failing recipient, the original sender, the reporting-MTA name, the enhanced status code, and the remote server's 5xx diagnostic reply. The 5xx reply is attacker-influenceable (it comes from the peer MX) and the addresses can come from a message being bounced. A CR or LF in any of these smuggled a new header or forged a report part into a message the operator then relays. Structured fields now reject CR/LF/NUL (the composer throws rather than emit an ambiguous message), and the free-text diagnostic is folded to one line so its text is preserved without introducing a line break. · *Message-disposition notifications refuse header-injecting fields* — b.mailMdn.build places the final recipient, original recipient, original message-id, reporting user-agent, and the From/To/Subject of the return receipt on header lines. Because an MDN is generated in response to an inbound message, these fields can carry attacker-chosen content; a CR or LF injected a header into the receipt. Each structured field now rejects CR/LF/NUL before the message is built. · *ARC signing refuses CR/LF/NUL in the authentication-results identity* — b.mail.arc.sign already refused CR/LF in the authentication-results value, but the ARC authserv-id, signing domain, and selector — interpolated verbatim into the ARC-Authentication-Results, ARC-Seal, and ARC-Message-Signature header block — were only checked for emptiness. A CR or LF in one of them injected a header into the signed block. All three now reject CR/LF/NUL. · *Archive entry names refuse CR/LF, closing a pax path-override escape* — tar and zip entry names already rejected a NUL byte and `..` segments but not CR/LF. In a tar archive, a bare LF in an over-long name flowed into the POSIX pax extended header (`len key=value\n`); because a pax `path=` record overrides the ustar header's name, a crafted name could inject an absolute `path=` record and write outside the extraction directory — an escape the `..` check does not catch. Both the tar and zip name normalizers now reject CR/LF. · *SRS envelope rewriting refuses control characters in the address* — b.mail.srs rewrite / srs1Rewrite / reverse embed the address they are given into the SRS0/SRS1 envelope address that becomes a subsequent SMTP MAIL FROM. They now reject CR/LF/NUL in the input address so a malformed address cannot be smuggled into an envelope command. · *The XML canonicalizer's nesting-depth cap now actually fires (stack-overflow DoS)* — b.xmlC14n.parse — the recursive-descent parser behind SAML and WebDAV canonicalization — carried a documented 200-level nesting cap that was dead: the depth counter was a per-frame-local incremented then decremented around each single recursive call, so it never exceeded 1 at the check. Deeply-nested untrusted XML recursed unbounded and overflowed the stack, crashing the process — a pre-authentication denial of service for any endpoint that canonicalizes attacker-supplied XML. The depth is now threaded through the recursion and enforced at entry, so nesting past the cap is refused before it can exhaust the stack. · *The Idempotency-Key replay cache is scoped to the authenticated principal* — b.middleware.idempotencyKey keyed its replay/response cache slot solely on the client-supplied Idempotency-Key header, with no binding to the authenticated principal. Two principals presenting the same (shared or guessed) key collided: one was served the other's cached response (cross-actor disclosure), or an attacker could pre-seed a key to force a 422 on the real client (cross-actor denial). The slot is now scoped to the authenticated principal, resolved via b.requestHelpers.extractActorContext and overridable with the new opts.scopeFn. Mount the middleware after authentication so the request carries the principal; slots for unauthenticated requests share a single anonymous scope. · *Mail and data parsers reject reserved prototype keys in untrusted input* — b.csv.parse, b.mime-parse (Content-Type parameters), b.eat (Entity Attestation Token claims), b.mailBimi (tiny-PS attributes), b.mailArf (feedback-report fields), and b.safeIcap (ICAP response headers) built plain objects keyed by names taken directly from untrusted input. A key of __proto__, constructor, or prototype would shadow or re-parent the object, letting an attacker taint a downstream type check. Every one of these sites now refuses the reserved keys — CSV throws csv/forbidden-header (an operator DDL surface); the parsers that must stay lenient drop the poisoned key and keep parsing. · *Verifiable-credential JOSE verification binds the algorithm to the key's curve* — b.vc.verify / b.vc.verifyPresentation resolved the public key and then verified with the algorithm named in the attacker-controlled JWS header, with no check that the two agree. A header claiming ES384 (or EdDSA) could be verified against a P-256 key an ECDSA curve/type confusion (CWE-347, RFC 7518 §3.4). The verifier now rejects any alg whose required curve/key-type doesn't match the resolved key, before the signature check. · *Span-event names are redacted on the telemetry wire* — The OTLP span exporter ran span names and exception messages through the telemetry redactor but passed span-EVENT names through verbatim, so a value-shape secret (a connection string, a token) placed in an event name egressed unredacted. Event names now route through the same redactor as span names, on both the JSON and protobuf wire paths. · *Session refresh enforces the idle and absolute timeout floors* — b.session.touch refreshed a session's activity timestamp without re-checking the idle / absolute timeout floors that b.session.verify enforces, so a floor-expired session could be resurrected by a refresh instead of being killed. Both floors are now evaluated on the refresh path (as on verify), and a session past either floor is deleted rather than extended.
+
+- v0.15.67 (2026-06-29) — **Path-scoped router middleware can no longer be bypassed by percent-encoding the request path: the router refuses an encoded path separator or null byte and decodes the path once, so a security gate and the resource it guards always agree on the path.** b.router supports path-scoped middleware — router.use('/admin', gate) runs a gate (requireAal, bearerAuth, requireMtls, csrfProtect, …) only for requests under a prefix. The gate matched the request path with its percent-escapes intact, while downstream consumers such as b.staticServe and router.serveStatic percent-decode the path before resolving the file. Because the gate and the consumer disagreed on decoding, an attacker could encode a character in the guarded segment (/%61dmin/secret) or hide a separator (/admin%2fsecret) so the gate's segment match missed while the consumer still reached the protected resource — an authentication, authorization, CSRF, or mTLS bypass for any resource served under a scoped gate. The router now refuses a request whose path contains an encoded path separator (%2f, %5c) or null byte (%00), and decodes the remaining escapes exactly once, so the gate, the route matcher, and every consumer act on a single canonical path. A request that legitimately needs those bytes was always ambiguous and is now rejected with 400 rather than silently routed two different ways. Route parameters captured from the path are now percent-decoded, matching the conventional behavior. **Changed:** *Encoded path separators and null bytes in the request path are refused; route params are decoded* — A request whose path contains %2f, %5c, or %00 is answered with 400 Bad Request — these have no unambiguous routing meaning (a consumer would treat them as a separator or terminator), and a request that needs a literal slash in a value should carry it in a query parameter. Path parameters captured by a route pattern (for example :id) are now percent-decoded before they reach the handler in req.params, matching conventional router behavior; handlers that previously received a still-encoded value will now receive the decoded form. **Security:** *Path-scoped middleware is no longer bypassable via percent-encoded paths* — A gate mounted with router.use(prefix, mw) matched req.pathname with percent-escapes preserved, but b.staticServe and router.serveStatic decode the path before resolving the resource. An attacker could percent-encode a character in the guarded segment (/%61dmin/secret, where %61 is 'a') so the segment compare saw '%61dmin' and skipped the gate, or hide a separator (/admin%2fsecret) so the gate saw one segment while the file resolver saw two — in both cases the protected resource was served without the gate running. The router now rejects a path containing an encoded separator (%2f/%5c) or null byte (%00) with 400, and percent-decodes the path exactly once before any path-scoped decision, so the gate and the resource it protects always resolve the same path. Operators who mounted authentication, authorization, CSRF, or mTLS gates with the scoped form no longer have a silent bypass beneath them.
+
+- v0.15.66 (2026-06-29) — **Recursive serializers and parsers refuse pathologically deep input with a typed error instead of overflowing the stack and crashing the process.** Several of the framework's recursive walkers over attacker-reachable input lacked an effective nesting cap, so a deeply nested value could exhaust the V8 call stack and throw an uncaught RangeError — crashing the process (a denial of service). b.canonicalJson is the most exposed: content-credentials verification canonicalises an untrusted manifest before it checks the signature, so a hostile credential could crash a verifier pre-authentication. b.jsonSchema.validate had a depth guard, but its limit was set so high the stack overflowed before the guard could fire, so validating a request body against a recursive schema crashed rather than returning a typed error. b.i18n.messageFormat parsed and rendered nested plural/select cases with no cap. Each walker now throws a typed framework error well before native overflow, and legitimate (even deeply nested) input is unaffected. The release also corrects DNSSEC signature-window comparison to the RFC 1982 serial-number arithmetic the spec requires, and makes the Redis client treat a malformed reply frame as a connection fault rather than letting it crash the host. **Fixed:** *DNSSEC compares RRSIG validity windows with RFC 1982 serial arithmetic* — b.network.dns.dnssec compared an RRSIG's inception and expiration against the current time by magnitude. RFC 4034 §3.1.5 requires the 32-bit timestamps to be interpreted with RFC 1982 serial-number arithmetic, which agrees with a plain comparison only while the values stay below 2^31. A signature whose window straddles the 2^31 (January 2038) or 2^32 (February 2106) boundary was mis-ordered — an in-window signature rejected, or a stale one accepted. The comparison now masks the clock into the same 32-bit serial space and tests the wrapped signed delta. **Security:** *Canonical JSON refuses excessively nested input before it can overflow the stack* — b.canonicalJson.stringify and stringifyJcs walk the value recursively. They detected circular references but had no nesting cap, so a deeply nested (acyclic) object or array overflowed the V8 stack with an uncaught RangeError. This is reachable before authentication: content-credentials verification canonicalises the untrusted manifest to hash it before verifying the signature, so a hostile credential could crash the verifier. Both serializers now throw a typed nesting-depth error at a depth far beyond any legitimate signed document and well short of native overflow. · *JSON Schema validation depth guard now fires before the stack overflows* — b.jsonSchema.validate caps subschema-validation nesting to defend against a recursive schema (for example items pointing back at the root with $ref) applied to a deeply nested instance — both attacker-controlled when validating a request body. The cap was set so high the V8 stack overflowed first, so the guard never ran and a crafted body crashed the validator with an uncaught RangeError instead of the typed reference-depth error. The limit is now well under native overflow; legitimate documents — deeply nested or wide — continue to validate. · *ICU MessageFormat refuses pathologically nested templates* — b.i18n.messageFormat.parse and format recurse once per nested plural/select case, with no depth cap. A template nested thousands of levels deep overflowed the stack. format() and parse() are public and b.i18n.t can render operator-supplied entries, so a hostile template is a denial-of-service vector; it now fails as a typed bad-template error. Real-world nesting (a handful of levels) is unaffected. · *Redis client treats a malformed reply frame as a connection fault, not a crash* — The RESP decoder recurses on nested arrays with no depth cap, and the data handler did not guard the parse, so a malformed or hostilely deep frame from a server threw out of the socket callback and could crash the host. The decoder now caps reply nesting and any parse fault tears the socket down and rejects in-flight commands for a reconnect — the same path as any other lost connection.
+
+- v0.15.65 (2026-06-29) — **The account-takeover kill-switch now actually locks the account: b.auth.lockout gains a lock() method and the kill-switch engages it through the operator's lockout instance.** b.auth.atoKillSwitch.trigger is the incident-response path for a compromised account: it destroys the user's sessions and then locks them out of new logins. The lockout step called b.auth.lockout.lock(), but no such method existed (and the kill-switch invoked it on the lockout module, which has no store), so the call threw and was swallowed — the kill-switch reported success while never locking the account, leaving an attacker who still held the credentials free to log straight back in. b.auth.lockout instances now expose lock(key, { durationMs?, untilMs?, reason? }) to force an account into lockout immediately, atomically, independent of the failure counter, and atoKillSwitch.trigger engages it through the lockout instance the operator passes as opts.lockout. When no lockout instance is supplied the step is skipped and the result's lockoutApplied is false (with an audit row), rather than silently claiming the account was locked. The release also closes a lock-clear race in lockout and refuses a self-disabling window. **Added:** *b.auth.lockout instances expose lock()* — lock(key, { durationMs?, untilMs?, reason? }) forces an account into lockout immediately — the operator action behind an ATO kill-switch or incident response — independent of the failure counter, defaulting to a long admin lock. A forced lock is released only by an explicit unlock(): recordSuccess() does not clear it, so a successful login by someone who still holds the compromised password cannot release a kill-switch lock. It uses the same atomic compare-and-set as the failure counter and throws if the lock cannot be committed (the caller must know it did not lock). **Security:** *Account-takeover kill-switch engages the lockout instead of silently doing nothing* — b.auth.atoKillSwitch.trigger invoked b.auth.lockout.lock(), which did not exist; the call threw and was caught by a best-effort guard, so the kill-switch destroyed sessions but never locked the account — an attacker still holding valid credentials could immediately re-authenticate. b.auth.lockout instances now provide lock() (an atomic, compare-and-set forced lockout), and the kill-switch calls it on the lockout instance supplied as opts.lockout. Without a lockout instance the lockout step cannot run; the result's lockoutApplied is false and an audit row records that the account was not locked, so an operator is not misled into believing a compromised account was secured. opts.lockout is now the lockout instance (or false to skip), not a boolean toggle. · *lockout clears the failure counter atomically and refuses a zero window* — b.auth.lockout.recordSuccess and unlock cleared state with a read-then-delete, which could erase a lock a concurrent recordFailure had just engaged; they now clear under the same compare-and-set the failure path uses. create() also refuses windowMs: 0, which previously disabled lockout entirely (every failure decayed immediately and the zero-TTL state never persisted).
+
+- v0.15.64 (2026-06-29) — **Token and HTTP-message-signature verifiers now reject a non-finite clock-skew or tolerance value instead of letting it disable the expiry, not-before, and future-dating checks.** Several verifiers read an operator-supplied clock-skew or tolerance value with a bare type check that accepted Infinity and NaN. Because the resulting comparison (for example exp + skew < now, or age > tolerance) is always false when the skew or tolerance is Infinity, a misconfigured non-finite value silently disabled the time-window check — so an expired token, a not-yet-valid token, a future-dated signature, or a replayed (too-old) signature would verify. The affected paths are the shared external-JWT verifier b.auth.jwt.verifyExternal (which the JAR / signed-request-object path also uses), the SD-JWT-VC credential verifier, the OAuth ID-token and client-attestation verifiers, and the HTTP message signature verifier's freshness and clock-skew windows. Each now requires a present skew or tolerance to be a non-negative finite number: the throw-based JWT, SD-JWT-VC, and OAuth verifiers reject a malformed value, and the verdict-returning HTTP-message-signature verifier falls back to its safe default rather than disabling the window. A build check now fails if any verifier reads one of these options without a finiteness guard. **Added:** *verifyExternal and jar.parse accept an `now` clock override* — b.auth.jwt.verifyExternal and b.auth.jar.parse now accept an optional `now` (a finite epoch-milliseconds value) to evaluate a token's exp / nbf / iat as of a specific instant instead of the wall clock — consistent with b.auth.sdJwtVc.verify. A negative clockSkewMs is no longer accepted as a way to shift the evaluation time; use `now`. **Security:** *Non-finite clock-skew / tolerance no longer disables a verifier's time-window check* — b.auth.jwt.verifyExternal, b.auth.sdJwtVc.verify, b.auth.oauth (ID-token and client-attestation verification), and the HTTP message signature verifier read their clock-skew, max-clock-skew, max-PoP-age, and tolerance options with a bare `typeof === "number"` check that let Infinity and NaN through. With such a value the expiry / not-before / future-dating comparison is always false, so the check was silently skipped and an expired or not-yet-valid token — or a future-dated or replayed signature — would verify. The JWT, SD-JWT-VC, and OAuth verifiers now reject a non-finite or negative skew (the option is operator configuration, not attacker-controlled), and the HTTP message signature verifier falls back to its default tolerance and skew. The CWT, DPoP, SAML, and OpenID Federation verifiers already enforced this and are unchanged. **Detectors:** *Verifier clock-skew / tolerance options must be finite-guarded* — A build check fails if a verifier reads a clock-skew or tolerance option with a bare `typeof === "number"` without a finiteness guard (a non-negative-finite check, an inline isFinite fallback, or a create-time non-negative-finite schema), preventing a future verifier from reintroducing the disable-the-window class.
+
+- v0.15.63 (2026-06-29) — **OID4VCI now enforces single-use of a pre-authorized code and of a single-use access token under concurrency, so two simultaneous requests can no longer mint two credentials from one.** On the OID4VCI credential issuer, two single-use values were consumed by a delete whose result was ignored, so concurrent requests could each act on the same value. exchangePreAuthorizedCode read the pre-authorized code's entry, validated the transaction code, then deleted the code and minted an access token without checking that its own call had removed the entry — two simultaneous /token requests with the same code each saw the entry, each deleted it, and each minted a distinct access token, issuing two access tokens (and ultimately two credentials) from a code OID4VCI requires to be single-use. issueCredential had the same shape: with single-use access tokens (the default), it minted the credential first and deleted the access token afterward as best-effort cleanup, so two concurrent requests bearing the same token both read it and the same not-yet-rotated c_nonce, both proofs verified, and both minted a credential. Both paths now claim the value with an atomic delete and proceed only when that delete succeeded; the losing request is refused. The transaction-code and proof checks still run first, so a bad transaction code or proof does not consume the value (a wallet can retry). **Security:** *OID4VCI pre-authorized code and access token are single-use under concurrency* — exchangePreAuthorizedCode and issueCredential consumed their single-use value (the pre-authorized code, and the single-use access token) with a delete whose return was discarded, and in issueCredential's case after the credential was already minted. Two concurrent requests carrying the same value therefore each succeeded — minting two access tokens from one pre-authorized code, or two credentials from one single-use access token — defeating the single-use guarantee OID4VCI §3.5 requires (an authorization intended for one credential could yield two). Both paths now delete the value atomically and issue only if that delete removed it, refusing the request that lost the race; the transaction-code and proof verifications run before the claim, so an invalid attempt does not burn the value. If the operator's credential issuer throws after the access token has been claimed (a transient signer outage), the token is restored so the wallet can retry rather than being permanently consumed without a credential.
+
+- v0.15.62 (2026-06-29) — **ARC evaluation now reads each hop's instance with the same strict parser the signature checks use, so a crafted ARC-Authentication-Results header can no longer forge the upstream auth-results surfaced to downstream policy.** b.mail.arc.evaluate returns finalAr — the most recent hop's ARC-Authentication-Results, the receiver's view of the upstream authentication results — which operators may key downstream decisions on. The instance tag (i=) on each ARC header was parsed by three different regexes: the indexing pass that drives the AMS/AS signature checks required i= with no surrounding space and at most three digits, while the finalAr extraction and the AMS header-retention test accepted a looser form (a space around =, unbounded digits). When a sealer signs without covering ARC-Authentication-Results in its AMS h= (permitted by RFC 8617 and supported by the verifier), an attacker holding no key could append a second ARC-Authentication-Results written so the strict pass ignored it while the loose pass consumed it — forging finalAr on a chain that still verified as pass. All ARC instance reads now route through one strict parser, so the evaluation surfaces the same hop the signatures validated. The release also repairs the b.mail.arc.sign excludeAarFromAms option (it was read but rejected by option validation, so the documented opt-out was unreachable) and routes the ARC-Seal signature's b= stripping through the shared tag-aware helper. **Fixed:** *ARC finalAr is read from the strictly-indexed hop, not a looser rescan* — b.mail.arc.evaluate extracted finalAr (and validated the per-hop AMS header retention) with a regex that accepted ARC instance tags the signature-indexing pass rejected — a space around i= or more than three digits. A sealer that omits ARC-Authentication-Results from its AMS h= leaves the AAR outside signature coverage; an attacker could then inject a second ARC-Authentication-Results whose instance the strict crypto pass skipped but the finalAr pass accepted, presenting attacker-chosen upstream auth-results on a chain that still reported pass. Every ARC instance read now goes through a single strict parser, so finalAr is always the AAR the chain's signatures actually covered. · *b.mail.arc.sign accepts excludeAarFromAms again* — The excludeAarFromAms option was read when building the AMS h= list but was missing from the function's option allow-list, so passing it raised an unknown-option error — the documented opt-out could not be used. It is now accepted. · *ARC-Seal b= stripping uses the shared tag-aware helper* — The ARC-Seal verification stripped the signature's b= value with a regex that could mis-zero a value containing b= inside another tag; it now uses the same tag-aware stripper as DKIM, so canonicalization matches the signer in every case. **Detectors:** *ARC instance parsing must use the shared strict reader* — A check fails the build if any ARC instance (i=) parsing regex is added outside the single shared reader, preventing a future divergence between the signature-indexing pass and the finalAr / header-retention passes.
+
+- v0.15.61 (2026-06-29) — **The local and Redis job queues fence completion, failure, and lease extension on the lease the caller actually holds, so a worker finishing after its lease expired can no longer disturb a job another worker has since taken over.** On the local and Redis queue backends, complete(), fail(), and extendLease() identified a job only by its id. When a worker's lease expired, the sweep returned the job to the ready set and another worker leased and began running it; if the original worker then finished late, its complete() could mark the new worker's in-progress job done (and double-fire a cron repeat or re-release flow children), and its fail() could re-queue or dead-letter a job the new worker was still executing. Each lease now carries the job's attempts value (incremented once per lease), and complete(), fail(), and extendLease() act only when that value still matches — so a call from a worker that no longer holds the lease changes nothing. The generic consumer threads this automatically; the SQS backend already bound these actions to the message's receipt handle and is unchanged. **Fixed:** *Local and Redis queues bind complete/fail/extendLease to the held lease* — A long-running handler whose lease expired and was swept could have its job re-leased to a second worker; when the first worker finished, complete() marked the second worker's in-progress job done — double-firing a cron-recurring job's next enqueue and re-releasing its flow dependents — while fail() re-queued or dead-lettered the job the second worker was still running (re-executing or discarding in-flight work). The backends now fence each of these calls on the leased attempts value, which is bumped once per lease; only the worker that holds the current lease can complete, fail, or extend it. A stale call returns without mutating the queue. This brings the local and Redis backends to parity with the SQS backend, which already bound these actions to the message receipt handle.
+
+- v0.15.60 (2026-06-29) — **`requireStepUp` binds the elevation grant to the authenticated principal, refusing a grant minted for a different user (cross-user step-up replay).** The b.middleware.requireStepUp gate accepts an operator-issued step-up elevation grant from the X-Step-Up-Grant header and verifies it with b.auth.stepUp.grant.verify. An elevation grant carries the subject it was minted for (payload.sub), but the middleware verified only the grant's signature, expiry, and scope — never that the grant's subject matched the request's authenticated principal. A grant minted for one user (and then leaked through a shared cache, a log line, a referrer, or a shared device) therefore satisfied the step-up requirement for ANY other authenticated user who presented it, elevating their session to the granted assurance level without ever completing a step-up ceremony. requireStepUp now passes the resolved principal as the grant's required subject, so the grant satisfies step-up only for the user it was issued to. The principal is resolved from whichever shape the authenticator populated — a session's req.user.id / req.user.userId, or the JWT subject (req.user.claims.sub / req.user.sub) set by bearerAuth with an external verifier — so a grant legitimately minted for a JWT subject still binds. A request with no resolvable principal cannot bind the grant and falls through to the claims-based challenge. **Security:** *Step-up elevation grants are bound to the authenticated principal* — requireStepUp's grant path called b.auth.stepUp.grant.verify with only the grant scope, not the subject, so any holder of a valid, unexpired, scope-matching elevation grant passed the step-up gate regardless of which user the request was authenticated as — a leaked or shared grant elevated a different user's session (cross-user step-up replay). The grant already binds a subject at mint time and the verifier supports a subject check; the middleware now supplies the request's principal as the required subject, refusing a grant whose subject does not match. The principal is read from whichever field the authenticator set — a session's id/userId or the JWT subject (claims.sub / sub) from bearerAuth's external verifier — so a grant minted for any of those binds correctly. A request with no authenticated principal cannot bind a grant and is handled by the normal claims-based step-up challenge. The grant verifier's signature/expiry/scope/jti-revocation checks are unchanged.
+
+- v0.15.59 (2026-06-29) — **OCSP response validation binds the response to the certificate's issuer (issuerNameHash + issuerKeyHash), not the serial number alone, refusing a wrong-issuer "good".** An OCSP SingleResponse identifies the certificate it covers by a CertID of (hashAlgorithm, issuerNameHash, issuerKeyHash, serialNumber) — RFC 6960 §4.1.1. b.network.tls.ocsp.evaluate matched a response to the certificate under validation by the serial number alone and never compared the CertID's issuer hashes. Because a serial number is unique only within one issuer, a responder key that serves more than one issuer identity — a delegated OCSP responder, or a CA key spanning issuers — could have a signed "good" response for serial-S under issuer-Y accepted as proof for the serial-S certificate under issuer-X. The evaluator now recomputes the expected issuerNameHash and issuerKeyHash from the issuer certificate and refuses a response whose CertID issuer hashes do not match. b.network.tls.ocsp.fetch supplies the issuer certificate automatically (its issuerPem is the leaf's issuer); ocsp.requireGood and direct ocsp.evaluate callers pass the issuer cert explicitly as the new issuerCertDer (requireGood's issuerPem may be a delegated OCSP responder rather than the issuer, so it is not used as the issuer), and a response with no issuer certificate available stays bound on serial plus signature as before. **Security:** *OCSP evaluate binds the response CertID to the issuer, not the serial alone (RFC 6960 §4.1.1)* — b.network.tls.ocsp.evaluate selected the matching SingleResponse by normalized serial number only, ignoring the CertID's issuerNameHash and issuerKeyHash. Since serials are unique only per issuer, a "good" response signed by a key that also serves a different issuer (a delegated id-kp-OCSPSigning responder, or a shared CA key) could be replayed as proof for a same-serial certificate under another issuer. evaluate now recomputes the expected issuerNameHash = Hash(issuer DN) and issuerKeyHash = Hash(issuer public key) under the CertID's own hash algorithm and refuses the response if either differs ("wrong-issuer response"). b.network.tls.ocsp.fetch forwards the issuer certificate automatically (its issuerPem is the leaf's issuer); ocsp.requireGood and a direct ocsp.evaluate caller enable the binding by passing issuerCertDer (the issuer cert DER) — requireGood's issuerPem may be a delegated OCSP responder, so the issuer cert is taken explicitly rather than derived from it — and a call without an issuer certificate retains the prior serial-plus-signature binding.
+
+- v0.15.58 (2026-06-29) — **File-upload content-safety scanning now also runs the gate for a file's magic-byte-detected type, so a mislabeled file can't dodge the scanner for its real type by choosing the extension.** b.fileUpload selected the per-extension content-safety gate purely from the upload's filename extension, which the uploader controls. A file whose magic bytes identify one type but whose name carries another extension (e.g. a PDF named photo.png) was therefore scanned by the gate for the named extension — or, when no gate was registered for that extension, not scanned at all — so an uploader could dodge the scanner configured for the file's real type by renaming it. When a fileType detector is wired, finalize now also runs the content-safety gate for the type the magic bytes identify, in addition to the filename-extension gate, so the scanner for the real type runs even under a mismatched name. Magic-byte-less text formats (HTML, SVG, CSV) cannot be classified this way; that residual is covered by serving uploads with an explicit Content-Type plus X-Content-Type-Options: nosniff and by registering a content-safety gate for every accepted extension. **Security:** *Content-safety gate selection follows the sniffed type, not just the filename extension* — finalize chose the content-safety gate from nodePath.extname(filename), so a file's real type could be hidden behind a chosen extension: a PDF named photo.png ran the .png gate (or, with no .png gate, skipped scanning) and never reached the .pdf scanner. When opts.fileType is wired, finalize now detects the magic-byte type and, if it differs from the filename extension and a gate is registered for it, runs that gate too (alongside the filename-extension gate), refusing or sanitizing per the gate's decision. Existing behavior is unchanged when no fileType detector is wired or the detected type matches the extension. Formats without magic bytes (HTML/SVG/CSV/plain text) remain undetectable by content sniffing — defend those by serving stored files with a fixed Content-Type and X-Content-Type-Options: nosniff, and by registering a content-safety gate for each accepted extension.
+
+- v0.15.57 (2026-06-29) — **The RFC 9421 HTTP-message-signature verifier now enforces a required-coverage floor by default, refusing a signature whose covered set omits `@method` / `@target-uri` (and `content-digest` for bodied requests).** b.crypto.httpSig.verify built the signature base entirely from the covered-component list carried in the message's own Signature-Input header and never checked that the signature actually covered the security-relevant parts of the request (RFC 9421 §3.2). A signature covering only @authority therefore verified even after the method, target URI, or body were changed — so a captured signature could be replayed across a different method and path, or a request body swapped, under an otherwise-valid signature. verify now refuses a signature whose covered set omits a required component, returning { valid: false, reason: "missing-required-component", missing: [...] } before the cryptographic check. By default (security-on, not opt-in) it requires @method and @target-uri on every request, plus content-digest when the request carries a body; an operator can pass requiredComponents to assert an exact set, or requiredComponents: [] to waive the floor (the signature itself is still verified). **Security:** *httpSig.verify enforces a required-coverage floor (RFC 9421 §3.2)* — The verifier trusted the covered-component list from the message's Signature-Input header without requiring that any particular component be covered, so an under-covered signature (e.g. covering only @authority) verified while the method, target URI, and body were free to change — a captured signature replayed across method+path, or a swapped body, passed verification. verify now refuses a signature missing a required component with reason "missing-required-component" (and a missing[] list) before the crypto check. The default floor is @method + @target-uri on every request plus content-digest for bodied requests; requiredComponents overrides it explicitly, and requiredComponents: [] waives the floor for callers that intentionally sign a narrower set (the signature itself is still verified). **Migration:** *Signers must cover @method + @target-uri (and content-digest for bodied requests)* — If you verify HTTP message signatures with b.crypto.httpSig.verify, signatures whose covered set omits @method or @target-uri (or content-digest on a request with a body) now fail with reason "missing-required-component". Broaden the signer's covered set to include them (recommended), pass requiredComponents to assert the exact components your application requires, or pass requiredComponents: [] to keep the prior behavior of accepting whatever the signer covered. Verifying a fully-covered signature is unchanged.
+
+- v0.15.56 (2026-06-29) — **Break-glass and dual-control wildcard scope matching is now segment-aware, and the JMAP cross-tenant gate validates every account-id argument (including `fromAccountId`), closing two authorization gaps.** Two authorization gates under-checked their input. b.breakGlass and b.dualControl matched a wildcard scope/role by stripping a trailing "*" and doing a raw string-prefix comparison (requireScope.indexOf(prefix) === 0), which ignores ":" segment boundaries — so a partial-segment grant like "phi:a*" satisfied a required "phi:admin", letting a holder break-glass-unseal or approve a flow they were not scoped for. Both now match through the canonical, segment-aware b.permissions.match, so only an exact scope or a whole-segment wildcard ("phi:*") satisfies the requirement. Separately, the JMAP server's cross-tenant gate validated only a method call's destination accountId, not the fromAccountId that /copy methods (Email/copy, CalendarEvent/copy — RFC 8620 §5.4) read their SOURCE account from — so an actor could name a foreign fromAccountId and copy another tenant's data. The gate now validates every account-id argument the call names. **Security:** *Break-glass / dual-control wildcard scope matching is segment-aware* — b.breakGlass grant (requireScope) and b.dualControl approval (approverRoles) matched a wildcard-shaped actor scope/role by stripping its trailing "*" and testing requireScope.indexOf(prefix) === 0 — a raw string prefix that ignores the ":" segment structure. A partial-segment grant therefore over-matched: "phi:a*" satisfied "phi:admin" (and "p*" satisfied any "phi:..."), so an actor with a narrower grant could break-glass-unseal sealed data or approve a dual-control flow they were not authorized for. Both sites now match through b.permissions.match, where "*" must occupy a whole ":"-delimited segment — "phi:*" still satisfies "phi:admin", but "phi:a*" does not. Actor scopes/roles flow from operator-trusted assignment, so this tightens a defense-in-depth gate rather than a request-controlled bypass. · *JMAP cross-tenant gate validates every account-id argument, not only the destination* — The JMAP server rejects a method call that names an accountId outside the actor's enumerated set (RFC 8620 §3.6.1). It checked only accountId, but /copy methods (Email/copy, CalendarEvent/copy — RFC 8620 §5.4) also carry fromAccountId, the SOURCE account they read from. An actor enumerated for their own destination account could therefore name a foreign fromAccountId and have the operator's copy handler read another tenant's messages. The gate now validates every account-id argument (any *AccountId) against the actor's enumerated accounts before the handler runs, so a foreign source account is refused with accountNotFound. **Detectors:** *Scope/role wildcard matching must use b.permissions.match* — A codebase-patterns detector flags the hand-rolled wildcard idiom (a trailing-"*" check plus a slice(0,-1) strip plus a raw indexOf(prefix)===0 prefix match), so a new authorization gate cannot reintroduce a segment-unaware scope match instead of routing through b.permissions.match.
+
+- v0.15.55 (2026-06-29) — **`b.fileUpload` enforces per-upload ownership: acceptChunk / finalize / status / cancelUpload now refuse a caller who is not the upload's owner, closing an IDOR.** A file-upload manager recorded the owner of each upload at init() but never checked it again: acceptChunk, finalize, status, and cancelUpload looked the upload up by the caller-supplied uploadId alone. The only gate was the coarse "fileUpload.<op>" permission scope, which says whether an actor may perform the operation at all — not whether they own the specific upload. So any caller holding the (commonly shared) fileUpload.finalize / cancel / status / accept scope could finalize, cancel, read the status of, or push chunks into another actor's in-flight upload by its uploadId (an insecure-direct-object-reference, CWE-639). Each lifecycle method now compares the calling actor against the stored owner (actor.id || actor.userId, captured at init) and refuses a non-owner. Operator admin tooling that must act across actors opts in with create({ allowCrossActor: true }); when a permissions instance is wired, cross-actor access additionally requires the new "fileUpload.admin" scope, so the escape hatch is itself gated. Uploads created without an actor are owned by the anonymous identity and unreachable by a named actor (fail-closed). **Security:** *File-upload lifecycle methods enforce per-upload ownership (IDOR fix)* — acceptChunk, finalize, status, and cancelUpload previously authorized only against the coarse fileUpload.<op> capability scope, never against the upload's recorded owner, so a caller with that scope could act on any actor's upload by guessing or enumerating its uploadId. Each method now refuses a caller whose identity (actor.id || actor.userId) does not match the owner stored at init() — raising fileUpload OWNERSHIP_VIOLATION — so an upload is reachable only by the actor that created it. Cross-actor admin tooling opts in via create({ allowCrossActor: true }) plus the new fileUpload.admin permission scope (required when permissions are wired); list({ scopeToActor: false }) remains the deliberate cross-actor listing view. Operators whose workflows legitimately hand an upload between actors must set allowCrossActor and grant fileUpload.admin to the acting principal. **Detectors:** *fileUpload lifecycle methods must enforce ownership* — A codebase-patterns detector flags any fileUpload lifecycle method that loads an upload by a request-supplied uploadId without calling the ownership check before acting, so a newly added method cannot silently reintroduce the IDOR.
+
+- v0.15.54 (2026-06-28) — **SAML federation-metadata (MDQ) verification binds the signature to the consumed EntityDescriptor and refuses signature-wrapping, closing an IdP trust-anchor takeover.** b.auth.saml.fetchMdq validates signed federation metadata with the same XML-dsig verifier the assertion path uses, but discarded the verified reference and never bound it to the EntityDescriptor the operator consumes — unlike verifyResponse, which already enforces that the signature covers the element it trusts. Combined with a first-child Signature lookup, an attacker controlling or interposing on the MDQ source could wrap a genuinely federation-signed EntityDescriptor under a forged container (or bury it in an EntityDescriptor whose own ID and signing certificate are attacker-chosen): the signature still validated over the buried element, fetchMdq returned the whole document, and the operator extracted the attacker's certificate as the IdP signing key — a full SAML authentication bypass (the CVE-2024-45409 / ruby-saml signature-wrapping class). fetchMdq now requires the metadata root to be a single EntityDescriptor, binds the verified reference to that root's ID (mirroring verifyResponse), confirms the signed entityID is the one requested, and refuses a duplicate top-level Signature. **Security:** *fetchMdq binds the federation signature to the consumed EntityDescriptor (XML signature-wrapping defense)* — On the MDQ trust-bootstrap path, fetchMdq verified the federation signature but discarded the reference it covered, so the signature did not have to cover the EntityDescriptor whose signing certificate the operator subsequently trusts. An attacker with a malicious or interposed MDQ responder could pair a genuine federation signature over a buried entity with a forged outer/sibling EntityDescriptor carrying their own signing certificate; fetchMdq accepted and returned the wrapped document, and the operator installed the attacker certificate as the IdP trust anchor — forging arbitrary assertions thereafter. fetchMdq now refuses a non-EntityDescriptor root (the EntitiesDescriptor wrapper), refuses a duplicate top-level Signature, binds the verified reference to the document-root EntityDescriptor's ID, and confirms the signed entityID matches the requested one — mirroring the wrapping defenses verifyResponse already applies to assertions. New error codes: auth-saml/mdq-not-entity-descriptor, auth-saml/mdq-duplicate-signature, auth-saml/mdq-entity-mismatch (plus the existing auth-saml/signed-different-element for a buried-reference root). Verification of legitimately signed single-entity metadata is unchanged.
+
+- v0.15.53 (2026-06-28) — **DKIM (and ARC) verification refuses a body-length-limited (`l=`) signature once content has been appended past the signed octets, closing the append-after-signature attack.** A DKIM signature with an `l=` body-length tag covers only the first `l=` octets of the canonicalized body, so anyone in the delivery path can append arbitrary unsigned content after the signed prefix and the body hash still matches. b.mail.dkim.verify honored such a signature and returned `pass`, with only a non-load-bearing warning that no consumer read — so b.mail.inbound.verify granted an aligned DMARC `pass` to a message whose delivered body diverged from the signed bytes (RFC 6376 §8.2). Verification now refuses an `l=` signature once the delivered body extends beyond the signed octets: the verified prefix no longer authenticates the appended content, so the result is a body-hash `fail` rather than a `pass`. Signatures whose `l=` exactly covers the body (no appended content) are unchanged, and an operator who must accept legacy `l=` senders can opt back in with verify({ acceptBodyLengthLimit: true }). ARC-Message-Signature verification, which reuses the same verifier, inherits the refusal unconditionally. **Security:** *DKIM verify refuses an l= signature with content appended past the signed octets* — The DKIM `l=` tag (RFC 6376 §3.5) limits the body hash to the first `l=` canonicalized octets, leaving any trailing body unsigned — the documented append-after-signature exposure (RFC 6376 §8.2). b.mail.dkim.verify hashed the prefix, matched `bh=`, and returned `pass` for the whole message, even though the recipient received appended content the signer never authenticated; the only signal was a warning string that b.mail.inbound.verify / dmarc.evaluate never inspected, so a forged trailer rode an aligned DMARC `pass`. verify now returns a body-hash `fail` when an `l=` signature leaves delivered body content beyond the signed octets (the framework already refuses `l=` at sign time). A signature whose `l=` covers the entire body still verifies; verify({ acceptBodyLengthLimit: true }) restores the prior accept-with-warning behavior for operators with legacy `l=` senders. · *ARC-Message-Signature verification inherits the same refusal* — ARC chain validation verifies each hop's ARC-Message-Signature through the same DKIM verifier, so an AMS carrying `l=` with appended content is now refused as a body-hash `fail` — failing the chain — rather than validating over a prefix. The ARC path does not expose the acceptBodyLengthLimit opt-out, so it is unconditionally fail-closed for an appended-content `l=`.
+
+- v0.15.52 (2026-06-28) — **An email address carrying more than one `@` is now refused instead of having its domain read from the wrong segment, closing a DMARC/SPF alignment bypass and an outbound mis-delivery path.** An RFC 5322 addr-spec has exactly one `@`, but blamejs derived the domain from a multi-@ address inconsistently across sites. For an inbound From like `user@attacker.example@victim.example`, the From-header parser took the RIGHTMOST `@` segment (victim.example) to gate DMARC and set the displayed author, while the DMARC and SPF evaluators re-derived the domain from the LEFTMOST segment (attacker.example) via split("@")[1]. So SPF/DMARC could authenticate a domain the attacker controls while the message displays the victim's domain — and the victim's `_dmarc` policy was never consulted, so a strict `p=reject` author domain could be impersonated. b.mail now refuses any From or MAIL FROM addr-spec with more than one `@` at every domain-derivation site (inbound From extraction, dmarc.evaluate, and spf.verify), and outbound delivery refuses a multi-@ recipient as a permanent bad-address rather than routing to the leftmost segment's MX. **Security:** *A multi-@ From address can no longer split DMARC/SPF alignment from the displayed author* — The inbound From-header parser derived the author domain from the rightmost `@` of a bare addr-spec, while dmarc.evaluate and spf.verify re-derived it from the leftmost `@` (split("@")[1]). A crafted From or MAIL FROM such as `user@attacker.example@victim.example` therefore authenticated attacker.example (which the attacker controls, with a permissive SPF/DMARC posture) while the displayed author was victim.example, whose `_dmarc` record was never queried — a DMARC alignment bypass (CWE-290) against any domain that publishes p=reject. An addr-spec has exactly one `@` (RFC 5322 §3.4.1); a From or MAIL FROM with more than one `@` is now treated as malformed at every derivation site (inbound From extraction yields no author domain and fails closed to reject; dmarc.evaluate and spf.verify refuse it), so the authenticated domain and the displayed domain can no longer diverge. · *Outbound delivery refuses a multi-@ recipient instead of routing to the wrong host* — Outbound SMTP delivery derived the recipient domain with split("@")[1], so a multi-@ recipient like `victim@internal.host@external.com` would have its MX looked up for the leftmost segment (internal.host) and the message routed there — a mis-delivery / exfiltration path when recipients are influenced by untrusted input. A recipient with more than one `@` is now refused as a permanent bad-address before any MX lookup. **Detectors:** *Leftmost-@ email-domain derivation must reject a multi-@ address* — A codebase-patterns detector flags any `str.split("@")[1]` email-domain derivation that is not preceded, within its function, by a single-@ rejection (`str.indexOf("@") !== str.lastIndexOf("@")`). This keeps the leftmost-vs-rightmost `@` divergence from being reintroduced at a new derivation site; a purely informational, non-routing use is marked inline.
+
+- v0.15.51 (2026-06-29) — **`b.guardOauth` and `b.session.verify` now fail closed when a backing store errors, instead of silently accepting a request whose security check could not be completed.** Two verifiers swallowed an error from a backing store and continued as if the check had passed. b.guardOauth's authorization-code replay defense wrapped the operator's seenCodeStore.hasSeen() call in a silent catch, so a store backend outage skipped the replay check entirely and a replayed authorization code was accepted — even though codeReusePolicy is reject at every profile. A store error now adds a high-severity oauth.code-reuse-unverifiable refusal, so the flow is denied (fail-closed) when reuse cannot be ruled out. b.session.verify enforces a device-fingerprint binding stored in the session's sealed data column; when that column could not be decrypted (key-rotation skew, database corruption, or a tamper of the independently-sealed cell) the failure was swallowed and the entire fingerprint gate — including requireFingerprintMatch and maxAnomalyScore — was skipped, so a strict-mode session was accepted from any device. An unreadable binding under a strict policy is now treated as a failure to prove the binding and the session is refused. **Security:** *OAuth authorization-code replay check fails closed on a store error* — b.guardOauth's code-reuse defense calls the operator-supplied seenCodeStore.hasSeen(code) to refuse a replayed authorization code (RFC 6749 §10.5). The call was wrapped in a drop-silent catch, so when the store backend errored (e.g. a Redis/DB outage) the exception was swallowed, no replay issue was raised, and the flow validated — accepting a code that could not be proven unused, despite codeReusePolicy being reject at every profile. A store error now raises a high-severity oauth.code-reuse-unverifiable issue, so the gate refuses the flow when reuse cannot be ruled out. · *Session verify fails closed when the device-fingerprint binding can't be decrypted* — b.session.verify stores the device-fingerprint binding inside the session's AEAD-sealed data column. When that column failed to decrypt or parse (key-rotation skew, database corruption, or a tamper of the separately-sealed cell), the failure was swallowed and the fingerprint gate was skipped entirely — so a session under a strict binding policy (requireFingerprintMatch:true or a maxAnomalyScore threshold) was accepted from any device, silently voiding the advertised drift-kills-the-session guarantee. A present-but-undecryptable binding column under a strict policy is now treated as a failure to prove the binding and the session is refused; sessions without a binding, and the default non-strict mode, are unchanged.
+
+- v0.15.50 (2026-06-28) — **`b.mail.bimi` closes a VMC certificate authorization bypass, and the host/origin comparisons in `b.ssrfGuard`, `b.middleware.csrfProtect`, and `b.mail.dmarc` now canonicalize both sides so case, trailing-dot, and IDN differences cannot decide a security check.** Four security and correctness decisions compared a host, origin, or domain where one side was normalized and the other was not, so two values that denote the same host in different encodings reached different verdicts. The most serious was in b.mail.bimi.fetchAndVerifyMark: when a VMC/CMC certificate's URI Subject Alternative Name could not be parsed as a URL (for example, a host carrying userinfo), the matcher fell back to a raw substring search of the whole SAN string — so a CA-chained certificate whose real host was attacker-controlled but whose SAN contained the victim domain anywhere (in the userinfo or path) was accepted to vouch for that victim domain. The fallback is removed (an unparseable URI SAN now fails closed) and both the certificate host and the BIMI domain are canonicalized before comparison. b.ssrfGuard allow/deny lists compared the operator's entries verbatim against the URL parser's already-lowercased host, so a mixed-case or trailing-dot deny entry silently failed to block its host; both sides now canonicalize through canonicalizeHost. b.middleware.csrfProtect canonicalized the candidate Origin via the URL parser but built the same-origin baseline by raw concatenation of the Host header, refusing a legitimate same-origin request whose Host was mixed-case or carried an explicit default port; the baseline and allowedOrigins now go through the same canonicalizer. b.mail.dmarc strict alignment compared the From and SPF/DKIM authentication domains with only case-folding, failing an aligned message whose authentication domain carried a trailing dot or an IDN label; both are now canonicalized the same way the relaxed path already was. A new b.publicSuffix.canonicalDomain primitive provides the shared encoding-stable host form. **Added:** *b.publicSuffix.canonicalDomain — encoding-stable host form* — Returns the bare canonical host form of a domain (lowercase, single trailing dot stripped, IDN labels as their A-label/punycode form) for identity comparison, without walking the public-suffix list. Two values that denote the same host in different encodings return the same string; an invalid or hostile host returns the empty string and matches nothing. It is the shared building block for the DMARC-alignment and certificate SAN authorization comparisons above. **Fixed:** *CSRF Origin check no longer refuses a legitimate same-origin request* — b.middleware.csrfProtect canonicalized the incoming Origin/Referer through the URL parser but built the same-origin baseline by concatenating the raw Host header, and compared allowedOrigins verbatim. A legitimate same-origin POST whose Host header was mixed-case or carried an explicit default port (:80/:443) was refused as cross-origin. The baseline and each allowedOrigins entry now pass through the same origin canonicalizer as the candidate. · *DMARC strict alignment canonicalizes the compared domains* — b.mail.dmarc strict alignment (aspf=s / adkim=s) compared the From domain against the SPF/DKIM authentication domain with only case-folding, while the relaxed path already normalized via the public-suffix lookup. An aligned message whose authentication domain carried a trailing dot or an IDN label was wrongly failed. Both domains are now canonicalized identically before the strict comparison. **Security:** *BIMI VMC certificate SubjectAltName authorization bypass closed* — b.mail.bimi.fetchAndVerifyMark binds a verified mark certificate to the BIMI domain via its Subject Alternative Name. When a URI SAN could not be parsed as a URL (e.g. a host with userinfo, or a malformed/homograph URI), the matcher fell back to a raw substring search of the entire SAN string, so a CA-chained certificate whose actual host was attacker-controlled — but whose SAN contained the victim domain as a substring (in the userinfo or path) — was accepted to vouch for the victim domain. The substring fallback is removed: a URI SAN the URL parser refuses now fails closed, and both the certificate host and the BIMI domain are canonicalized (lowercase, trailing-dot strip, IDN A-label) before an exact host comparison. · *SSRF allow/deny lists now match the host case-insensitively* — b.ssrfGuard.createAllowlist compared each operator allow/deny entry verbatim against the URL parser's host, which is already lowercased. A mixed-case or trailing-dot denylist entry therefore failed to match its own host and did not block it. Both the host and each non-CIDR entry now canonicalize through canonicalizeHost before comparison, so a denylisted host is blocked regardless of the case or trailing-dot form the operator wrote.
+
+- v0.15.49 (2026-06-28) — **`b.crypto.httpSig` now canonicalizes `@query-param` names and values per RFC 9421 §2.2.8, so its HTTP Message Signatures interoperate with conformant peers.** b.crypto.httpSig built the signature base for a @query-param component from the raw on-wire query bytes — the name was matched with encodeURIComponent and the value was emitted verbatim, with no decode-then-reencode. RFC 9421 §2.2.8 requires both the name and the value to be canonicalized: parsed as application/x-www-form-urlencoded (so a '+' and a %20 both become a space, and hex case is normalized) and then re-encoded, with a space rendered as %20. Because the framework signed and verified with the same raw bytes, blamejs-to-blamejs round-trips still worked, but a signature covering a query parameter whose name or value required encoding (a space, a '+', mixed or lowercase percent-encoding) did not match the base a conformant peer constructs — and an emitted identifier could even carry a literal space that the verifier then could not parse. Sign now emits the canonical percent-encoded name and signs the canonical value, and both sign and verify resolve the value through the same canonicalizer; the framework's base now matches the RFC's own published §2.2.8 example vectors. The whole-query @query component (§2.2.7), which the RFC defines as the raw encoded query, is unchanged, and signatures over plain-ASCII parameter names and values are byte-identical to before. **Fixed:** *HTTP Message Signatures @query-param canonicalization (RFC 9421 §2.2.8)* — b.crypto.httpSig now canonicalizes a @query-param component's name and value per RFC 9421 §2.2.8 — decode as application/x-www-form-urlencoded then re-encode, so a '+'-encoded space becomes %20, a %20 and a '+' resolve identically, and percent-encoding hex case is normalized to uppercase. Previously the name was matched with encodeURIComponent and the value was emitted raw, so a signature covering a query parameter that required encoding did not match the signature base a conformant RFC 9421 peer builds, and an emitted ;name="..." identifier could carry a literal space the verifier could not parse. Sign emits the canonical name and signs the canonical value; verify resolves the value through the same canonicalizer and reproduces the received identifier per §2.5. The framework's signature base now matches the RFC's published §2.2.8 example vectors. The whole-query @query component (§2.2.7) stays the raw encoded query, and signatures over plain-ASCII parameters are byte-identical to before.
+
+- v0.15.48 (2026-06-28) — **`b.network.dns.tsig` now accepts a message it signed with a non-default Original ID, fixing a sign/verify digest mismatch that made the originalId option non-functional (RFC 8945).** b.network.dns.tsig.verify restores the Original ID carried in the TSIG RDATA into the DNS message header before computing the HMAC, so a signed message survives an on-wire ID rewrite by a forwarder. b.network.dns.tsig.sign digested the message's current header ID instead of the Original ID, so any message signed with the originalId option set to a value other than the message's header ID produced a MAC the framework's own verify rejected (BADSIG) — the advertised originalId option was effectively non-functional for any non-default value. sign() now digests the Original-ID form, matching verify(); when originalId equals the message's header ID (the default) the digest is byte-for-byte identical to before, so existing signatures and the reference vectors are unaffected. **Fixed:** *TSIG: a message signed with a non-default Original ID now verifies (RFC 8945)* — b.network.dns.tsig.verify restores the Original ID carried in the TSIG RDATA into the DNS message header before computing the HMAC, so a signed message survives an on-wire ID rewrite by a forwarder. b.network.dns.tsig.sign digested the message's current header ID instead of the Original ID, so any message signed with the originalId option set to a value other than the message's header ID produced a MAC the framework's own verify rejected (BADSIG). sign() now digests the Original-ID form, matching verify(); when originalId equals the message's header ID (the default) the digest is byte-for-byte identical to before, so existing signatures and the reference vectors are unaffected.
+
+- v0.15.47 (2026-06-28) — **`b.mail.arc.verify` now returns chainStatus=pass for a cryptographically valid ARC chain — three defects in the ARC-Message-Signature verification path that made every real chain fail are fixed.** ARC-Message-Signature (AMS) verification reuses the DKIM verifier against a synthetic message, and three independent defects in that seam caused b.mail.arc.verify to reject every cryptographically valid ARC chain — its own and those from upstream relays. First, the AMS i= tag is an RFC 8617 instance number (1..50), not a DKIM Agent/User Identifier, but it was run through the RFC 6376 §3.5 AUID-must-be-a-subdomain-of-d= check, which permerrored every chain. Second, the synthetic renames the AMS header to DKIM-Signature so the DKIM verifier can find it, but the signature header was then canonicalized under that renamed field name instead of ARC-Message-Signature, so the b= signature never matched what the relay signed. Third, when sealing hop i>=2 the signer canonicalized a prior hop's ARC-Authentication-Results into the AMS instead of the current hop's, so multi-hop chains failed verification past the first hop. All three are fixed: arc.verify now confirms valid single- and multi-hop chains as cv=pass. The RFC 6376 §3.5 AUID/d= binding check remains a non-opt-out default on the public b.mail.dkim.verify path — the ARC reuse signal that skips it is framework-internal and cannot be set through the public options. **Fixed:** *ARC chain verification now succeeds for valid chains (it previously failed every one)* — b.mail.arc.verify reused the DKIM verifier to check each ARC-Message-Signature, and three defects in that path made it reject all cryptographically valid ARC chains. (1) The AMS i= instance number (RFC 8617 §4.1.2) was treated as a DKIM AUID and rejected by the RFC 6376 §3.5 AUID/d= binding check (permerror). (2) The synthetic message renames the AMS header to DKIM-Signature so the verifier can locate it, but the signature header was canonicalized under the renamed name rather than ARC-Message-Signature, so the b= value could never match the relay's signature. (3) For hops at instance 2 and beyond, b.mail.arc.sign canonicalized a prior hop's ARC-Authentication-Results into the AMS rather than the current hop's, breaking verification past the first hop. arc.verify now returns chainStatus=pass for valid single- and multi-hop chains; the DKIM AUID check stays enforced on the public DKIM verify path.
+
+- v0.15.46 (2026-06-28) — **`b.auth.fidoMds3` now enforces basicConstraints cA:TRUE on every intermediate link of the MDS3 x5c chain, closing a bypass where a non-CA certificate spliced in as an intermediate could sign a forged FIDO metadata BLOB that fido-mds3 accepted.** fido-mds3's x5c chain validation checked each intermediate link with X509Certificate.checkIssued(), which validates the issuer/subject linkage and signature but does NOT enforce the basicConstraints CA bit; only the final tail-to-root anchor used the framework's cA-enforcing helper. An attacker holding a non-CA (cA:FALSE) end-entity certificate that legitimately chains to a trusted MDS3 root (and its private key) could splice it in as an intermediate, sign a forged leaf with it, and have fido-mds3 accept an attacker-authored MDS3 metadata BLOB as authentic — the classic basicConstraints bypass (CVE-2002-0862 class). Every intermediate link now routes through x509Chain.issuerValidlyIssued, which enforces basicConstraints cA:TRUE in addition to the issuance and signature linkage, matching the mdoc / tsa / bimi / content-credentials / S-MIME chain walkers. A codebase guard now fails the build if any chain walker uses a bare issuance checkIssued() instead. **Security:** *fido-mds3 x5c intermediate links enforce the CA bit (basicConstraints bypass closed)* — b.auth.fidoMds3 validated each intermediate x5c link with X509Certificate.checkIssued(), which does not enforce basicConstraints cA:TRUE, so a non-CA certificate inserted as an intermediate was accepted as an issuer. An attacker with a cA:FALSE end-entity cert chaining to a trusted MDS3 root could sign a forged leaf and have a forged FIDO metadata BLOB accepted as authentic (CVE-2002-0862 class). Each intermediate link now routes through x509Chain.issuerValidlyIssued (cA:TRUE + issuance + signature), the same hardened test the framework's other certificate-chain walkers already use. The default GlobalSign MDS3 root and operator-supplied caCertificate roots are both covered. **Detectors:** *Build guard: a cert-chain issuance link must use issuerValidlyIssued, not bare checkIssued* — A codebase guard now fails the build if a certificate-chain walker validates an issuance link with a bare X509Certificate.checkIssued() (which omits the basicConstraints CA check) instead of x509Chain.issuerValidlyIssued, so the basicConstraints bypass cannot reappear at a new walker. A self-signed-root check (cert.checkIssued(cert)) is not an issuance link and is unaffected.
+
+- v0.15.45 (2026-06-28) — **`b.selfUpdate.swap` now re-hashes the asset against the hash `verify` returned and refuses to install on a mismatch, closing the window where an asset swapped between verify and swap could be installed after the signature check passed.** selfUpdate.verify (signature-checks the asset and returns its hash) and selfUpdate.swap (renames the new asset into place) were two separate path-keyed operations with nothing binding the bytes swap installs to the bytes verify checked. An attacker able to write the asset path in the window between the two calls — or who pointed verify at a different inode via a symlink — could have the signature-verified bytes replaced before swap renamed the file into place, installing unverified code. swap now requires an expectedHash and re-hashes the from bytes against it immediately before the install, refusing with selfupdate/swap-hash-mismatch on any difference; the re-check runs right before the rename so the residual is a sub-millisecond window rather than the operator-controlled gap between verify and swap. Because swap now requires expectedHash, callers must pass the hash that verify returned (await verify(...) then swap({ ..., expectedHash: result.hash })). **Security:** *self-update install is bound to the signature-verified bytes (verify→swap TOCTOU closed)* — selfUpdate.swap renamed the new asset into place with no integrity re-check, so the bytes it installed were not bound to the bytes selfUpdate.verify had signature-checked: an attacker who could write the asset path between verify and swap (or repoint a symlink) could install unverified code. swap now re-hashes the from bytes against a required expectedHash (the hash verify returns) immediately before the install and refuses a mismatch (selfupdate/swap-hash-mismatch), with the check positioned right before the rename to minimize the residual window. A symlinked or differing-inode asset is caught the same way, because the install source is what gets re-hashed. **Migration:** *selfUpdate.swap requires expectedHash* — swap now requires an expectedHash option (refused at the call with selfupdate/bad-expected-hash if absent). Pass the hash that selfUpdate.verify returns: const v = await selfUpdate.verify({ assetPath, signaturePath, pubkeyPem }); await selfUpdate.swap({ from, to, backupTo, expectedHash: v.hash }). An optional hashAlgo (default sha3-512, matching verify's default) selects the digest when verify used a non-default algorithm.
+
+- v0.15.44 (2026-06-28) — **`b.fileUpload` now rejects the bare path tokens "." and ".." as upload IDs, closing a path traversal where a ".." id resolved to the staging directory's parent and a cancel or cleanup could recursively delete it.** b.fileUpload validated the uploadId with a character-class regex that permits the dot character, so the bare path tokens "." and ".." passed validation even though they are not ordinary identifiers. The uploadId is joined under the configured staging directory to locate an upload's files, so "." resolved to the staging directory itself and ".." to its parent: an operation keyed on a ".." uploadId acted OUTSIDE the staging directory. The most damaging path is cancelUpload (and finalize/expiry cleanup), which removes the upload directory with a recursive rmSync — keyed on ".." that would recursively delete the staging directory's parent; chunk writes for a ".." id also land outside staging. The validator now rejects "." and ".." before any filesystem operation. Every public method validates the uploadId there, so init, acceptChunk, finalize, status, and cancelUpload are all covered, and legitimate dotted IDs (for example "build.v2") are unaffected. **Security:** *Upload IDs of "." and ".." are refused (path-traversal / parent-directory deletion)* — fileUpload's uploadId regex allows the dot character, so the bare tokens "." and ".." passed validation and, joined under the staging directory, resolved to the staging directory or its parent. An operation keyed on a ".." id acted outside staging — most seriously cancelUpload / cleanup, whose recursive rmSync would have deleted the staging directory's parent, and chunk writes that would land outside staging. The validator now rejects "." and ".." up front; because every public method validates the id, init / acceptChunk / finalize / status / cancelUpload are all covered. Legitimate dotted IDs are unaffected. Operators who never pass caller-controlled upload IDs were not exposed.
+
+- v0.15.43 (2026-06-28) — **`b.auth.lockout`'s failed-attempt counter now accumulates with an atomic compare-and-set, so a brute-force attacker spreading failed logins across multiple nodes can no longer lose increments and stay under the lockout threshold.** b.auth.lockout tracked failed attempts with a cache read-modify-write: read the counter, increment it, write it back. On a multi-node deployment two concurrent failures for the same account on different nodes both read the same value, each added one, and one write clobbered the other — a lost update that let an attacker spreading attempts across nodes exceed maxAttempts without ever triggering the lockout, weakening brute-force protection on a cluster. The counter now runs the whole decision (window decay, increment, lockout-ladder) through the cache's atomic update() (compare-and-set, retried on the cluster backend under contention), so every failure is counted regardless of which node records it. The lockout's documented fail-open posture is preserved — a genuinely unreachable cache still allows the attempt and signals the error — but a cache backend that cannot perform an atomic update now surfaces loud at first use instead of silently disabling the lockout. **Security:** *Lockout failure counter is atomic across nodes (no lost increments)* — b.auth.lockout accumulated failed attempts with a non-atomic cache get -> increment -> set, so concurrent failures for one account across a multi-node deployment lost increments and an attacker could exceed maxAttempts without engaging the lockout. The counter now uses the cache's atomic compare-and-set update(), counting every failure across nodes, with the existing exponential lockout ladder and window-decay logic unchanged. The cache backing a lockout must support atomic update() (b.cache does; the create() check now requires it), and a backend that can't commit an atomic update surfaces loud at first use rather than silently disabling brute-force protection. A genuinely unreachable cache still fails open by design.
+
+- v0.15.42 (2026-06-28) — **The agent orchestrator and tenant registries serialize registration per name, so two concurrent register() calls for the same name can no longer both create a row (duplicate-create / lost registration), and a new b.safeAsync.keyedSerializer exposes that per-key serialization.** b.agent.orchestrator and b.agent.tenant registered a name with a check-then-create: read the backend row for the name, throw a duplicate error if it exists, otherwise write the new row. Because the read and the write are separated by an await, two concurrent register() calls for the same name both observed absence and both wrote — a duplicate-create where the second silently clobbered the first and both callers saw success, violating the one-row-per-name invariant. register() (and unregister()) now run through a per-name in-process serializer, so concurrent calls for the same name apply one at a time and the second is correctly refused as a duplicate; distinct names still run concurrently. The serializer is exposed as b.safeAsync.keyedSerializer() for any read-modify-write or check-then-create that must not interleave per key. It is in-process only: a registry backend shared across processes still needs its own atomic create or unique constraint to refuse a cross-process duplicate. **Added:** *b.safeAsync.keyedSerializer — serialize async work per key* — b.safeAsync.keyedSerializer() returns a { run(key, fn) } that queues fn behind any in-flight or queued work for the same key and runs it once they settle, so a read-modify-write or a check-then-create on a shared store cannot interleave with another call for the same key in the same process. Distinct keys run concurrently, and the per-key chain is dropped once it drains. It is the serialization the agent registries now use, and the same primitive backs the lockout and bot-challenge per-key failure counters. **Fixed:** *Agent orchestrator + tenant registries serialize registration per name (no duplicate-create race)* — b.agent.orchestrator.register and b.agent.tenant.register did a check-then-create (await backend.get -> throw-if-exists -> await backend.set) with an await between the read and the write, so two concurrent registrations of the same name both passed the duplicate check and both wrote — the second silently clobbering the first while both callers saw success. Registration now serializes per name in-process, so concurrent calls for one name apply sequentially and the second is refused with the duplicate error; distinct names are unaffected. A backend shared across processes still needs its own uniqueness constraint to refuse a cross-process duplicate. **Detectors:** *Build guard: a registry check-then-create must serialize per key* — A codebase guard now fails the build if a primitive does an async check-then-create on a pluggable backend (await backend.get -> throw a /duplicate error -> await backend.set) without serializing per key, so the duplicate-create race fixed here cannot reappear at a new registry.
+
+- v0.15.41 (2026-06-28) — **Counters kept on a shared cache — byte quotas and the static server's bandwidth/concurrency caps — now accumulate with an atomic compare-and-set, so concurrent requests can no longer lose each other's charges and slip under the limit.** Several caps maintained a counter on a cache with a non-atomic read-modify-write: read the current value, add to it in memory, write it back. On a cache shared across nodes, two concurrent requests both read the same value, each added only its own contribution, and one write clobbered the other — a lost update that under-counted the cap and let a peer slip under it. b.network.byteQuota (and the b.middleware.dailyByteQuota that composes it) and the static server's per-actor/global bandwidth and per-actor concurrency caps all did this. They now accumulate through the cache's atomic update() (compare-and-set, with retry on the cluster backend under contention), so every concurrent charge is counted. A cache backing these caps must support atomic update(); b.cache provides it, and both primitives refuse a get/set-only cache at construction. The single-node in-memory paths were already safe (they accumulate synchronously). **Fixed:** *Byte quota on a shared cache counts concurrent requests atomically (no lost updates)* — b.network.byteQuota's cache backend accumulated bytes with a get → add → set that is not atomic, so concurrent requests from one peer on a multi-node deployment lost each other's byte charges and the rolling daily byte budget was under-enforced. Accounting now uses the cache's atomic compare-and-set update(), counting every concurrent request, and retries the cluster CAS under a contention burst rather than dropping a charge. A cache wired to a byte quota must support update() — b.cache does; a plain get/set cache is refused at create() (byte-quota/cache-no-atomic-update), and a backend that can't actually commit an atomic update surfaces loud on first use instead of silently disabling the quota. b.middleware.dailyByteQuota, which composes byteQuota, inherits the fix. · *Static server bandwidth + concurrency caps count concurrent requests atomically* — b.staticServe's per-actor and global bandwidth caps and its per-actor concurrency cap kept their counters on the cache with a non-atomic get → add → set, so concurrent downloads from one actor on a multi-replica deployment lost each other's charges and the caps were under-enforced (a bandwidth/concurrency limit bypass). The counters now accumulate through the cache's atomic update() with the same contention retry, and the quota cache is required to support update() at create(). **Detectors:** *Build guard: a cache-backed counter must use atomic update(), not get → set* — A codebase guard now fails the build if a primitive accumulates a counter on a cache with a get → mutate → set read-modify-write instead of the atomic update(), so the lost-update class fixed here cannot reappear at a new cap. Caches used for lookups or cache-aside (the value is replaced wholesale, not incremented), or whose writes are serialized in-process, are allowlisted with the reason they cannot lose an increment.
+
+- v0.15.40 (2026-06-27) — **The durable webhook dispatcher's retry poller now claims due deliveries with FOR UPDATE SKIP LOCKED on Postgres and MySQL, so two pollers running at once (multiple app nodes) can no longer both grab the same delivery and send the webhook twice in one cycle.** The webhook dispatcher's retry poller claimed due deliveries by flipping them pending->in-flight and then re-selecting the in-flight rows by id. On Postgres or MySQL under the default READ COMMITTED isolation, two pollers running concurrently could both re-select the same row: the loser's UPDATE matched zero rows (the winner had already flipped it), but its reselect-by-id still re-read the row the winner had just claimed, so both pollers attempted the same HTTP delivery in one cycle. The claim now row-locks the due rows with SELECT ... FOR UPDATE SKIP LOCKED on the row-locking backends, so concurrent pollers see disjoint sets and each delivery is claimed by exactly one poller; sqlite (a single writer) keeps the existing mark-then-reselect, which it serializes safely. This matches the claim used by the framework's transactional outbox and cluster queue. Receivers that already dedup on the X-Webhook-Delivery-Id header were protected from a duplicate POST; this closes the at-most-once-per-cycle gap at the dispatcher itself. **Fixed:** *Webhook retry pollers no longer double-deliver under concurrency on Postgres / MySQL* — b.webhook.dispatcher's processRetries() claimed due deliveries with a mark-then-reselect that had no row lock, so on Postgres / MySQL at READ COMMITTED two concurrent pollers (for example, the dispatcher running on more than one app node) could both hand back the same delivery and POST it twice in a single retry cycle. The claim now uses SELECT ... FOR UPDATE SKIP LOCKED on those backends so each due row is locked by exactly one poller and concurrent pollers claim disjoint sets; the rows a poller selects are exactly the rows it owns. sqlite keeps the mark-then-reselect path, which its single writer serializes. Operators running the dispatcher on a single node, or whose receivers dedup on X-Webhook-Delivery-Id, were not exposed to a duplicate delivery; no configuration change is required to pick up the fix. **Detectors:** *Build guard: a competing-consumer claim must use FOR UPDATE SKIP LOCKED* — A codebase guard now fails the build if a poller that claims due rows across workers — SELECT status='pending' inside a transaction, then flip the rows to in-flight — omits FOR UPDATE SKIP LOCKED on the row-locking backends. Without the row lock, two pollers under READ COMMITTED both claim the same row; the guard keeps any future poller from re-introducing the shape, with the transactional outbox and cluster queue as the reference claims.
+
+- v0.15.39 (2026-06-27) — **Nine more places that matched an operator-supplied regex against request data — User-Agent, Origin, request path, form fields, SMTP HELO, release-asset names — now screen the pattern for catastrophic backtracking (ReDoS) before use, and a new b.guardRegex.assertSafe helper makes that screening one call.** The previous release screened feature-flag and MCP regex patterns for ReDoS but did not sweep every place the framework matches an operator-supplied regex against attacker-controlled input. Nine more were found and fixed: the bot guard (User-Agent), CORS (Origin), the HTTP span middleware and the shared request skip-matcher used by CSRF / fetch-metadata / rate-limit / access-lock / age-gate and the request logger (request path), static serving (hashed-asset path pattern), form field validation (submitted field value), SMTP HELO generic-rDNS patterns (HELO name), and the self-updater's asset/signature patterns (names from a remote release feed). Each accepted an operator RegExp with only a type check and ran it on every matching request, so an accidentally catastrophic pattern such as (a+)+$ or ((a)+)+$ could pin a CPU on a crafted input — a length cap does not bound backtracking. Every one now screens the pattern through b.guardRegex at configuration time. A new b.guardRegex.assertSafe(input, label?, ErrorClass?, code?) primitive performs that screen in one call (accepting a RegExp or a pattern string), which operators can also use on their own patterns. **Added:** *b.guardRegex.assertSafe — screen a RegExp or pattern string for ReDoS in one call* — b.guardRegex.assertSafe(input, label?, ErrorClass?, code?, opts?) screens an already-compiled RegExp (its source) or a raw pattern string for the catastrophic-backtracking classes — nested, alternation-with, and lookaround quantifiers — throwing the supplied framework-error class (or the underlying GuardRegexError) on a hostile pattern and returning the input on success. It allows large or open-ended bounded repeats (`{8,}`, `{n,m}`): a single counted repeat matches in linear time and legitimate patterns (including the framework's own defaults) use them. It is the config-time guard used by the request-lifecycle fixes above, and operators can apply it to their own patterns before matching them against untrusted input. **Security:** *Operator regex patterns matched against request data are screened for ReDoS framework-wide* — An operator-supplied RegExp matched against attacker-controllable input is a denial-of-service surface if it has a catastrophic-backtracking shape: the input triggers exponential work in the regex engine. Nine sites accepted such patterns with only an `instanceof RegExp` type check and executed them per request — bot-guard against the User-Agent, CORS against the Origin header, the HTTP span middleware and the shared skip-path matcher (CSRF / fetch-metadata / rate-limit / access-lock / age-gate / request-log) against the request path, static serving against the request path, form validation against the submitted field value, SMTP HELO checks against the HELO name, and the self-updater against asset names from a remote release feed. Each now routes the pattern through b.guardRegex at configuration time, so a catastrophic shape is refused up front instead of being weaponized by a crafted request. A length bound on the input is not a defense: a nested-quantifier pattern backtracks catastrophically at a few dozen characters. **Detectors:** *Build guard: an operator regex matched against request input must be ReDoS-screened* — A codebase guard now fails the build if a primitive accepts an operator-supplied RegExp and executes it against request input without screening the pattern through b.guardRegex.assertSafe — so the catastrophic-backtracking class fixed in this release cannot be reintroduced at a new site (the trusted-input cases — local filesystem paths, operator config keys, operator-owned schemas — are explicitly allowlisted). · *Build guard: process.moduleLoadList filters must match the 'NativeModule X' naming* — A guard now fails the build if a test filters process.moduleLoadList by the 'node:X' name only. Node 20+ records a loaded builtin as 'NativeModule X', so a 'node:'-only filter in an edge-runtime no-eager-load test would rot green and miss a reintroduced top-level networking require.
+
 - v0.15.38 (2026-06-27) — **Regex patterns supplied in feature-flag targeting rules and MCP tool input schemas are now screened for catastrophic-backtracking (ReDoS) shapes before compilation, so a pattern matched against request data can't pin a CPU.** Two places compiled a caller-supplied regex pattern and `.test()`'d it against request-controlled input with only a length bound as the stated defense: a feature-flag targeting condition (`op: "regex"`) matched against runtime attribute values, and an MCP tool's input-schema `pattern` matched against tool-call arguments. A length bound is not a ReDoS defense — a catastrophic-backtracking pattern such as `(a+)+$` is six characters and pins a CPU on a crafted input. Both patterns now pass through `b.guardRegex` (strict profile) before compilation, which refuses nested-quantifier, alternation-with-quantifier, and quantifier-inside-lookaround shapes. A ReDoS-shaped flag pattern is refused when the rules are validated; a ReDoS-shaped MCP schema pattern fails tool-input validation. Patterns built from the framework's own static tables, operator-owned JSON Schema patterns, the Sieve glob translator (which cannot express nested quantifiers), and the I-Regexp translator (linear by dialect) are unchanged. **Security:** *Feature-flag regex targeting conditions are screened for ReDoS before compilation* — A flag targeting rule with `op: "regex"` compiled the operator-supplied pattern and `.test()`'d it against runtime attribute values, guarded only by a 200-character length cap. Length does not bound catastrophic backtracking, so a pattern like `(a+)+$` combined with an attacker-controlled attribute value could pin a CPU during flag evaluation. The pattern is now screened through b.guardRegex (strict) when the rules are validated, and a catastrophic-backtracking shape is refused with a clear error. · *MCP tool input-schema patterns are screened for ReDoS before matching request input* — b.mcp.validateToolInput compiled a tool author's input-schema `pattern` and matched it against tool-call argument values; the 4096-character input cap does not bound backtracking (a `(a+)+$` pattern blows up at roughly forty input characters). The schema pattern is now screened through b.guardRegex (strict) before compilation, so a ReDoS-shaped pattern in a registered tool's schema fails input validation instead of letting hostile arguments hang the validator. · *b.guardRegex now catches wrapped nested-quantifier patterns* — The nested-quantifier detector matched a quantified group whose body contained a quantifier, but its inner match was paren-blind, so wrapping the inner quantifier in an extra group — `((a)+)+`, `(([a-z]+)*)*`, `((a+))+` — slipped past it while remaining catastrophic. A structural scan now tracks group nesting and refuses an unbounded-quantified group whose body itself contains an unbounded quantifier at any depth, so the wrapped forms are rejected alongside the bare `(a+)+`. Bounded repeats (`{n}`, `{n,m}`) are unaffected. This strengthens every b.guardRegex caller, including the flag-targeting and MCP screening above.
 
 - v0.15.37 (2026-06-27) — **Several numeric options that silently accepted a non-finite value — disabling a clock-skew / freshness check or a resource cap — now reject it, so an `Infinity` skew or limit can no longer turn off the protection it configures.** A number of configuration options validated a numeric value with a bare `typeof === "number" && value >= 0` check, which accepts `Infinity`. Where the value is a clock-skew tolerance or a resource cap, an `Infinity` (or `NaN`) silently disabled the very check it tunes: a CWT / OCSP-staple / ARC clock-skew of `Infinity` made the expiry, freshness, and expiration comparisons unsatisfiable (an expired token / a replayed pre-revocation "good" response / an expired ARC seal would be accepted); a WebSocket-client `maxMessageBytes` / `maxFrameBytes` / `handshakeTimeoutMs` of `Infinity` disabled the inbound-OOM and stalled-handshake defenses; and inbox / flag-cache / audit-chain size and count caps of `Infinity` admitted unbounded data. These options now route through the finite-bounds validator: a present non-finite value is refused at the entry point (or falls back to the safe default on the result-returning paths). Options where an unbounded value is a deliberate intent — reconnect "retry indefinitely", inbox "retain indefinitely" — continue to accept `Infinity`. **Security:** *A non-finite clock-skew no longer disables CWT / OCSP / ARC time checks* — b.cwt.verify, the OCSP-staple freshness check in b.network.tls, and b.mail.arc.verify each took an operator clock-skew tolerance validated as `typeof === "number" && >= 0`, which accepts `Infinity`. Because each check is of the form `now > deadline + skew`, a skew of `Infinity` made it unsatisfiable and silently turned the check off: an expired CWT verified, a stale (post-nextUpdate) OCSP "good" response — the exact reply an attacker replays after the certificate is revoked — was accepted, and an expired ARC seal passed. A present clock-skew that is not a non-negative finite integer is now refused (b.cwt.verify throws cwt/bad-clock-skew; the OCSP and ARC paths fall back to their safe default). Regression tests assert an expired token / stale staple / expired ARC seal is still rejected when the skew is `Infinity`. · *WebSocket-client inbound caps can no longer be disabled by an Infinity value* — b.wsClient.connect validated maxMessageBytes, maxFrameBytes, and handshakeTimeoutMs (and the ping/pong keepalive intervals) with a bare numeric check that accepted `Infinity`, which disabled the inbound-message and frame size limits — the defenses against a malicious server sending an unbounded message — and the handshake timeout. A present non-finite value for these is now refused at connect time. The reconnect maxAttempts still accepts `Infinity` (a deliberate "reconnect indefinitely" intent). · *Inbox, flag-cache, and audit-chain caps reject a non-finite limit* — The inbox maxPayloadBytes / messageIdMaxLen / sourceMaxLen caps, the flag-cache ttlMs / maxEntries, and the audit-chain partition fan-out cap each accepted `Infinity`, disabling the cap (unbounded stored payloads, a never-expiring or unbounded cache, unbounded fan-out). These now require a positive finite integer — refused at create time, or clamped to the bounded default on the result-returning verify path. The inbox retentionDays still accepts `Infinity` (retain indefinitely).

package/lib/vendor/blamejs/CONTRIBUTING.md

@@ -98,6 +98,15 @@ A new framework primitive lands with at least layer-0 tests. New middleware land
 
 The smoke target is `OK — N checks passed` ending with a count higher than the previous release. New operator-facing routes / primitives add their own checks to `examples/wiki/test/e2e.js`.
 
+## Developer Certificate of Origin (DCO)
+
+Contributions are accepted under the [Developer Certificate of Origin](https://developercertificate.org/).
+By adding a `Signed-off-by` line to each commit you certify that you wrote the
+patch — or otherwise have the right to submit it — under the project's Apache-2.0
+license. Sign off with `git commit -s` (which appends
+`Signed-off-by: Your Name <you@example.com>`); the sign-off must match the commit
+author. Releases are cut with sign-off through `scripts/release.js`.
+
 ## The PR loop
 
 1. **Open an issue first** for non-trivial work — design discussion catches scope problems before code is written. Trivial fixes (typos, doc tweaks, single-line bug fixes) can skip the issue.
@@ -121,6 +130,13 @@ The smoke target is `OK — N checks passed` ending with a count higher than the
 
 ## What to contribute
 
+**New here?** Issues labeled [`good first issue`](https://github.com/blamejs/blamejs/labels/good%20first%20issue)
+are deliberately scoped small and self-contained — a doc or wiki-example fix, a
+test for an uncovered branch, an error message that could better say what to do
+next. They're the best on-ramp: pick one, comment that you're taking it, and open
+a PR per the loop above. If none fit, the areas below are all newcomer-friendly at
+their smaller end.
+
 Good contribution areas, ordered by current need:
 
 1. **Operator ergonomics** — wiki docs gaps, DEPLOY.md improvements, CLI verb usability, error messages that don't say what to do next.

package/lib/vendor/blamejs/README.md

@@ -13,6 +13,7 @@ One install. One upgrade path. One place to look when something breaks — no bl
 [![CI](https://img.shields.io/github/actions/workflow/status/blamejs/blamejs/ci.yml?branch=main&label=CI)](https://github.com/blamejs/blamejs/actions/workflows/ci.yml)
 [![release](https://img.shields.io/github/v/release/blamejs/blamejs?include_prereleases&sort=semver)](https://github.com/blamejs/blamejs/releases)
 [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/blamejs/blamejs/badge)](https://scorecard.dev/viewer/?uri=github.com/blamejs/blamejs)
+[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13471/badge)](https://www.bestpractices.dev/projects/13471)
 [![SLSA Level 3](https://slsa.dev/images/gh-badge-level3.svg)](https://slsa.dev)
 [![License: Apache 2.0](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](https://www.apache.org/licenses/LICENSE-2.0)
 [![node](https://img.shields.io/node/v/@blamejs/core.svg)](https://nodejs.org)
@@ -52,7 +53,7 @@ var b = require("@blamejs/core");
 })();
 ```
 
-**Requirements:** Node.js 24.16+ (current active LTS line; 24.14.1 fixed CVE-2026-21713 non-constant-time HMAC compare, 24.16 is the current patch level). Node 26 satisfies the floor and the framework test suite runs cleanly on it today; the floor itself will bump to `>=26.x` when Node 26 promotes to Active LTS. Two Node 26 platform changes operators integrating with blamejs should know about: the new `localStorage` global (the framework's storage backend is `b.backup.diskStorage`; the legacy `b.backup.localStorage` alias was removed in v0.11.20 — update call sites accordingly), and the seed-only ML-KEM / ML-DSA PKCS8 export shape (sealed material from Node 24 re-imports cleanly on Node 26; new material from Node 26 in the seed-only shape). See [SECURITY.md](SECURITY.md#node-26-compatibility) for the details.
+**Requirements:** Node.js 24.18+ (current active LTS line; 24.14.1 fixed CVE-2026-21713 non-constant-time HMAC compare, 24.18 is the current patch level). Node 26 satisfies the floor and the framework test suite runs cleanly on it today; the floor itself will bump to `>=26.x` when Node 26 promotes to Active LTS. Two Node 26 platform changes operators integrating with blamejs should know about: the new `localStorage` global (the framework's storage backend is `b.backup.diskStorage`; the legacy `b.backup.localStorage` alias was removed in v0.11.20 — update call sites accordingly), and the seed-only ML-KEM / ML-DSA PKCS8 export shape (sealed material from Node 24 re-imports cleanly on Node 26; new material from Node 26 in the seed-only shape). See [SECURITY.md](SECURITY.md#node-26-compatibility) for the details.
 
 ## What ships in the box
 

package/lib/vendor/blamejs/ROADMAP.md

@@ -0,0 +1,51 @@
+# Roadmap
+
+This is the high-level direction for blamejs over roughly the next year. It
+describes intent, not a dated commitment; specifics land in
+[CHANGELOG.md](CHANGELOG.md) as they ship and in the issue tracker as they are
+scoped. The stability guarantees in [SECURITY.md](SECURITY.md) and the support
+windows in [LTS-CALENDAR.md](LTS-CALENDAR.md) govern anything below.
+
+## Direction
+
+- **Toward 1.0 — API stabilization.** Continue hardening the public surface
+  toward a 1.0 that carries a stable-upgrade guarantee. Until 1.0, minors remain
+  additive and deprecations ship at least one minor before removal; breaking
+  changes are batched into a major with a prior deprecation minor.
+- **Continuous security hardening.** The ongoing correctness-and-hardening pass
+  over every primitive continues as the primary cadence — each release closes
+  audited gaps with a reproducing test and, where structural, a codebase-pattern
+  detector. Findings from CodeQL, OpenSSF Scorecard, ClusterFuzzLite fuzzing, and
+  coordinated disclosure are folded in on the timelines in SECURITY.md.
+- **Post-quantum completion.** Keep the crypto stack PQC-first (ML-KEM, ML-DSA,
+  SLH-DSA, XChaCha20-Poly1305, SHAKE256/SHA3, HKDF-SHA3, Argon2id). Track the
+  NIST/IETF PQC standards surface and adopt native platform PQC where it reaches
+  proven byte-parity with the vendored implementations without breaking existing
+  key material.
+- **Node LTS tracking.** Raise the minimum engine as Node LTS lines advance
+  (currently `>=24.18`), adopting stabilized platform capabilities (native PQC,
+  `node:sqlite`, native WebSocket) only when they reach parity with what the
+  framework already ships and without regressing the security defaults.
+- **Supply-chain assurance.** Maintain SLSA L3 provenance, Sigstore-signed SBOMs,
+  SSH-signed releases, pinned CI actions and Docker digests, and the vendored
+  dependency review discipline. Keep the OpenSSF Scorecard and Best Practices
+  posture current.
+
+## Explicitly out of scope
+
+- **Classical-only cryptographic defaults** (no AES-GCM / SHA-256 / P-256-ECDH
+  as defaults; PQC-first only).
+- **npm runtime dependencies** (everything ships vendored under `lib/vendor/`;
+  the runtime dependency count stays zero).
+- **A build/transpile step for the framework itself** (it runs on Node LTS
+  as-shipped; CommonJS, no TypeScript).
+- **Silent breaking changes in a minor** (the stable-upgrade policy is a hard
+  constraint, not an aspiration).
+- **Opt-in security** (CSRF / origin / bot-guard / sealed storage / encrypted
+  session / fetch-metadata / cookie prefixes / DoH / Trusted Types stay wired
+  into the request lifecycle by default, never behind flags).
+
+## How to influence it
+
+Open an issue or a pull request. Security-sensitive direction is best raised
+privately first per the process in [SECURITY.md](SECURITY.md).

package/lib/vendor/blamejs/SECURITY.md

@@ -228,6 +228,56 @@ What blamejs does **not** defend against (operator responsibility):
 
 ---
 
+## Assurance case
+
+This is blamejs's assurance case — the argument, backed by evidence, that the
+framework meets its security requirements (in the sense of NIST IR 7608). The top
+claim is decomposed into sub-claims, each supported by the design and by
+verifiable evidence.
+
+**Top claim.** A blamejs deployment, run with defaults, resists the threats in
+the [Threat model](#threat-model) above and does not silently degrade its
+security posture.
+
+- **Sub-claim 1 — the security defaults are actually on.** CSRF, origin /
+  fetch-metadata, bot-guard, sealed storage, encrypted session, cookie prefixes,
+  Trusted Types, strict CSP, and the SSRF guard are wired into the request
+  lifecycle, not behind config flags. *Evidence:* the smoke suite asserts each
+  default fires; any change that trips a security default is fixed in the test,
+  never by weakening the default.
+- **Sub-claim 2 — the cryptography is post-quantum and misuse-resistant.** No
+  classical-only defaults; every sealed/signed envelope is algorithm-tagged so a
+  substitution fails the AEAD/verify check; keys and RNG come from audited
+  implementations. *Evidence:* the [Cryptographic stack](#cryptographic-stack)
+  section; known-answer tests on the crypto primitives; algorithm agility
+  exercised by round-trip tests.
+- **Sub-claim 3 — untrusted input cannot crash or subvert a parser.** Every
+  `safe-*` / `guard-*` primitive validates adversarial input and is fuzzed.
+  *Evidence:* ClusterFuzzLite per-PR + daily fuzzing with a regression corpus,
+  and a coverage gate that refuses any new parser primitive without a fuzz
+  harness.
+- **Sub-claim 4 — defects are caught before release and fixed at the root.**
+  Every bug fix lands with a reproducing test (RED-before-fix) and, where
+  structural, a detector; CI runs the full suite plus CodeQL, Semgrep,
+  OSV-Scanner, gitleaks, and OpenSSF Scorecard on every change across three
+  platforms. *Evidence:* the [CI workflow](.github/workflows/ci.yml); the
+  23,000+ smoke assertions; the OpenSSF Scorecard and Best Practices badges.
+- **Sub-claim 5 — what ships is what was reviewed.** Releases carry SLSA L3
+  provenance, Sigstore-signed SBOMs, npm provenance, and SSH-signed tags; the
+  supply chain (vendored deps, CI actions, Docker bases) is hash/digest-pinned
+  and integrity-checked at boot. *Evidence:*
+  [Verifying release authenticity](#verifying-release-authenticity);
+  `b.configDrift.verifyVendorIntegrity` at boot; the pinned-dependency gates.
+
+**Residual risk.** The items under "does not defend against" above are explicit
+operator responsibilities (vault-passphrase strength, host/root compromise,
+network-layer DoS, reverse-proxy CVEs). The project is solo-maintained, so
+review-by-a-second-person is a known gap tracked in
+[GOVERNANCE.md](GOVERNANCE.md); it is compensated by the automated gates above
+until a second maintainer is onboarded.
+
+---
+
 ## Cryptographic stack
 
 | Layer | Algorithm | Standard |
@@ -464,6 +514,7 @@ CVE classes the framework tracks but does not currently ship a primitive for —
 - **HTTP/2 WINDOW_UPDATE rate-flood variants** — CVE-2026-21714 closes the leak-after-GOAWAY shape; the broader rate-flood class (peer bursting WINDOW_UPDATE to spin nghttp2 flow-control accounting) remains an active research area. The framework's H/2 server caps `maxConcurrentStreams` / `maxSessionMemory` / `maxHeaderListPairs` plus a per-stream WINDOW_UPDATE rate cap; operators on Internet-facing deployments add upstream rate-limiting at the edge.
 - **Glassworm Unicode in audit-log readers** — log-readers that render audit-row metadata as a string in a terminal can be tricked by bidi / zero-width / homoglyph characters in operator-supplied reasons. The framework's `b.redact` strips the dangerous classes from emitted audit rows; operators building custom log viewers route the rendered string through `b.guardHtml` (HTML viewer) or `b.guardCsv` (CSV exporter) before display.
 - **picomatch / minimatch ReDoS class** — the framework does not vendor a glob library; the only glob-shaped match in `lib/` is the bounded subscription matcher in `b.pubsub` (`_MAX_CHANNEL_LEN` cap before regex compile). Operators vendoring a glob library separately must cap input length and apply a regex-evaluation budget (CVE-2026-26996 / CVE-2026-33671 / CVE-2026-27904 class).
+- **Operator regex matched against request input** — every framework primitive that accepts an operator-supplied `RegExp` and runs it against attacker-controllable data (bot-guard `User-Agent`, CORS `Origin`, the request-path skip matchers, static-serve path patterns, form-field patterns, SMTP HELO patterns, self-update asset names) screens the pattern through `b.guardRegex` at configuration time, refusing catastrophic-backtracking shapes before they can be weaponized — a length bound on the input does not stop backtracking. Operators matching their **own** regex against untrusted input (a custom router, allow-list, or content filter) should screen it the same way with `b.guardRegex.assertSafe(re)`.
 - **AdonisJS multipart-filename → arbitrary-write class** — the framework's `b.fileUpload` routes every multipart filename through `b.guardFilename.gate({ profile: "strict" })` by default (path traversal / null-byte / NTFS ADS / UNC / overlong UTF-8 / Windows reserved names / RTLO bidi). Operators implementing a parallel multipart receiver outside the framework's primitive must wire the same gate.
 - **fs.realpath symlink-chain Permission Model bypass class** — see "Operator territory" entry above; the framework's symlink defenses live at the application layer (`b.vault` PEM-file read-side + `b.staticServe` realpath gate); operators using Node's experimental Permission Model add it as defense-in-depth, never as the primary symlink-resolution boundary.
 - **QUIC / HTTP/3 outbound (RFC 9000 / RFC 9001)** — the framework's `b.httpClient` is HTTP/1.1 + HTTP/2 only. QUIC + HTTP/3 are deferred-with-condition: re-open when Node's `--experimental-quic` flag graduates to stable and `node:http3` ships. Until then, operators wanting outbound h3 wire their own client outside the framework (see `lib/http-client.js` header note on the future `kind: "h3"` transport shape). The framework's TLS 1.3 + h2 anti-amplification + flow-control caps remain in force on every other transport. Inbound h3 is similarly deferred; operators terminating h3 at the edge route h2 / h1 to the framework's `b.router`.
@@ -472,7 +523,7 @@ CVE classes the framework tracks but does not currently ship a primitive for —
 
 ## Node 26 compatibility
 
-Today's `engines.node` floor is `>=24.16.0` and the release container pins `node:24-alpine`. Node 26 satisfies the floor and the framework's test suite runs cleanly on Node 26 today. When Node 26 promotes to Active LTS (target Oct 2026), the framework will bump the floor to `>=26.x` in a dedicated release that ships the queued refactors (Map.getOrInsertComputed sweep, Ed25519 context-parameter adoption, PKCS8 reverse-direction roundtrip test) as one PR.
+Today's `engines.node` floor is `>=24.18.0` and the release container pins `node:24-alpine`. Node 26 satisfies the floor and the framework's test suite runs cleanly on Node 26 today. When Node 26 promotes to Active LTS (target Oct 2026), the framework will bump the floor to `>=26.x` in a dedicated release that ships the queued refactors (Map.getOrInsertComputed sweep, Ed25519 context-parameter adoption, PKCS8 reverse-direction roundtrip test) as one PR.
 
 Two Node 26 platform-level changes operators integrating with blamejs should be aware of now:
 

package/lib/vendor/blamejs/api-snapshot.json

@@ -1,7 +1,7 @@
 {
   "version": 1,
-  "frameworkVersion": "0.15.38",
-  "createdAt": "2026-06-27T15:30:08.749Z",
+  "frameworkVersion": "0.16.2",
+  "createdAt": "2026-07-03T12:18:24.287Z",
   "exports": {
     "a2a": {
       "type": "object",
@@ -33331,6 +33331,10 @@
             }
           }
         },
+        "assertSafe": {
+          "type": "function",
+          "arity": 5
+        },
         "buildProfile": {
           "type": "function",
           "arity": 1
@@ -48947,6 +48951,10 @@
     "publicSuffix": {
       "type": "object",
       "members": {
+        "canonicalDomain": {
+          "type": "function",
+          "arity": 1
+        },
         "isPublicSuffix": {
           "type": "function",
           "arity": 1
@@ -49778,6 +49786,10 @@
           "type": "function",
           "arity": 3
         },
+        "keyedSerializer": {
+          "type": "function",
+          "arity": 0
+        },
         "makeBatchDrain": {
           "type": "function",
           "arity": 1
@@ -49879,6 +49891,10 @@
           "type": "instance",
           "ctorName": "RegExp"
         },
+        "assertHeaderSafe": {
+          "type": "function",
+          "arity": 4
+        },
         "boundedChunkCollector": {
           "type": "function",
           "arity": 1
@@ -49891,6 +49907,10 @@
           "type": "function",
           "arity": 2
         },
+        "foldHeaderText": {
+          "type": "function",
+          "arity": 2
+        },
         "hasCrlf": {
           "type": "function",
           "arity": 1

package/lib/vendor/blamejs/bench/_helpers.js

@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
 "use strict";
 // bench/_helpers.js — small benchmark harness using node:perf_hooks.
 // No npm deps. Deliberately simple: one-shot benches + percentile latency

package/lib/vendor/blamejs/bench/crypto-hash.bench.js

@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
 "use strict";
 // bench crypto.sha3Hash on small + medium + large inputs.
 

package/lib/vendor/blamejs/bench/crypto-symmetric.bench.js

@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
 "use strict";
 // bench symmetric XChaCha20-Poly1305 round-trip via crypto.encryptPacked /
 // decryptPacked. This is the hot path the vault.seal call lands on after

package/lib/vendor/blamejs/bench/run.js

@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
 "use strict";
 // bench/run.js — discovers bench/*.bench.js files, runs every entry,
 // emits a flat JSON record to bench/baseline.json (or --out <path>).

package/lib/vendor/blamejs/bench/safe-json.bench.js

@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
 "use strict";
 // bench safe-json — stringify + parse for a small + medium payload.
 

package/lib/vendor/blamejs/bin/blamejs.js

@@ -1,4 +1,6 @@
 #!/usr/bin/env node
+// SPDX-License-Identifier: Apache-2.0
+// Copyright (c) blamejs contributors
 "use strict";
 // Thin entrypoint — all dispatch logic lives in lib/cli.js so it can
 // be driven from tests without spawning a child process.