@blamejs/core 0.15.53 → 0.15.55

package/CHANGELOG.md

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

package/lib/auth/saml.js

@@ -2128,12 +2128,48 @@ async function fetchMdq(opts) {
   if (opts.trustCertPem) {
     var c14n = xmlC14n();
     var root = c14n.parse(xml);
-    var sig = _findChild(root, "Signature");
+    // The element the operator consumes is the document-root EntityDescriptor
+    // (fetchMdq queries a single entityID; an EntitiesDescriptor aggregate is
+    // not what a per-entity MDQ lookup returns). Refusing the wrapper closes the
+    // XML-signature-wrapping vector where a genuine federation signature over a
+    // buried entity is paired with a forged sibling/outer entity carrying the
+    // attacker's signing cert (CVE-2024-45409 class).
+    var rootColon = root.name.indexOf(":");
+    var rootLocal = rootColon !== -1 ? root.name.substring(rootColon + 1) : root.name;
+    if (rootLocal !== "EntityDescriptor") {
+      throw new AuthError("auth-saml/mdq-not-entity-descriptor",
+        "fetchMdq: metadata root must be a single EntityDescriptor, got " + rootLocal +
+        " (signature-wrapping defense)");
+    }
+    // Refuse a duplicate top-level Signature (XSW multi-signature shape), the
+    // way verifyResponse refuses duplicate security-critical children.
+    var sigChildren = _findAllChildren(root, "Signature", null);
+    if (sigChildren.length > 1) {
+      throw new AuthError("auth-saml/mdq-duplicate-signature",
+        "fetchMdq: EntityDescriptor has multiple Signature children (XSW shape refused)");
+    }
+    var sig = sigChildren[0] || null;
     if (!sig) {
       throw new AuthError("auth-saml/mdq-unsigned",
         "fetchMdq: metadata is unsigned but trustCertPem was supplied");
     }
-    _verifyXmldsig(xml, sig, opts.trustCertPem);
+    var signed = _verifyXmldsig(xml, sig, opts.trustCertPem);
+    // Bind the verified bytes to the consumed element: the federation signature
+    // MUST cover the document-root EntityDescriptor, not some inner element a
+    // wrapper buried beside a forged one. Mirrors verifyResponse's
+    // signed.refId === _attr(root/assertion, "ID") guard.
+    if (signed.refId !== _attr(root, "ID")) {
+      throw new AuthError("auth-saml/signed-different-element",
+        "fetchMdq: metadata signature references a different element than the " +
+        "EntityDescriptor root (signature-wrapping defense)");
+    }
+    // And the signed root must be the entity that was requested, so a signed
+    // descriptor for one entity cannot be served for another.
+    if (_attr(root, "entityID") !== opts.entityId) {
+      throw new AuthError("auth-saml/mdq-entity-mismatch",
+        "fetchMdq: signed EntityDescriptor entityID '" + _attr(root, "entityID") +
+        "' does not match requested '" + opts.entityId + "'");
+    }
   }
   _emitAudit("mdq_fetched", "success", { entityId: opts.entityId });
   _emitMetric("mdq-fetched");

package/lib/file-upload.js

@@ -129,9 +129,12 @@
  * Design posture:
  *
  *   - **init() before any chunk**: explicit lifecycle. Init records
- *     createdAt + actor + metadata + signing key in a per-upload sidecar
- *     so subsequent acceptChunk / finalize / status calls can authenticate
- *     and audit consistently.
+ *     createdAt + actor + metadata in a per-upload sidecar; the stored owner
+ *     (actor.id || actor.userId) is enforced on every subsequent acceptChunk /
+ *     finalize / status / cancelUpload call, so one actor cannot act on another
+ *     actor's upload by its uploadId. Operator admin tooling opts into
+ *     cross-actor access via allowCrossActor (default off) plus the
+ *     "fileUpload.admin" permission scope.
  *
  *   - **Framework owns chunk lifecycle**, not final storage. Operator
  *     decides via `onFinalize` what to do with the assembled buffer
@@ -305,6 +308,16 @@ function _validateCreateOpts(opts) {
       validateOpts.optionalObjectWithMethod(v, "check", label, FileUploadError, "BAD_OPT",
         "must be a b.permissions instance (check fn)");
     },
+    // allowCrossActor — escape hatch for operator admin tooling that must act on
+    // ANY actor's upload (ops dashboards, cleanup jobs). Default false: per-upload
+    // ownership is enforced so actor B cannot finalize / cancel / status /
+    // acceptChunk actor A's upload by guessing its uploadId. When true the
+    // ownership check is skipped; if a permissions instance is also wired the
+    // caller must additionally hold the "fileUpload.admin" scope, so cross-actor
+    // access stays gated.
+    allowCrossActor: function (v, label) {
+      validateOpts.optionalBoolean(v, label, FileUploadError, "BAD_OPT");
+    },
     // contentSafety — extension-keyed gate map for per-extension content
     // validation. Default behaviour: when undefined, the framework wires
     // b.guardAll.byExtension({ profile: "strict" }) automatically so every
@@ -383,6 +396,7 @@ function _validateCreateOpts(opts) {
  *   audit:                     b.audit,
  *   observability:             b.observability,
  *   permissions:               b.permissions,          // optional; gates init/accept/finalize/status/list/cancel
+ *   allowCrossActor:           boolean,                // default false; admin escape hatch — bypasses per-upload ownership when the caller holds the "fileUpload.admin" scope
  *   fileType:                  b.fileType,             // required when allowedFileTypes is non-empty
  *   contentSafety:             Object | null,          // ext→gate map; null = audited opt-out; undefined = b.guardAll.byExtension({ profile: "strict" })
  *   filenameSafety:            Object | null,          // gate; null = audited opt-out; undefined = b.guardFilename.gate({ profile: "strict" })
@@ -415,6 +429,7 @@ function create(opts) {
   var onChunk                 = opts.onChunk || null;
   var fileType                = opts.fileType || null;
   var permissions             = opts.permissions || null;
+  var allowCrossActor         = opts.allowCrossActor === true;
   // ---- Default-on safety wiring ----
   // contentSafety: undefined → wire b.guardAll.byExtension({ profile: "strict" })
   // contentSafety: null      → explicit opt-out, audit row emitted
@@ -547,6 +562,60 @@ function create(opts) {
     }
   }
 
+  // _checkOwnership — refuse when the calling actor does not own the upload.
+  // Owner identity is the same _actorKey derivation init() stored in
+  // meta.actorId (actor.id || actor.userId || "_anonymous"), so an anonymous
+  // upload is owned by "_anonymous" and a named actor cannot reach it (and vice
+  // versa) — fail-closed for the missing/legacy-meta case. The permission-scope
+  // check ("fileUpload.<op>") is a coarse capability ("may this actor finalize
+  // uploads AT ALL"); this is the per-resource authorization ("does this actor
+  // own THIS upload"). Both run on every lifecycle method, so one actor cannot
+  // act on another's upload by guessing its uploadId (IDOR / CWE-639).
+  //
+  // Escape hatch: allowCrossActor (create-time, default off) skips the ownership
+  // comparison for operator admin tooling; when permissions are also wired,
+  // "fileUpload.admin" is required so cross-actor access is itself gated.
+  function _checkOwnership(action, actor, meta) {
+    if (!meta) return;   // not-found is handled by the caller's own UNKNOWN_UPLOAD path
+    var callerKey = _actorKey(actor);
+    if (meta.actorId === callerKey) return;   // the owner always passes
+    // The caller is NOT the owner. Refuse unless the operator enabled
+    // cross-actor admin access at create() — and, when permissions are wired,
+    // the caller holds the "fileUpload.admin" scope (so the escape hatch is
+    // itself gated and a non-owner cannot ride allowCrossActor without it).
+    if (allowCrossActor) {
+      var adminOk = !permissions;   // scope-less single-tenant operator: allowCrossActor alone suffices
+      if (permissions) {
+        try { adminOk = permissions.check(actor, "fileUpload.admin"); }
+        catch (_e) { adminOk = false; }
+      }
+      if (adminOk) return;
+      _emitObs("fileUpload.permission_denied", 1, { action: "admin" });
+      _emitAudit("fileUpload." + action, {
+        actor:    requestHelpers.extractActorContext(actor),
+        resource: { kind: "fileUpload", id: meta.uploadId },
+        outcome:  "denied",
+        reason:   "cross-actor-admin-scope-required",
+        metadata: { uploadId: meta.uploadId, owner: meta.actorId,
+                    caller: callerKey, action: action },
+      });
+      throw _err("PERMISSION_DENIED",
+        "fileUpload." + action + ": cross-actor access requires scope 'fileUpload.admin'");
+    }
+    _emitObs("fileUpload.ownership_violation", 1, { action: action });
+    _emitAudit("fileUpload." + action, {
+      actor:    requestHelpers.extractActorContext(actor),
+      resource: { kind: "fileUpload", id: meta.uploadId },
+      outcome:  "denied",
+      reason:   "ownership-violation",
+      metadata: { uploadId: meta.uploadId, owner: meta.actorId,
+                  caller: callerKey, action: action },
+    });
+    throw _err("OWNERSHIP_VIOLATION",
+      "fileUpload." + action + ": actor does not own upload '" + meta.uploadId +
+      "' (ownership enforced; set allowCrossActor + 'fileUpload.admin' scope for admin tooling)");
+  }
+
   function _readReceivedIndices(uploadId) {
     var p = _receivedPath(uploadId);
     if (!nodeFs.existsSync(p)) return [];
@@ -699,6 +768,7 @@ function create(opts) {
       throw _err("UNKNOWN_UPLOAD",
         "fileUpload.acceptChunk: no init() seen for '" + uploadId + "'; call init() first");
     }
+    _checkOwnership("accept", actor, meta);
     if (clock() - meta.lastChunkAt > maxIdleMs) {
       // Idle-timed-out — too much time since init or last chunk.
       throw _err("UPLOAD_IDLE_EXPIRED",
@@ -991,6 +1061,7 @@ function create(opts) {
       throw _err("UNKNOWN_UPLOAD",
         "fileUpload.finalize: no init() seen for '" + uploadId + "'");
     }
+    _checkOwnership("finalize", actor, meta);
 
     _validateManifest(manifest);
 
@@ -1216,6 +1287,7 @@ function create(opts) {
     _checkPermission("status", callerOpts.actor);
     var meta = _readMeta(uploadId);
     if (!meta) return null;
+    _checkOwnership("status", callerOpts.actor, meta);
     var indices = _readReceivedIndices(uploadId).slice().sort(function (a, b) { return a - b; });
     return {
       uploadId:           uploadId,
@@ -1258,6 +1330,7 @@ function create(opts) {
     _checkPermission("cancel", callerOpts.actor);
     var meta = _readMeta(uploadId);
     if (!meta) return { ok: false, uploadId: uploadId, reason: "not-found" };
+    _checkOwnership("cancel", callerOpts.actor, meta);
     try { nodeFs.rmSync(_uploadDir(uploadId), { recursive: true, force: true }); }
     catch (_e) { /* best-effort */ }
     _emitObs("fileUpload.cancelled", 1);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.15.53",
+  "version": "0.15.55",
   "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:3c37e813-c979-4c20-b8c7-3c496401d86c",
+  "serialNumber": "urn:uuid:c04e6464-14f6-4e3e-9612-897f574eb1e2",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-06-29T06:09:51.919Z",
+    "timestamp": "2026-06-29T08:12:12.873Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.15.53",
+      "bom-ref": "@blamejs/core@0.15.55",
       "type": "application",
       "name": "blamejs",
-      "version": "0.15.53",
+      "version": "0.15.55",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.15.53",
+      "purl": "pkg:npm/%40blamejs/core@0.15.55",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.15.53",
+      "ref": "@blamejs/core@0.15.55",
       "dependsOn": []
     }
   ]