@blamejs/core 0.15.43 → 0.15.44

package/CHANGELOG.md

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

package/lib/file-upload.js

@@ -245,9 +245,16 @@ var UPLOAD_ID_RE = /^[A-Za-z0-9._-]+$/;
 var UPLOAD_ID_MAX_LENGTH = C.BYTES.bytes(128);
 
 function _validateUploadId(id) {
+  // The char-class allows '.', so the bare path tokens "." and ".." pass the
+  // regex; joined under stagingDir they resolve to the staging dir / its PARENT
+  // (path.join(stagingDir, "..") escapes), and a later rmSync would recurse into
+  // the parent. Reject them before any filesystem op — every public method
+  // validates the id here, so this guards init / acceptChunk / finalize /
+  // status / cancelUpload alike.
   if (typeof id !== "string" ||
       id.length === 0 ||
       id.length > UPLOAD_ID_MAX_LENGTH ||
+      id === "." || id === ".." ||
       !UPLOAD_ID_RE.test(id)) {
     var ID_PREVIEW_CHARS = C.BYTES.bytes(64);
     throw _err("BAD_UPLOAD_ID",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.15.43",
+  "version": "0.15.44",
   "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:bcd0c33c-a657-4ed3-b17c-eb1691a77bc5",
+  "serialNumber": "urn:uuid:bf9b0dcd-010c-4ef3-b922-fb94a9cb440b",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-06-28T11:16:40.494Z",
+    "timestamp": "2026-06-28T12:15:14.692Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.15.43",
+      "bom-ref": "@blamejs/core@0.15.44",
       "type": "application",
       "name": "blamejs",
-      "version": "0.15.43",
+      "version": "0.15.44",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.15.43",
+      "purl": "pkg:npm/%40blamejs/core@0.15.44",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.15.43",
+      "ref": "@blamejs/core@0.15.44",
       "dependsOn": []
     }
   ]