RAG Pipeline Utils 3.8.1 fixes four security flaws and needs a re-ingest

What the release does

As dev.to reported, the maintainers of RAG Pipeline Utils published version 3.8.1 as a security release. The library helps developers build retrieval-augmented generation (RAG) systems, where an AI model looks up passages from your own documents before it answers a question.

The project's instruction is blunt: upgrade now if you use its access-control layer, called RetrievalGuard, its plugin signature checking, its development server (DevServer), or the separate @devilsdev/rag-mcp-server package. MCP is a standard way for AI tools to plug into outside data and services. The upgrade is a normal npm install of version 3.8.1 or a compatible later one, and the MCP server can be launched pinned to 3.8.1.

The post says each of the four advisories names the affected versions and offers a workaround for people who cannot upgrade right away.

The four problems, in plain terms

The first and most serious for many teams concerns access control. It affects RetrievalGuard when its access-rule enforcement is switched on, plus the built-in MemoryRetriever, FileVectorStore and BM25Search components. A document limited to one role could end up in front of users without that role. Whether that happened depended on where the restriction was recorded on the document and how the user's permissions were supplied. It is tracked as GHSA-8393-cmg7-9rv3.

The second is about plugin signatures. When the signature checker runs with the content-digest option on (a digest is a fingerprint of the code), a specially built manifest, the plugin's description file, could get through even though the code behind it was never something the signer had approved. That is GHSA-w693-22gp-m69r.

The third involves the development server. In some configurations, other machines on the network, or other web pages open in the same browser, could reach it. They could then fire off requests that spend the owner's paid usage with their language-model provider. That is GHSA-6h47-g8cw-366q.

The fourth hits the MCP server. A booby-trapped HTML file sitting in a folder being indexed could make indexing hang for several minutes. It is GHSA-j2vr-gm7f-3r37.

Why upgrading alone is not enough

The step most likely to be missed is the re-ingest. If you use FileVectorStore, a file-based index, and your documents declare acl or requiredRole at the top level of the document rather than inside its metadata, the old index files never saved that field. Installing the new version does not conjure it back, so those documents stay unrestricted until you rebuild the index from the source files.

Documents that keep the restriction in metadata need nothing further. Neither do the in-memory stores, MemoryRetriever and BM25Search, because they are rebuilt each time rather than read from saved files. For those, the upgrade is the whole fix.

The practical lesson is that a stored index is a snapshot of how the software behaved when it was written. Fixing the code does not fix the snapshot.

A stricter rule that can hide documents

The release also changes how RetrievalGuard decides who may see a document. A document can carry a role or access-list requirement in three places: at its top level, in its metadata, and on the doc object. Access now requires satisfying every one of those that exists. Where a requirement is a list of roles, holding any single role from that list counts as meeting it.

That is safer, but the project warns that it can hide documents people could see before. Imagine a file that says "editors" in one place and "finance" in another. A user who was in only one of the two groups used to get through and now will not. If staff report that files have gone missing after the upgrade, this is the first place to look. The project's CHANGELOG holds the complete list of behavior changes.

Who should care

Anyone who builds or maintains a RAG system with this package is affected, especially if it serves several users with different permissions. Teams that run the development server on a shared network, or on a laptop while browsing the web, should also treat that advisory seriously, because the cost lands on a real billing account.

If you only use an AI product built by someone else, you cannot act on this directly. It is still a fair question to put to a vendor: how do they enforce who can see which document, and how do they handle old indexes when they fix a permissions bug?