@blamejs/blamejs-shop 0.5.21 → 0.5.22

package/lib/vendor/blamejs/CHANGELOG.md

@@ -8,6 +8,38 @@ upgrading across more than a few patches at a time.
 
 ## v0.18.x
 
+- v0.18.24 (2026-08-11) — **A scheduler test waited for the wrong task, so a loaded machine could fail the release pipeline on a race in the test rather than a defect in the framework.** The suite covering scheduled-task success and failure registered two tasks — one that returns and one that throws — then waited for the aggregate counters to show a fire and an error before asserting that the succeeding task had actually run. Both counters are totals across tasks, so the throwing task alone satisfied the wait. On an unloaded machine the two first-fires land together and it never mattered; on a loaded CI runner they separate far enough that the wait returned while the succeeding task had not run yet, and the assertion failed.
+
+The wait now uses the same counter the assertion does. Nothing in the shipped framework changes; this is the release pipeline being made to fail only for real reasons. **Fixed:** *The scheduler suite waits for the task it asserts on* — `aggregate.totalFires` and `aggregate.withErrors` both count across every registered task, so a wait for "at least one fire and at least one error" is satisfied by a single failing task. The assertion that followed checked a counter incremented inside the succeeding task's body, which that wait says nothing about.
+
+This is the general shape worth naming: a poll-until-ready is only as good as the condition it polls, and a condition that is merely correlated with the assertion is a race waiting for a slow machine. The wait now polls the success counter itself, alongside the aggregate error count, so it cannot return before the thing being asserted is true.
+
+- v0.18.23 (2026-08-10) — **A Certificate Transparency consistency proof was checked against the new tree but not against the tree you pinned — unless your pinned size happened to be a power of two.** `b.network.tls.ct.verifyConsistency` answers one question: is the tree I pinned earlier still a prefix of the tree this log is showing me now? RFC 9162 §2.1.4.2 answers it by rebuilding BOTH roots from the proof — the first tree's and the second's — and requiring both to match what the operator holds. The implementation rebuilt only the second. The pinned root reached the computation solely as a seed in the branch taken when the first tree is a complete subtree, so for a pinned size of 4, 8 or 16 it was checked by accident, and for 3, 5, 6, 7, 9 and every other size it was not looked at at all. A proof describing an entirely different first tree of the same size verified.
+
+That is the whole premise of pinning, and it was being taken on trust. Both roots are now rebuilt and both are checked; a proof that does not connect to the pinned tree is refused with `first-root-mismatch`.
+
+Two smaller defects came out of the same work. A tree is consistent with itself and RFC 9162 says so with an empty proof, which the walk refused for any size that was not a power of two — so an operator re-checking an unchanged STH was told their log was inconsistent. And a proof carrying entries beyond the root was accepted with the remainder ignored, where the sibling inclusion-proof walk refuses exactly that. **Changed:** *Vendored `@blamejs/pki` 0.4.13 → 0.4.14* — The PKI toolkit behind `b.mtlsCa` now wipes every key-establishment secret it allocates once that secret stops being needed, classical as well as post-quantum, and reaches raw key material through a single path that clears the copy it hands out. A password supplied as a string or `Uint8Array` is encoded into a buffer the toolkit allocated — a credential copy — and that copy is cleared once the key derivation has consumed it; a caller-supplied `Buffer` is borrowed and left untouched. Public API behaviour is unchanged. **Fixed:** *A tree is consistent with itself* — RFC 9162 §2.1.4 gives the proof for two equal tree sizes as the empty list. The verification walk in §2.1.4.2 is written for a first tree strictly smaller than the second, and running it on equal sizes made it look for a sibling the definition says is not there — so it refused. Not always: for a power-of-two size the index bits shift down to zero on their own and the walk short-circuits, so the failure appeared at 3, 5, 6, 7, 9 and not at 4, 8, 16.
+
+An operator polling a log that has not grown since their last check got told the log was inconsistent, intermittently by tree size. A false alarm on a security check is worse than a quiet one, because it is the alarm that teaches you to ignore the alarm. Equal sizes now verify on an empty proof and refuse a non-empty one. · *A consistency proof must be fully consumed* — Entries past the point the walk stopped were ignored rather than refused, while the inclusion-proof walk beside it refuses an audit path with entries beyond the root. Nothing was forgeable through it — the computed root still had to match — but a proof carrying material the verifier never looked at is not the proof the operator believes was checked, and the two walkers disagreeing about what well-formed means is its own defect. Both now refuse a tail. **Security:** *The consistency proof must connect to the pinned first root* — A consistency check has two halves: the proof rebuilds the new tree's root, which must match the STH the log just served, and it rebuilds the old tree's root, which must match the STH the operator pinned. Only the first half was enforced.
+
+The pinned root was used as the walk's seed when the first tree happened to be a complete subtree — true exactly when the pinned size is a power of two — and in that case the final root comparison carried it along. At every other size the walk seeded from the proof itself and the supplied root was never read. A log could serve a proof for some other first tree of the same size and it verified; so did a pinned root of arbitrary bytes.
+
+The exposure is not that a log can forge a tree, but that pinning stopped detecting the thing it exists to detect: a log that quietly rewrote history before the point you pinned would still have passed, at 11 of the 16 first-sizes below 17. Both roots are now rebuilt per RFC 9162 §2.1.4.2 and both are checked, with a distinct `first-root-mismatch` reason so a proof that is well-formed but describes the wrong tree does not read as a malformed one. **Detectors:** *Merkle proofs are tested against real trees* — All three defects were reachable because the tests built their fixtures by hand: four-leaf trees with hand-picked sibling values. A four-leaf tree is a perfect binary tree, so it never takes the uneven split the algorithm turns on, and hand-picked values can be chosen to make the answer come out right without describing any tree at all — one fixture asserted the incomplete-subtree branch with a first root of thirty-two identical bytes, which is exactly the input the missing check would have caught.
+
+The suite now transcribes RFC 9162's recursive definitions separately from the framework's iterative walk, builds real trees, derives real proofs, and feeds every first-size/second-size pair up to seventeen leaves through the verifier before breaking them one way at a time. The two implementations share no structure, so agreement means something. A detector fires on a re-hand-rolled tree hash.
+
+- v0.18.22 (2026-08-10) — **An OCSP response that declared one signature algorithm and carried another was accepted — the field steering the digest was never checked against the key doing the verifying.** `b.network.tls.ocsp.evaluate` read the responder's `signatureAlgorithm` OID to pick a digest, then handed the bytes to `node:crypto`, which selects RSA or ECDSA from the KEY rather than from that field. A response declaring `sha256WithRSAEncryption` while carrying an ECDSA signature therefore verified, and so did the reverse.
+
+This is not a forgery path and was never exploitable: the issuer's private key is required either way, and a response signed by any other key is still refused. What it meant is that the declared algorithm and the algorithm actually verified were allowed to differ, with nothing in the result saying so. RFC 6960 §4.2.1 gives that field one job; the verifier now holds it to it, and a mismatch is refused with `tls/ocsp-sig-alg-key-mismatch`.
+
+It surfaced while covering the refusal paths of the revocation checker — the half of a security primitive that only matters when something is wrong, and the half that had the least coverage. **Fixed:** *The revocation checker's refusal paths are covered* — A revocation check earns its cost only by saying NO for every reason it should, and the accept path is the part that gets exercised. Each refusal now has a test driving the real `evaluate` call with a response that is well-formed in every respect except the one under test: `certStatus` revoked (with and without a CRLReason) and unknown; a `responseStatus` that is not successful; a ResponseData carrying no responses at all; a nonce that does not echo and one absent when required; a signature that does not verify and one made by the wrong key; a CertID under an unrecognised hash algorithm and one naming a different issuer than the certificate under validation; a SingleResponse with no thisUpdate.
+
+Both encodings of the nonce extension are covered — the RFC 8954 raw form and the RFC 6960 double-wrapped one — because a verifier that reads only one scores a live responder's echo as a mismatch and refuses a good response. **Security:** *The OCSP signatureAlgorithm must agree with the issuer key* — The verifier mapped the response's `signatureAlgorithm` OID to a digest — `sha256WithRSAEncryption` to SHA-256, `ecdsa-with-SHA384` to SHA-384, and so on — and then called `node:crypto.verify(digest, tbs, issuerKey, signature)`. Node decides RSA versus ECDSA from the key object, so the OID's algorithm half was read and discarded. An EC-signed response declaring RSA verified; an RSA-signed response declaring ECDSA verified.
+
+Nothing was forgeable through it. Producing a signature that verifies under the issuer key still requires that private key, and the release ships a test asserting that a response signed by a different key is refused. The defect is that a field the verifier depends on to choose the digest was never validated against the key it verified with, so what a response claimed and what was actually checked could differ silently.
+
+`evaluate` now requires the OID family and the issuer key type to agree, and refuses with `tls/ocsp-sig-alg-key-mismatch` when they do not. Responders that declare their own algorithm — every conformant one — are unaffected. **Detectors:** *one OCSP response builder for the test suite* — An OCSP response is layers of nested DER, so each suite that needed one grew its own assembler — three of them, each reaching only the shapes that suite had thought of. Between them they covered the accept path, staleness and the CertID issuer binding, and could not express the signature-algorithm disagreement above at all: no builder had a knob for it. A shared builder makes a new refusal shape an argument rather than a fourth copy, and a detector fires on a re-hand-rolled one.
+
 - v0.18.21 (2026-08-10) — **An NTS or NTP query that cannot build its request left the datagram socket open — one leaked handle per failed query, for the life of the process.** `b.network.ntp.nts.querySingle` and `b.ntpCheck.querySingle` opened their UDP socket before building the request packet. Building it can fail — an AEAD suite the encoder does not recognise is the reachable case, and refusing it is the point — and the socket opened first had nobody left to close it once the exception left the Promise executor. The caller saw the right error either way, which is why this stayed invisible: nothing was wrong with the rejection, only with what it left behind. A scheduler polling a misconfigured time source accumulated one dead handle per attempt and never released any of them.
 
 Both now build the request first and open the socket only once every step that can throw has succeeded, so there is nothing to leak rather than something each new failure path has to remember to undo. A synchronous refusal from `send()` routes through the same close-then-settle path.

package/lib/vendor/blamejs/NOTICE

@@ -77,7 +77,7 @@ Used for:    WebAuthn / passkey registration + authentication response
              server.cjs).
 --------------------------------------------------------------------------------
 Component:   @blamejs/pki
-Version:     0.4.13
+Version:     0.4.14
 Source:      https://github.com/blamejs/pki
 License:     Apache-2.0
 Copyright:   Copyright (c) blamejs contributors

package/lib/vendor/blamejs/README.md

@@ -321,7 +321,7 @@ All runtime dependencies are committed to the repo — no transitive npm install
 | [`@noble/curves`](https://github.com/paulmillr/noble-curves) | 2.3.0 (bundles @noble/hashes 2.3.0) | [Paul Miller](https://github.com/paulmillr) | RFC 9497 Oblivious Pseudo-Random Function (OPRF / VOPRF / POPRF) over ristretto255 / P-256 / P-384 / P-521, behind `b.crypto.oprf` |
 | [`@noble/post-quantum`](https://github.com/paulmillr/noble-post-quantum) | 0.7.0 (bundles @noble/hashes, @noble/curves, @noble/ciphers 2.3.0) | [Paul Miller](https://github.com/paulmillr) | Pure-JS FIPS 203 ML-KEM (`ml_kem_512` / `ml_kem_768` / `ml_kem_1024`), FIPS 204 ML-DSA (`ml_dsa_44/65/87`), FIPS 205 SLH-DSA (`slh_dsa_*`). First-class on both server-side and client-side via `b.pqcSoftware` — security-first defaults pin to the highest cat-5 levels (ML-KEM-1024, ML-DSA-87, SLH-DSA-SHAKE-256f); interoperable with Node's built-in WebCrypto ML-KEM that `b.crypto.encrypt` / `b.middleware.apiEncrypt` use. A browser (ESM) build ships beside it carrying the KEM suites only — a client half encapsulates and does not sign |
 | [`@simplewebauthn/server`](https://github.com/MasterKale/SimpleWebAuthn) | 13.3.2 | [Matthew Miller](https://github.com/MasterKale) | WebAuthn / passkey verification |
-| [`@blamejs/pki`](https://github.com/blamejs/pki) | 0.4.13 | [blamejs](https://github.com/blamejs) | Zero-dependency pure-JS X.509 / CRL / PKCS#12 / CSR / CMS toolkit backing `b.mtlsCa` — ML-DSA-87 (FIPS 204) post-quantum + ECDSA-P384 cert signing, PBMAC1 PKCS#12 packaging, chain validation (no openssl CLI) |
+| [`@blamejs/pki`](https://github.com/blamejs/pki) | 0.4.14 | [blamejs](https://github.com/blamejs) | Zero-dependency pure-JS X.509 / CRL / PKCS#12 / CSR / CMS toolkit backing `b.mtlsCa` — ML-DSA-87 (FIPS 204) post-quantum + ECDSA-P384 cert signing, PBMAC1 PKCS#12 packaging, chain validation (no openssl CLI) |
 | [`SecLists` 10k-most-common.txt](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt) | master snapshot | [Daniel Miessler / SecLists contributors](https://github.com/danielmiessler/SecLists) (CC-BY-3.0) | Top-10000 common-password dictionary read by `b.auth.password.policy()` for the NIST 800-63B §5.1.1.2 "previously breached" check |
 | [`prismjs`](https://prismjs.com/) | 1.30.0 | [Lea Verou + contributors](https://github.com/PrismJS/prism) | Syntax highlighting in the example wiki's code blocks (browser-side) |
 

package/lib/vendor/blamejs/lib/network-tls.js

@@ -1610,6 +1610,23 @@ function _verifyOcspSignature(parsed, issuerPem) {
     throw new TlsTrustError("tls/ocsp-bad-issuer-key",
       "issuer public key parse failed: " + ((e && e.message) || String(e)));
   }
+  // RFC 6960 §4.2.1 — signatureAlgorithm identifies the algorithm the
+  // responder used, and the digest above is derived from it. node:crypto picks
+  // RSA or ECDSA from the KEY, not from that field, so a response declaring
+  // one and carrying the other verifies without anyone noticing the
+  // disagreement. That is not a forgery path — the issuer's private key is
+  // required either way — but it means the field steering the digest was never
+  // checked against the key doing the verifying. Require them to agree, so
+  // what the response claims and what was actually verified are the same
+  // thing.
+  var wantKeyType = (algOid === OID_RSA_SHA256 || algOid === OID_RSA_SHA384 ||
+                     algOid === OID_RSA_SHA512) ? "rsa" : "ec";
+  if (keyObj.asymmetricKeyType !== wantKeyType) {
+    throw new TlsTrustError("tls/ocsp-sig-alg-key-mismatch",
+      "OCSP signatureAlgorithm OID '" + algOid + "' declares a " + wantKeyType.toUpperCase() +
+      " signature but the issuer key is " + String(keyObj.asymmetricKeyType).toUpperCase() +
+      " (RFC 6960 §4.2.1 — the declared algorithm does not match the issuer key)");
+  }
   // ECDSA OCSP signatures use DER-encoded ECDSA-Sig-Value (the ASN.1
   // shape that node:crypto.verify accepts by default — no dsaEncoding
   // option needed).
@@ -2831,13 +2848,19 @@ function _ctVerifyInclusionPath(leafHash, leafIndex, treeSize, auditPath) {
 // prefix. Returns the computed roots (oldRoot, newRoot) so the caller
 // can compare against the operator-supplied STHs.
 function _ctVerifyConsistencyPath(m, n, consistencyProof, firstHash) {
-  if (typeof m !== "number" || m < 1 || Math.floor(m) !== m) {
+  // isFinite carries the weight here: Math.floor(Infinity) === Infinity, so an
+  // integer check alone accepts a tree of infinite size. The walk used to
+  // reject it downstream by running out of proof, but that was an accident of
+  // the loop rather than a decision, and the equal-sizes shortcut below has no
+  // loop to run out of. A tree size that is not a finite positive integer is
+  // refused here, once, for every path through this function.
+  if (typeof m !== "number" || !isFinite(m) || m < 1 || Math.floor(m) !== m) {
     throw new TlsTrustError("tls/ct-bad-first-size",
-      "ct.verifyConsistency: m (first tree size) must be a positive integer");
+      "ct.verifyConsistency: m (first tree size) must be a finite positive integer");
   }
-  if (typeof n !== "number" || n < m || Math.floor(n) !== n) {
+  if (typeof n !== "number" || !isFinite(n) || n < m || Math.floor(n) !== n) {
     throw new TlsTrustError("tls/ct-bad-second-size",
-      "ct.verifyConsistency: n (second tree size) must be an integer >= m");
+      "ct.verifyConsistency: n (second tree size) must be a finite integer >= m");
   }
   if (!Buffer.isBuffer(firstHash) || firstHash.length !== 32) {                  // RFC 9162 SHA-256 digest length
     throw new TlsTrustError("tls/ct-bad-first-hash",
@@ -2847,11 +2870,34 @@ function _ctVerifyConsistencyPath(m, n, consistencyProof, firstHash) {
     throw new TlsTrustError("tls/ct-bad-consistency-proof",
       "ct.verifyConsistency: consistencyProof must be an array of Buffers");
   }
-  // RFC 9162 §2.1.4.2 — algorithm is the same as the inclusion-proof
-  // walk, with the leaf-index seeded at the first-tree size minus 1 and
-  // the special case for m being a complete subtree.
+  // A tree is consistent with itself, and RFC 9162 §2.1.4 says so with an
+  // EMPTY proof: PROOF(m, D[m]) = SUBPROOF(m, D[m], true) = {}. The walk below
+  // is §2.1.4.2, which is written for a first tree strictly smaller than the
+  // second — run on m === n it looks for a sibling that the definition says is
+  // not there. That refused a conformant log's answer whenever the size was
+  // not a power of two (for a power of two the index bits happen to shift down
+  // to zero and the walk short-circuits), so an operator re-checking a pinned
+  // STH against an unchanged one was told the log was inconsistent. A false
+  // alarm on this check is worse than a quiet one: it is the alarm that
+  // teaches an operator to ignore it.
+  if (m === n) {
+    if (consistencyProof.length !== 0) {
+      throw new TlsTrustError("tls/ct-consistency-not-empty",
+        "ct.verifyConsistency: the proof for two equal tree sizes must be empty " +
+        "(RFC 9162 §2.1.4), got " + consistencyProof.length + " entries");
+    }
+    return firstHash;
+  }
+  // RFC 9162 §2.1.4.2 — the walk rebuilds BOTH roots from the same proof: the
+  // first tree's root (fr) and the second's (sr). Both must be checked. Only
+  // sr was, and firstHash reached the computation solely as the seed in the
+  // complete-subtree branch below — so whenever the pinned size was NOT a
+  // power of two, the operator's pinned root was never looked at, and a proof
+  // for some OTHER first tree of the same size verified. That is the whole
+  // premise of pinning an STH ("the tree I pinned is a prefix of the tree you
+  // are showing me"), and it was being taken on trust.
   var path = consistencyProof.slice();
-  var node;
+  var firstNode, secondNode;
   var fn = m - 1;
   var sn = n - 1;
   // Walk past the right-side bits — the consistency proof omits the
@@ -2860,14 +2906,15 @@ function _ctVerifyConsistencyPath(m, n, consistencyProof, firstHash) {
 
   if (fn === 0) {
     // m was a complete subtree — its root is the firstHash itself.
-    node = firstHash;
+    firstNode = firstHash;
   } else {
     if (path.length === 0) {
       throw new TlsTrustError("tls/ct-consistency-empty",
         "ct.verifyConsistency: consistency proof empty but first tree is not a complete subtree");
     }
-    node = path.shift();
+    firstNode = path.shift();
   }
+  secondNode = firstNode;
   while (sn > 0) {
     if (path.length === 0) {
       throw new TlsTrustError("tls/ct-consistency-short",
@@ -2879,15 +2926,34 @@ function _ctVerifyConsistencyPath(m, n, consistencyProof, firstHash) {
         "ct.verifyConsistency: consistency-proof entry is not a 32-byte Buffer");
     }
     if ((fn & 1) === 1 || fn === sn) {
-      node = _ctInnerHashFinal(sibling, node);
+      firstNode  = _ctInnerHashFinal(sibling, firstNode);
+      secondNode = _ctInnerHashFinal(sibling, secondNode);
       while ((fn & 1) === 0 && fn !== 0) { fn >>>= 1; sn >>>= 1; }
     } else {
-      node = _ctInnerHashFinal(node, sibling);
+      secondNode = _ctInnerHashFinal(secondNode, sibling);
     }
     fn >>>= 1;
     sn >>>= 1;
   }
-  return node;
+  // The rebuilt first root must be the one the operator pinned, or the proof
+  // connects their second root to a first tree they never saw.
+  if (firstNode.length !== firstHash.length ||
+      !bCrypto.timingSafeEqual(firstNode, firstHash)) {
+    throw new TlsTrustError("tls/ct-first-root-mismatch",
+      "ct.verifyConsistency: the proof rebuilds a first-tree root that is not the one supplied " +
+      "(RFC 9162 §2.1.4.2 — the proof does not connect the pinned tree to the new one)");
+  }
+  // Everything the peer sent must have been consumed. Its sibling walk above
+  // refuses an audit path with entries beyond the root for the same reason:
+  // a proof carrying material the verifier never looked at is not the proof
+  // the operator believes was checked, and silently ignoring the remainder
+  // means the two walkers disagree about what a well-formed proof is.
+  if (path.length !== 0) {
+    throw new TlsTrustError("tls/ct-consistency-long",
+      "ct.verifyConsistency: consistency proof has " + path.length +
+      " trailing entries beyond the second-tree root");
+  }
+  return secondNode;
 }
 
 function _findSctOid(rawDer) {
@@ -3087,6 +3153,15 @@ var ct = Object.freeze({
                    consistency: consistencyResult };
         }
       } catch (e) {
+        // A proof that rebuilds the wrong first tree is a different answer
+        // from a malformed one, and it is the answer that matters most here:
+        // it says the log's history before the pinned point does not match
+        // what was pinned. Composing the consistency check inside an
+        // inclusion check must not flatten that into "malformed proof".
+        if (e && e.code === "tls/ct-first-root-mismatch") {
+          return { valid: false, reason: "first-root-mismatch",
+                   error: e.message || String(e) };
+        }
         return { valid: false, reason: "consistency-walk-failed",
                  error: (e && e.message) || String(e) };
       }
@@ -3128,6 +3203,16 @@ var ct = Object.freeze({
       computed = _ctVerifyConsistencyPath(opts.firstSize, opts.secondSize,
         opts.proof || [], firstRoot);
     } catch (e) {
+      // A first root that does not rebuild is a distinct answer from a
+      // malformed proof: the proof is well-formed, it just describes a
+      // different tree than the one the operator pinned.
+      // `e` is already proven truthy by the guard on this branch, so the
+      // usual (e && e.message) shape would be dead here; the fallback below
+      // keeps it because a throw of a falsy value still reaches that one.
+      if (e && e.code === "tls/ct-first-root-mismatch") {
+        return { valid: false, reason: "first-root-mismatch",
+                 error: e.message || String(e) };
+      }
       return { valid: false, reason: "consistency-walk-failed",
                error: (e && e.message) || String(e) };
     }

package/lib/vendor/blamejs/lib/vendor/MANIFEST.json

@@ -21,7 +21,7 @@
         "server": "sha256:f3325f480cb8eb814fcb0baaa19336cbbf2b993f48624c6aa9600ffd69d0be5e",
         "browser": "sha256:0ffd91540bcb586a29b56e52ee1c29df69097b50776beb4036a07558f7a4e12e"
       },
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     },
     "@noble/hashes": {
       "version": "2.3.0",
@@ -48,7 +48,7 @@
       "hashes": {
         "browser": "sha256:dfe4b7ae3c9880e388c8da4b68f44742b229b53afacd1e674179527e33da62b0"
       },
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     },
     "@noble/curves": {
       "version": "2.3.0",
@@ -70,7 +70,7 @@
       "hashes": {
         "server": "sha256:b5fe88d1ea780d0581dee6145d666f89d46fc9531b5db35db2e5b16627840890"
       },
-      "refreshedAt": "2026-08-10T18:39:35.028Z",
+      "refreshedAt": "2026-08-11T00:05:07.579Z",
       "components": {
         "@noble/hashes": {
           "url": "https://github.com/paulmillr/noble-hashes",
@@ -114,7 +114,7 @@
         "server": "sha256:fab7ebe5737793862c473444f4ee5912f79dd1edec86683acbb4eecbca0f5892",
         "browser": "sha256:cae1d5bbdc7184b202b6ca68df6e1db7b0d0f668c77809ded189ca7f271accc9"
       },
-      "refreshedAt": "2026-08-10T18:39:35.028Z",
+      "refreshedAt": "2026-08-11T00:05:07.579Z",
       "components": {
         "@noble/hashes": {
           "url": "https://github.com/paulmillr/noble-hashes",
@@ -151,7 +151,7 @@
       "hashes": {
         "server": "sha256:e83195dc9f189385da9c856ef38843f4466f93ea8f3d7fc2efcb1e1b18da6f20"
       },
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     },
     "SecLists-common-passwords-top-10000": {
       "version": "10k-most-common (master)",
@@ -171,7 +171,7 @@
       },
       "runtime_artifact": "lib/vendor/common-passwords-top-10000.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     },
     "bimi-trust-anchors": {
       "version": "operator-managed",
@@ -196,7 +196,7 @@
       },
       "runtime_artifact": "lib/vendor/bimi-trust-anchors.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     },
     "publicsuffix-list": {
       "version": "master",
@@ -216,10 +216,10 @@
       },
       "runtime_artifact": "lib/vendor/public-suffix-list.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     },
     "@blamejs/pki": {
-      "version": "0.4.13",
+      "version": "0.4.14",
       "license": "Apache-2.0",
       "author": "blamejs",
       "source": "https://github.com/blamejs/pki",
@@ -240,11 +240,11 @@
       },
       "bundler": "esbuild --format=cjs --platform=node --external:crypto --external:node:crypto",
       "bundledAt": "2026-08-10T00:00:00Z",
-      "cpe": "cpe:2.3:a:blamejs:pki:0.4.13:*:*:*:*:node.js:*:*",
+      "cpe": "cpe:2.3:a:blamejs:pki:0.4.14:*:*:*:*:node.js:*:*",
       "hashes": {
-        "server": "sha256:067ac05899ef04f7851a8d010dc4289e7a01706d5fd2cdc1ce59860631bba284"
+        "server": "sha256:96a873b733c95b53b8e2ced065a82192b6acabcede312cf68a45a128857cc3bc"
       },
-      "refreshedAt": "2026-08-10T18:39:35.028Z"
+      "refreshedAt": "2026-08-11T00:05:07.579Z"
     }
   }
 }