@blamejs/core 0.17.1 → 0.17.2

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.17.x
 
+- v0.17.2 (2026-07-17) — **Recurrence expansion refuses to spin or crash on an out-of-range interval, the CIDR guard rejects the whole of the ULA and link-local IPv6 ranges, and a device-bound session assertion no longer accepts a far-future issued-at.** b.calendar.expandRecurrence accepted an unbounded, unvalidated recurrence interval; a large interval drove its date arithmetic past the representable range, which either spun the expansion loop forever at full CPU (a denial of service reachable from any JSCalendar event in a request body) or threw an uncaught error that crashed the caller. The expander now stops as soon as the date arithmetic overflows. b.guardCidr tested IPv6 reserved-range membership on whole hex nibbles, so it missed the parts of the ULA (fc00::/7) and link-local (fe80::/10) ranges that do not fall on a nibble boundary -- accepting fd00::/8 and several fe80::/10 sub-ranges as clean under the strict profile that is supposed to refuse them. And b.dbsc.verifyBindingAssertion bounded the assertion's issued-at only from below, so a far-future issued-at was accepted and never aged out of the replay window. **Security:** *Recurrence expansion refuses an out-of-range interval instead of hanging or crashing* — b.calendar.expandRecurrence validated a recurrence rule's frequency but not its interval, so a caller-supplied interval was used unbounded. A large interval drives the expander's date arithmetic past the representable ECMAScript date range and yields a non-finite date, with two consequences from the one root: with a by-set-position rule the outer loop computed a non-finite period whose inner day-enumeration ran zero times, so the shared step budget never decremented and the not-after break comparisons (which compare against a non-finite value) never fired -- an infinite loop pinning a CPU at 100%; without by-set-position, the loop advanced to a non-finite date and threw an uncaught error when serializing it. Because the rule passed validation, any attacker supplying a JSCalendar event (a JMAP request body, an imported calendar) could trigger it. The expander now stops stepping as soon as the date arithmetic overflows the representable range -- no further instances can exist -- so a hostile interval yields the finite instances that fit and returns, rather than hanging or crashing. · *CIDR guard rejects the full ULA and link-local IPv6 ranges under the strict profile* — b.guardCidr tested whether an IPv6 address falls in a reserved range by comparing hex-nibble prefixes with a string prefix match. Reserved membership is a bit-prefix relation, and the unique-local (fc00::/7, 7 bits) and link-local (fe80::/10, 10 bits) ranges end mid-nibble, so the nibble comparison covered only fc00-fcff and fe80-fe8f -- it missed fd00::/8 (the half of the ULA block that real deployments actually assign) and the fe90::/16 through febf::/16 sub-ranges of link-local. Under the strict profile, which refuses reserved ranges, those CIDRs were accepted as clean and sanitize normalized them into place instead of refusing them. The reserved-range check now compares the whole nibbles and then the remaining prefix bits of the boundary nibble under a mask -- the same bit-prefix relation the IPv4 path and the SSRF guard already use -- so the entire reserved range is caught; nibble-aligned ranges (documentation, multicast, loopback) are unaffected. · *Device-bound session assertions reject a far-future issued-at* — b.dbsc.verifyBindingAssertion enforced the assertion's issued-at only as a lower bound (refusing one older than the configured max age), with no upper bound. A forward-dated issued-at makes the age check compare a negative interval, which never trips, so an assertion carrying an issued-at far in the future was accepted and could not age out of the replay window on the default 300-second path. verifyBindingAssertion now also refuses an issued-at more than a small clock-skew allowance in the future, matching the future-issued-at bound the JWT, DPoP, and client-attestation verifiers already enforce.
+
 - v0.17.1 (2026-07-17) — **Profile, posture, and capability name lookups across the content-safety and mail-protocol guards reject a prototype-member name instead of running under it, the mTLS CA can generate a CRL after a fingerprint-only revocation, and a hostile MIME filename no longer crashes attachment extraction.** A second family of guards resolved a profile, posture, or capability name against a plain-object lookup table with a truthiness or in-operator guard, so a name that is an inherited Object.prototype member (constructor, __proto__, toString) slipped the guard and the gate ran under the inherited member instead of refusing the unknown name. The shared profile resolver (b.gateContract.makeProfileResolver, which the guard family composes), the iCal and vCard content guards, the dark-patterns posture check, the JMAP capability allowlist, and the IMAP/POP3/ManageSieve command guards now all resolve names through an own-property check. Separately, b.mtlsCa.generateCrl crashed with a null-serial error once any certificate had been revoked by fingerprint (the mode the require-mTLS gate pins on), dropping every serial-keyed revocation from the published CRL; and b.safeMime.extractAttachments threw an uncaught URIError on a hostile Content-Disposition filename with a malformed percent-escape, crashing the caller. **Fixed:** *mTLS CA generates a CRL after a fingerprint-only revocation* — b.mtlsCa.revoke accepts a certificate fingerprint (the value the require-mTLS gate pins on and generateClientCert surfaces for exactly this use), which is stored without a serial number. b.mtlsCa.generateCrl then mapped the whole revocation registry into CRL entries and handed the null serial to the CRL encoder, which threw -- aborting CRL generation entirely. Because one fingerprint-only revocation broke every subsequent CRL build, all serial-keyed revocations were silently dropped from the published CRL and it could never be regenerated, going stale for external CRL-based revocation checking. generateCrl now projects out fingerprint-only entries (which a standard X.509 CRL cannot represent) before encoding and reports how many were omitted; fingerprint-only revocations remain enforced through the mTLS gate, and the CRL publishes every serial-keyed revocation. · *A hostile MIME filename no longer crashes attachment extraction* — b.safeMime.extractAttachments decoded an RFC 2231 / RFC 5987 extended filename parameter (filename*=charset''percent-encoded) with an unguarded percent-decode, so a malformed escape -- a truncated %, a non-hex %ZZ, or a sequence that decodes to invalid UTF-8 -- threw an uncaught URIError that escaped the parser's typed-error contract and crashed the caller (for example a mail store extracting attachments). A one-line hostile Content-Disposition header was a trivial denial of service. The decode now degrades to the still-encoded filename on failure, matching the framework's handling of every other percent-decode site, so a hostile filename yields a best-effort name that downstream filename guards still vet rather than a crash. **Security:** *Guard profile, posture, and capability lookups reject a prototype-member name* — A group of content-safety and mail-protocol guards resolved a caller- or request-supplied profile / posture / capability name against a plain-object lookup table using a truthiness check (var caps = TABLE[name]; if (!caps)) or the prototype-chain-aware in operator. A name that names an inherited Object.prototype member -- constructor, __proto__, toString -- is truthy (or present via the prototype chain), so it slipped the guard and the gate ran under the inherited member instead of refusing the unknown name. The shared resolver b.gateContract.makeProfileResolver (composed by the idempotency-key, mail-compose, message-id and other guards) now guards both its posture and profile lookups with hasOwnProperty; b.safeIcal, b.safeVcard, b.darkPatterns, b.guardJmap (capability allowlist and profile/posture), and the b.guardImapCommand / b.guardPop3Command / b.guardManageSieveCommand command guards do the same. An unknown or prototype-member name is now rejected with the guard's typed error; supported names are unaffected. This extends the same own-property hardening applied to the crypto algorithm-table lookups in 0.17.0 to the guard-family profile resolvers.
 
 - v0.17.0 (2026-07-17) — **Algorithm and key-type lookups across the crypto verifiers reject a prototype-member name instead of accepting it, the ZIP reader honors the operator's decompression-ratio policy, and signed S3/GCS query parameters transmit the space encoding they were signed with.** A family of verifiers resolved an algorithm, hash, or key-type name against a plain-object lookup table with a truthiness or `in`-operator guard, so a name that is an inherited Object.prototype member (constructor, __proto__, toString, valueOf) slipped the guard and resolved to the inherited member: b.jwk thumbprinted an attacker-crafted key to a predictable digest, b.vc and b.contentCredentials emitted a real signature under a bogus algorithm, and b.sdJwtVc accepted an attacker-controlled hash name from an unsigned issuer payload. All of them now reject a name that is not an own property of the table. Separately, b.archive's ZIP reader silently capped the decompression ratio at its composed default and ignored the operator's configured bomb policy, refusing legitimate highly-compressible entries; and b.storage's SigV4 (and the GCS V4 presigner) signed a query space as %20 but transmitted it as +, so a signed parameter carrying a space was rejected as a signature mismatch. **Fixed:** *ZIP extraction honors the operator's decompression-ratio policy* — b.archive's random-access ZIP reader composed b.safeDecompress for each DEFLATE entry without forwarding the reader's own expansion-ratio cap, so the decompression inherited safeDecompress's stricter default ratio and silently overrode the operator's configured bomb policy. A ZIP entry that legitimately compressed better than the default ratio (logs, JSON, telemetry, zero-padded or sparse binaries) was refused even when the operator's policy permitted it. The reader now forwards its configured maximum expansion ratio into the decode, so the actual-bytes ratio re-check uses the same cap the declared-size gate already enforced. · *Signed S3 and GCS query parameters transmit the space encoding they were signed with* — b.storage's SigV4 request signing (S3, R2, MinIO, and the S3-compatible backends) and the GCS V4 presigner sign the canonical query string, which encodes a space as %20 per the AWS/GCS specification, but transmitted the request via the WHATWG URL serializer, which encodes a space as +. A signed query parameter carrying a literal space -- a response-content-disposition filename or a list prefix -- was therefore signed over %20 but sent as +, so the storage server re-canonicalized to different bytes and rejected the request with a signature mismatch. The signer now aligns the wire query to the signed canonical encoding (rewriting a bare + back to %20) at each signing sink, so the transmitted query is byte-identical to what the signature commits to. **Security:** *Crypto algorithm and key-type lookups reject a prototype-member name* — Several verifiers resolved a caller- or attacker-supplied algorithm / hash / key-type name against a plain-object lookup table using a truthiness check (`var v = TABLE[name]; if (!v) reject`) or the prototype-chain-aware `in` operator. A name that names an inherited Object.prototype member -- constructor, __proto__, toString, valueOf, toLocaleString -- is truthy (or present via the prototype chain), so it slipped the guard and resolved to the inherited member. The observed consequences: b.jwk.thumbprint / canonicalize accepted an unsupported kty and thumbprinted the key to a single predictable digest; b.vc.issue (JOSE) and b.contentCredentials.signCose emitted a real signature under a bogus algorithm id; and b.sdJwtVc.present accepted an attacker-controlled _sd_alg read from the unsigned issuer payload. b.tsa and the SD-JWT hash-disclosure path returned a raw runtime error rather than a typed rejection. Every one of these table lookups now checks Object.prototype.hasOwnProperty before indexing, so a name that is not an own member of the table is rejected with the primitive's typed error. Supported algorithm and key-type names are unaffected.

package/lib/calendar.js

@@ -804,6 +804,11 @@ function _expandSingleRule(rule, startMs, ctx) {
       throw new CalendarError("calendar/bad-recurrence",
         "b.calendar.expandRecurrence: unsupported frequency '" + freq + "'");
     }
+    // The caller-supplied `interval` is unbounded; a large one drives
+    // _advance's Date arithmetic past the representable range, returning
+    // NaN. No further instances can exist — stop before the NaN reaches
+    // _msToIsoZ on the next iteration, which throws on an invalid Date.
+    if (!isFinite(t)) break;
   }
   return { instances: out, stepBudgetRemaining: ctx.stepBudgetRef.remaining };
 }
@@ -856,6 +861,14 @@ function _expandWithBysetpos(ctx) {
   while (out.length < count && out.length < maxCount && stepBudgetRef.remaining > 0) {
     var period = _periodForIndex(freq, startDate, periodIndex * interval);
     periodIndex += 1;
+    // A non-finite period means the FREQ interval (unbounded and
+    // caller-supplied) drove Date.UTC past the representable ECMAScript
+    // date range. No further instances can exist. This break is also
+    // load-bearing against a hang: a NaN period runs the day-enumeration
+    // loop zero times, so it never decrements the shared step budget,
+    // and the untilMs / toMs comparisons below are NaN no-ops (`NaN > x`
+    // is false) — without stopping here the outer loop spins forever.
+    if (!isFinite(period.startMs) || !isFinite(period.endMs)) break;
     // Out-of-window early exit. Window-uppper applies once the period
     // start crosses toMs; until applies once period-start crosses untilMs.
     if (period.startMs > untilMs) break;

package/lib/dbsc.js

@@ -47,6 +47,15 @@ var DbscError = defineClass("DbscError", { alwaysPermanent: true });
 
 var DEFAULT_CHALLENGE_TTL_MS = C.TIME.minutes(5);
 
+// Clock-skew allowance for a forward-dated `iat`. An assertion whose iat
+// sits further ahead than this is refused: without an upper bound a future
+// iat makes the stale check (Date.now() - iat*1000 > maxAge) permanently
+// false, so the assertion never expires and the maxAge replay window is
+// defeated. Mirrors the future-iat bound in b.auth.jwt.verifyExternal
+// (iat-future) and dpop's ±window; sized to tolerate ordinary client clock
+// drift without admitting a far-future token.
+var IAT_FUTURE_SKEW_MS = C.TIME.minutes(1);
+
 /**
  * @primitive b.dbsc.challenge
  * @signature b.dbsc.challenge(opts)
@@ -243,6 +252,14 @@ function verifyBindingAssertion(assertion, opts) {
     throw new DbscError("dbsc/stale",
       "verifyBindingAssertion: iat is more than " + opts.maxAgeSec + "s old");
   }
+  // Upper-bound iat: a forward-dated assertion (beyond IAT_FUTURE_SKEW_MS)
+  // is refused. A future iat makes the stale check above never fire, so the
+  // assertion would stay "fresh" indefinitely — a freshness fail-open on an
+  // attacker-chosen iat that defeats the maxAge replay bound.
+  if (typeof payloadJson.iat === "number" && payloadJson.iat * 1000 - Date.now() > IAT_FUTURE_SKEW_MS) {   // allow:raw-time-literal — sec→ms
+    throw new DbscError("dbsc/iat-future",
+      "verifyBindingAssertion: iat is more than " + (IAT_FUTURE_SKEW_MS / C.TIME.seconds(1)) + "s in the future");
+  }
   // Re-verify any embedded challenge if the assertion claims one.
   if (payloadJson.challenge) {
     verifyChallenge(payloadJson.challenge, { secretKey: opts.secretKey });

package/lib/guard-cidr.js

@@ -237,13 +237,34 @@ function _ipv4InReservedRange(octets, prefix) {
   return hits;
 }
 
+// Bit-accurate prefix match over two hex strings. Reserved-range membership
+// is a relation on the first `prefixBits` bits, NOT on a whole number of hex
+// nibbles: ULA fc00::/7 (7 bits) and link-local fe80::/10 (10 bits) end
+// mid-nibble, so a hex-string startsWith on the reserved nibbles silently
+// misses every address whose trailing (masked-off) bits differ — e.g. fd00::
+// (the assigned half of fc00::/7) and fe90::/fea0::/feb0:: (all inside
+// fe80::/10). Compare the whole nibbles, then the top `prefixBits % 4` bits of
+// the boundary nibble under a mask — the same bit-prefix relation the IPv4
+// side gets from `(addr & mask) === net` and ssrf-guard gets from its byte-
+// level `_ipv6PrefixMatch`.
+function _ipv6HexPrefixMatch(hex, reservedHex, prefixBits) {
+  var fullNibbles = Math.floor(prefixBits / 4);                                  // whole hex chars fully inside the prefix
+  if (hex.slice(0, fullNibbles) !== reservedHex.slice(0, fullNibbles)) return false;
+  var remBits = prefixBits - fullNibbles * 4;                                    // 0-3 bits in the boundary nibble
+  if (remBits === 0) return true;
+  var mask = (0xF << (4 - remBits)) & 0xF;                                       // high `remBits` bits of the nibble
+  var aNib = parseInt(hex.charAt(fullNibbles), 16);                              // base-16 radix
+  var rNib = parseInt(reservedHex.charAt(fullNibbles), 16);                      // base-16 radix
+  return (aNib & mask) === (rNib & mask);
+}
+
 function _ipv6InReservedRange(groups, prefix) {
   var hex = groups.join("");
   var hits = [];
   for (var i = 0; i < IPV6_RESERVED.length; i += 1) {
     var r = IPV6_RESERVED[i];
     if (prefix < r.prefix) continue;
-    if (hex.startsWith(r.hexPrefix)) hits.push(r.label);
+    if (_ipv6HexPrefixMatch(hex, r.hexPrefix, r.prefix)) hits.push(r.label);
   }
   return hits;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.17.1",
+  "version": "0.17.2",
   "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:04849b6a-ae7a-43f3-939a-e67a488f6a49",
+  "serialNumber": "urn:uuid:2d2edd9e-40b2-4d7d-8170-e9e03ba03685",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-07-17T08:07:44.038Z",
+    "timestamp": "2026-07-17T09:06:52.771Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.17.1",
+      "bom-ref": "@blamejs/core@0.17.2",
       "type": "application",
       "name": "blamejs",
-      "version": "0.17.1",
+      "version": "0.17.2",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.17.1",
+      "purl": "pkg:npm/%40blamejs/core@0.17.2",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.17.1",
+      "ref": "@blamejs/core@0.17.2",
       "dependsOn": []
     }
   ]