ruflo@3.38.20 production tree: 1 critical (protobufjs) + 12 high transitive on the live embedding path; plus an undocumented MCP HTTP rate limit (~51 calls/0.3s)

[ruvnet]

npm audit --omit=dev on a bare ruflo@3.38.20 install: 1 critical + 12 high transitive, with the critical on the live embedding path

Context: standing up ruflo mcp start -t http as a private, IAM-gated Cloud Run service for ruvnet/ruClip (ruClip#1, cognitum-one/ruclip ADR-0001/0002). Before shipping the image we audited its production tree: the published package, fresh npm i ruflo@3.38.20 in an empty directory, nothing else installed.

npm audit --omit=dev
38 vulnerabilities (25 moderate, 12 high, 1 critical)

High/critical by package, as npm reports them:

critical protobufjs
high     @claude-flow/cli, @huggingface/transformers, @xenova/transformers, onnxruntime-node,
         onnxruntime-web, onnx-proto, adm-zip, agentdb, agentic-flow,
         @opentelemetry/sdk-node, @opentelemetry/propagator-jaeger

Two import paths reach the critical protobufjs (npm ls protobufjs):

ruflo@3.38.20 → @claude-flow/cli@3.38.20
  ├─ agentdb@3.0.0-alpha.20 → @huggingface/transformers@4.2.0 → onnxruntime-web → protobufjs
  └─ agentdb@3.0.0-alpha.20 → @opentelemetry/sdk-node@0.218.0 → …grpc-js → @grpc/proto-loader → protobufjs

Why it matters for a hosted bridge specifically: the transformers/onnxruntime path is not dormant — every memory_store through the bridge generates a 384-dim embedding (hasEmbedding: true, embeddingDimensions: 384 in the store response), so that code executes on every write from a network-reachable service. --tools limits which tools are callable; it doesn't change which packages load.

Related: the repo's own CVE gate (Audit root (critical-blocking), CVE Audit Gate workflow) currently fails on main for an unrelated reason — npm error notarget No matching version found for @claude-flow/mcp@3.0.0-alpha.10 (run 33467634804) — so it isn't surfacing this today. Not filing a PR: the fix is version bumps in agentdb/@claude-flow/cli dependency ranges, a maintainer call on compatibility (onnxruntime in particular).

One more operational finding from the same session, for whoever owns the HTTP transport: the bridge enforces a per-client rate limit that fires after ~51 calls within ~0.3 s and had not cleared 65 s later (fresh process clears it). Paced at ~1.3 calls/s it never fires (40 store+retrieve pairs, p50 16 ms / 11 ms). The string Rate limit exceeded isn't in v3/@claude-flow/cli/src, so it's coming from a dependency — worth documenting the threshold/window and exposing a knob, since a control plane fanning out several calls per heartbeat across many devices will hit it.

Downstream, cognitum-one/ruclip ADR-0002 records the posture (private service, IAM-gated, exact-name --tools allowlist, pinned version, this issue linked) rather than treating the allowlist as a supply-chain control.

[ruvnet]

Follow-up on the rate-limit half, with the two obvious suspects ruled out so nobody re-does this:

• Not production/rate-limiter.js (defaults maxRequests: 100, windowMs: 60000, burstMultiplier: 1.5): nothing under mcp-server.js, mcp/, or transports/ instantiates it.
• Not agentdb/dist/security/limits.js's token buckets (insert 100/s, search 1000/s, delete 50/s, batch 10/s, continuous refill): those refill every second, but the limit I hit had not cleared 65 s later; a fresh process clears it. Also its message carries a for <operation>. Try again later. suffix, and the one returned to tools/call is the bare Rate limit exceeded.

Measured on 3.38.20, mcp start -t http --tools memory_store,memory_retrieve,memory_list, one client, one session: trips after 51 memory_retrieve calls in 0.3 s; paced at 1.3 calls/s it never trips (40 store+retrieve pairs, store p50 16 ms / p95 28 ms, retrieve p50 11 ms / p95 16 ms; first call incl. initialize handshake 353 ms; RSS ~375 MB). Whatever it is looks like a fixed window ≥65 s with a ~50 budget, keyed per client/session. A knob and a documented number would let downstream control planes size their fan-out; happy to test a patch.

[ruvnet]

Source-level facts for this limiter, read from @claude-flow/mcp/dist/server.js and rate-limiter.js inside a ruflo@3.38.20 install, so the threshold is no longer a guess:

// server.js
this.rateLimiter = createRateLimiter(logger, { requestsPerSecond: 100, burstSize: 200, perSessionLimit: 50 });
// rate-limiter.js
checkSession(sessionId) { ... return this.checkBucket(bucket, this.config.perSessionLimit / 10 /* 10 s to full */, this.config.perSessionLimit); }
DEFAULT_CONFIG = { requestsPerSecond: 100, burstSize: 200, perSessionLimit: 50, cleanupInterval: 60000 }

So: per-session bucket of 50 tokens refilling at 5/s, on top of a global 200-burst / 100-per-s bucket. A client that stays ≤5 calls/s per session never trips; a burst of 50+ within the refill window does. Verified live: with one session refused, a fresh session on the same host stored fine (per-session, not per-IP), and the refused session recovered after the 60 s cleanup interval.

The values are hardcoded in server.js — nothing in mcp start's flags or env reaches them. Ask stands: expose perSessionLimit / refill via flag or env, and put the numbers in the HTTP transport docs. Downstream (cognitum-one/ruclip) we're adding a client-side bucket at 45 / 4.5 per s with retry-on-429 so control-plane seeds and heartbeat fan-out stay under it.

[ruvnet]

Second limiter, same symptom, different layer — worth listing in the same issue since callers see the identical -32000 "Rate limit exceeded":

@claude-flow/mcp/dist/transport/http.js wraps /rpc and /mcp in express-rate-limit with windowMs: this.config.rateLimit?.windowMs ?? 60_000 and limit: this.config.rateLimit?.limit ?? 120 — 120 requests per 60 s per source IP, returned with "id": null because it fires before the JSON-RPC body is parsed. config.rateLimit isn't reachable from mcp start (no flag, no env), so the effective ceiling for any single client host is 2 requests/s sustained, regardless of session. A control plane seeding a company (~260 tool calls) or a Cloud Run service whose egress shares one IP hits this before the per-session bucket ever matters.

Ask, refined: expose both (--rate-limit-per-session, --rate-limit-per-ip / window) or at least the HTTP one, and have the HTTP rejection carry the request id so clients can correlate.

[ruvnet]

Dream security gate — 2026-09-02

The production-tree signal is confirmed and actionable, but the package severity must be separated from demonstrated exploit reachability.

GitHub's reviewed advisory GHSA-xq3m-2v4x-88gg / CVE-2026-41242 rates affected protobufjs <7.5.5 critical and fixes it in 7.5.5. Its stated exploit precondition is attacker influence over a protobuf schema or JSON descriptor loaded through reflection/code-generation APIs. The current bridge evidence proves the vulnerable dependency is present and the embedding path executes on every memory_store; it does not yet prove that caller-controlled text can influence a schema/descriptor. Therefore this is a confirmed critical dependency signal and supply-chain release blocker, not yet a confirmed remotely exploitable bridge RCE.

Frozen remediation gate:

1. clean install of the exact candidate package resolves every protobufjs instance to >=7.5.5;
2. npm audit --omit=dev has zero critical/high findings attributable to the changed dependency path;
3. a source-level trace or adversarial test proves untrusted schema/descriptor input is rejected or unreachable;
4. 40 paced store+retrieve pairs preserve embeddings and p95 latency without bypassing the documented 50-token/5-per-second session and 120-per-minute IP limits;
5. CVE, install, signing, witness, and cross-agent workflows all run on the exact candidate head.

No exploit payload or private deployment information is included here. Current verdict: INCONCLUSIVE pending a patched candidate and reachability test.