@blamejs/core 0.15.50 → 0.15.52

package/CHANGELOG.md

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

package/lib/guard-oauth.js

@@ -296,7 +296,18 @@ function _detectIssues(flow, opts) {
                    "(RFC 6749 §10.5)",
         });
       }
-    } catch (_e) { /* drop-silent — operator-supplied store */ }
+    } catch (_e) {
+      // A replay-store error means we cannot prove the authorization code is
+      // unused — that is a denial, not "the code is fresh". codeReusePolicy is
+      // "reject" at every profile, so the replay check is unconditional: fail
+      // CLOSED with a high-severity refusal rather than silently skipping it.
+      issues.push({
+        kind: "code-reuse-unverifiable", severity: "high",
+        ruleId: "oauth.code-reuse-unverifiable",
+        snippet: "replay store (seenCodeStore.hasSeen) errored — cannot prove " +
+                 "the authorization code is unused; refusing (fail-closed, RFC 6749 §10.5)",
+      });
+    }
   }
 
   return issues;

package/lib/mail-auth.js

@@ -807,8 +807,24 @@ async function spfVerify(opts) {
     throw new MailAuthError("mail-auth/spf-bad-ip",
       "spf.verify: ip must be a string");
   }
+  var mailFromStr = opts.mailFrom ? String(opts.mailFrom) : "";
+  // A MAIL FROM addr-spec has exactly one '@' (RFC 5322 §3.4.1). split("@")[1]
+  // on a multi-@ string takes the LEFTMOST segment, so the SPF check would
+  // authorize a domain the attacker controls rather than the envelope sender's
+  // real domain (CWE-290). A multi-@ MAIL FROM is malformed — return a permanent
+  // SPF error (a RESULT, not a throw). spfVerify runs inside b.mail.inbound.verify,
+  // whose contract is that message-derived faults surface as a permerror/temperror
+  // verdict, never a throw: a throw here is caught by mail-server-mx as a pipeline
+  // temperror, which onTemperror:"accept" would let through — skipping SPF/DMARC
+  // gating for the spoofed From. Returning permerror (domain null → SPF cannot
+  // align) keeps the pipeline running so DMARC still gates the From header.
+  if (mailFromStr && mailFromStr.indexOf("@") !== mailFromStr.lastIndexOf("@")) {
+    return { result: "permerror", domain: null,
+             explanation: "mailFrom has more than one '@' (not a valid addr-spec)",
+             lookupCount: 0 };
+  }
   var domain = opts.mailFrom
-    ? String(opts.mailFrom).split("@")[1]
+    ? mailFromStr.split("@")[1]
     : opts.helo;
   if (typeof domain !== "string" || domain.length === 0) {
     throw new MailAuthError("mail-auth/spf-bad-domain",
@@ -1209,6 +1225,15 @@ async function dmarcEvaluate(opts) {
     throw new MailAuthError("mail-auth/dmarc-bad-from",
       "dmarc.evaluate: opts.from must be the From-header email address");
   }
+  // An addr-spec has exactly one '@' (RFC 5322 §3.4.1). split("@")[1] on a
+  // multi-@ string (x@attacker@victim) silently takes the LEFTMOST segment
+  // (attacker), which can diverge from the rightmost-@ domain the inbound From
+  // parser gated on — so DMARC would authorize a different domain than the one
+  // displayed. Refuse a multi-@ From as malformed (CWE-290).
+  if (opts.from.indexOf("@") !== opts.from.lastIndexOf("@")) {
+    throw new MailAuthError("mail-auth/dmarc-bad-from",
+      "dmarc.evaluate: opts.from has more than one '@' (not a valid addr-spec)");
+  }
   var fromDomain = opts.from.split("@")[1];
   if (!fromDomain) {
     throw new MailAuthError("mail-auth/dmarc-bad-from",
@@ -2253,6 +2278,14 @@ function _extractFromHeaders(headerBlock) {
     // not a single bare addr-spec.
     if (/[\s,;:<>]/.test(address)) address = null;
   }
+  // An RFC 5322 addr-spec has EXACTLY ONE '@' (local-part "@" domain). A second
+  // '@' (x@attacker@victim) is malformed: the rightmost-@ derivation below reads
+  // victim as the author domain, while a downstream leftmost-@ parser
+  // (dmarc.evaluate's split("@")[1]) reads attacker — so DMARC could authorize a
+  // domain the attacker controls while the displayed From is the victim's
+  // (CWE-290). Treat any address with more than one '@' as unparsable so the
+  // caller fails closed (permerror → reject).
+  if (address && address.indexOf("@") !== address.lastIndexOf("@")) address = null;
   var at = address ? address.lastIndexOf("@") : -1;
   var domain = (at > 0 && address && at < address.length - 1)
     ? address.slice(at + 1).toLowerCase()

package/lib/mail-send-deliver.js

@@ -143,6 +143,10 @@ function _buildDsnMessage(opts) {
     "--" + boundary + "\r\n" +
     "Content-Type: message/delivery-status\r\n" +
     "\r\n" +
+    // Reporting-MTA is an informational DSN header naming our own reporting MTA
+    // (it falls back to the bounce-from's domain); it drives no auth decision or
+    // delivery routing, so the leftmost-@ segment is acceptable here.
+    // allow:leftmost-domain-informational
     "Reporting-MTA: dns; " + (opts.reportingMta || from.split("@")[1] || "") + "\r\n" +
     "Arrival-Date: " + nowIso + "\r\n" +
     "\r\n" +
@@ -300,6 +304,15 @@ async function _tryHost(envelope, mxHost, hostnameLocal, opts) {
 }
 
 async function _deliverOne(envelope, recipient, ctx) {
+  // A recipient addr-spec has exactly one '@' (RFC 5322 §3.4.1). split("@")[1]
+  // on a multi-@ string (victim@internal.host@external.com) takes the LEFTMOST
+  // segment, so the MX lookup + delivery would route to a domain other than the
+  // intended one — a mis-delivery / exfiltration vector. Refuse a multi-@
+  // recipient as a permanent bad-address rather than route to the wrong host.
+  if (recipient.indexOf("@") !== recipient.lastIndexOf("@")) {
+    return { recipient: recipient, outcome: "permanent",
+             reason: "bad-address", reasonCode: "5.1.3" };
+  }
   var domain = recipient.split("@")[1];
   if (!domain) {
     return { recipient: recipient, outcome: "permanent",

package/lib/session.js

@@ -581,6 +581,12 @@ async function verify(token, verifyOpts) {
   var unsealed = cryptoField.unsealRow(SESSION_TABLE, row);
   var data = null;
   var storedFingerprint = null;
+  // The sealed `data` cell carries the device-fingerprint binding. A cell that
+  // EXISTS on the row but does not decrypt (key-rotation skew, DB corruption, or
+  // a tamper of the independently-AEAD-sealed column) means the binding is
+  // UNREADABLE — distinct from a session that legitimately carries no binding.
+  // Under a strict binding policy that must FAIL CLOSED below, not be skipped.
+  var bindingUnreadable = (row.data != null && row.data !== "" && unsealed.data == null);
   if (unsealed.data) {
     try {
       data = safeJson.parse(unsealed.data);
@@ -599,6 +605,7 @@ async function verify(token, verifyOpts) {
       // operator notices empty-`data` flows. data stays null so the
       // session remains usable for non-data flows.
       data = null;
+      bindingUnreadable = true;   // decrypted but unparseable — binding unreadable
       try {
         audit.safeEmit({
           action:   "auth.session.data_unparseable",
@@ -618,6 +625,21 @@ async function verify(token, verifyOpts) {
   // login-from-Tokyo-then-immediately-from-Brazil pattern is not).
   var fingerprintDrift = false;
   var fingerprintAnomalyScore = null;
+  // A strict binding policy (requireFingerprintMatch / maxAnomalyScore) cannot be
+  // satisfied when the binding is UNREADABLE — we can't prove it matches, so fail
+  // CLOSED rather than silently skipping the gate (the pre-fix fail-open).
+  if (bindingUnreadable && verifyOpts.req &&
+      (verifyOpts.requireFingerprintMatch === true ||
+       typeof verifyOpts.maxAnomalyScore === "number")) {
+    try {
+      audit.safeEmit({
+        action:   "auth.session.binding_unreadable",
+        outcome:  "failure",
+        metadata: { hasUserId: !!unsealed.userId },
+      });
+    } catch (_ig) { /* audit best-effort */ }
+    return null;
+  }
   if (storedFingerprint && verifyOpts.req) {
     var fpFields = Array.isArray(verifyOpts.fingerprintFields) && verifyOpts.fingerprintFields.length > 0
       ? verifyOpts.fingerprintFields : DEFAULT_FINGERPRINT_FIELDS;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.15.50",
+  "version": "0.15.52",
   "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:74c051d6-47fc-4a6b-a557-b70f7fd7afdf",
+  "serialNumber": "urn:uuid:3f2c8d09-0fb1-4038-bd9d-295c29932f8b",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-06-29T02:26:06.809Z",
+    "timestamp": "2026-06-29T05:28:59.150Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.15.50",
+      "bom-ref": "@blamejs/core@0.15.52",
       "type": "application",
       "name": "blamejs",
-      "version": "0.15.50",
+      "version": "0.15.52",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.15.50",
+      "purl": "pkg:npm/%40blamejs/core@0.15.52",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.15.50",
+      "ref": "@blamejs/core@0.15.52",
       "dependsOn": []
     }
   ]