@blamejs/core 0.15.52 → 0.15.53

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.15.x
 
+- 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.

package/lib/mail-dkim.js

@@ -751,6 +751,21 @@ function _verifySingleSignature(rfc822, parsedHeaders, sigHeader, keyTags, sigTa
   if (actualBh !== expectedBh) {
     return { result: "fail", errors: ["body hash mismatch"] };
   }
+  // RFC 6376 §8.2 — l= signs only the first lcap canonicalized octets, so any
+  // body delivered beyond lcap is UNSIGNED: the body hash above matched the
+  // prefix, but the recipient receives appended content the signer never
+  // authenticated (verified bytes ≠ delivered bytes, CWE-345). The framework
+  // already refuses l= at sign-time; on verify, a signature whose l= leaves
+  // appended content unsigned must not pass by default. An operator who must
+  // accept legacy l= senders opts in via verify({ acceptBodyLengthLimit: true }).
+  if (lcap !== undefined && !verifyOpts.acceptBodyLengthLimit) {
+    var fullCanon = canonBody === "simple" ? _canonBodySimple(body) : _canonBodyRelaxed(body);
+    if (lcap < Buffer.byteLength(fullCanon, "utf8")) {
+      return { result: "fail",
+               errors: ["DKIM-Signature l= leaves appended body content unsigned " +
+                        "(RFC 6376 §8.2 append-after-signature)"] };
+    }
+  }
 
   // 2. Canonicalize the headers in h= order, then the DKIM-Signature
   //    header itself with the b= value emptied (per §3.7).
@@ -876,7 +891,7 @@ async function verify(rfc822, opts) {
   }
   opts = opts || {};
   validateOpts(opts, ["dnsLookup", "audit", "clockSkewMs", "maxSignatures",
-                       "minRsaBits"], "mail.dkim.verify");
+                       "minRsaBits", "acceptBodyLengthLimit"], "mail.dkim.verify");
   var auditOn = opts.audit !== false;
 
   // Bounded clock skew: refuse non-numeric / negative / infinite /
@@ -918,7 +933,8 @@ async function verify(rfc822, opts) {
     }
     maxSignatures = Math.floor(opts.maxSignatures);
   }
-  var verifyOpts = { minRsaBits: opts.minRsaBits };
+  var verifyOpts = { minRsaBits: opts.minRsaBits,
+                     acceptBodyLengthLimit: opts.acceptBodyLengthLimit === true };
   // Framework-internal ARC reuse: the key is a Symbol owned by
   // mail-arc-reuse-token (exported from no public surface), so only framework
   // code that requires that module can set it. When present, the i= tag is an

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.15.52",
+  "version": "0.15.53",
   "description": "The Node framework that owns its stack.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:3f2c8d09-0fb1-4038-bd9d-295c29932f8b",
+  "serialNumber": "urn:uuid:3c37e813-c979-4c20-b8c7-3c496401d86c",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-06-29T05:28:59.150Z",
+    "timestamp": "2026-06-29T06:09:51.919Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.15.52",
+      "bom-ref": "@blamejs/core@0.15.53",
       "type": "application",
       "name": "blamejs",
-      "version": "0.15.52",
+      "version": "0.15.53",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.15.52",
+      "purl": "pkg:npm/%40blamejs/core@0.15.53",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.15.52",
+      "ref": "@blamejs/core@0.15.53",
       "dependsOn": []
     }
   ]