GHSA-4jh4-qv86-j2gw: 
JavaScript vulnerability analysis and mitigation

Summary

Some inputs made several checks take seconds to minutes of CPU time, in time that grows faster than the input: InjectionDetector, the default email PII pattern, answer scoring in checkAnswer / evaluate, plugin archive extraction in hub install, EntityExtractor, and the MCP server's check_answer and search_documents tools. Separately, a DevServer bound to all interfaces did not apply its Host-header check to requests from the local machine. Fixed in 3.8.2.

Details

Affected components (main package versions)

• InjectionDetector role-marker rule: from 2.5.0 (@devilsdev/rag-guardrails from 3.2.0).
• Default email PII pattern (PostGenerationGuard, later detectors): from 2.4.2 (@devilsdev/rag-guardrails from 3.2.0).
• Answer scoring identifier pattern (checkAnswer, evaluate): from 3.6.0 (@devilsdev/rag-core from 3.6.0).
• Plugin archive extraction (hub install of a .tgz): from 2.5.0 (main package only).
• @devilsdev/rag-mcp-server tool inputs had no size limits: from 3.4.0.
• DevServer bound to 0.0.0.0 or ::: from 2.3.0 (main package only).
• The same email pattern in EntityExtractor (graph retrieval): from 2.4.2 (main package only).
• SecureLogger's secret redaction in 2.3.0 to 3.1.1 (used by the event logger) had the same issue; it was removed from the package in 3.2.0. Severity: moderate for the availability issues; low for the DevServer Host check.

Patches

3.8.2. The patterns run in linear time, and archives with a malformed extended header are refused. The MCP server caps its inputs (answer 50,000 characters, each source 200,000, question or query 10,000, 100 sources per call; configurable) and refuses a check_answer call whose check would take too long: more than 2,000,000 answer words × source clauses, or 3,000,000 answer sentences × source characters (configurable). Every check then runs in a worker thread with a 512 MB heap limit and is stopped after 10 seconds (--check-timeout-ms, configurable), so input the two counts don't cover can't hold the server longer, and the server keeps answering other calls during a check. At most 2 checks run at once (--max-concurrent-checks) and up to 8 wait. DevServer applies the Host check to loopback requests whatever it is bound to. checkAnswer in the library has no such limit: its cost still grows with answer size × source size, so library callers should cap untrusted input (see Workarounds). 3.9 makes the comparison linear.

Behaviour changes

MCP calls over the limits are rejected, including calls whose check would take too long, and checks are stopped after 10 seconds. Malformed plugin archives are refused. See CHANGELOG 3.8.2, Changed.

Workarounds

Limit the length of text passed to the guards and to checkAnswer (for example with PreRetrievalGuard's maxQueryLength and a size limit on documents and answers). Install plugins only from sources you trust. Don't expose the MCP server to untrusted clients. Bind DevServer to loopback.

Proof of concept

Step-by-step reproduction details are withheld for now so that users have time to upgrade. The affected configurations are described under Details and Impact. Release 3.8.2 adds regression tests for each issue in this advisory; they fail on 3.8.1 and pass on 3.8.2.

Impact

• Availability: applications that pass untrusted text to InjectionDetector (queries and, with detectInjection, retrieved documents), check answers and citations for PII, score answers with checkAnswer / evaluate, pass text to EntityExtractor, unpack plugin archives with hub install, or expose the MCP server's check_answer and search_documents tools. While a check runs, the Node.js process does nothing else.
• DevServer bound to all interfaces: requests arriving from the local machine skipped the Host-header check, so a web page could reach the server through DNS rebinding. Binding to loopback (the default) was not affected.