CVE-2026-22252 is a critical flaw (CVSS 9.1) in LibreChat before v0.8.2-rc2. The MCP stdio transport accepts arbitrary commands without validation, so any authenticated user can run shell commands as root inside the container with one API request. The fix is v0.8.2-rc2 or later, so upgrade.
What's affected
LibreChat versions prior to v0.8.2-rc2. The fixed version is v0.8.2-rc2.
The advisory reports the issue as tested on v0.8.2-rc1 and says it works on the default installation. The fix is commit 211b39f in the LibreChat repository.
The account needed is any registered user. The CVSS vector lists privileges required as high, which is lower than the advisory text suggests, so judge your own exposure by who can register or log in to your instance.
How to check if you're exposed
Find the version you run. For a Docker deployment, look at the image tag or the commit your compose file builds from.
docker ps --format "table Names\tImage" | grep -i librechat
docker exec LibreChat cat package.json | grep version
The container name may differ in your setup. If the version is older than v0.8.2-rc2, you are affected.
Then answer three questions. Is registration open? Who has accounts? Is the MCP server creation permission enabled for ordinary users? The advisory says it is on by default.
What to do now
- Upgrade LibreChat to v0.8.2-rc2 or later and redeploy the container.
- Until then, close open registration and review the list of accounts for any you do not recognise.
- Review role permissions and turn off MCP server creation for users who do not need it.
- Check the container for signs of tampering, including new files and unexpected processes, and look at the MCP server list for entries you did not add.
- Rotate API keys, database credentials and any secrets held in the environment of the container, since the commands run as root.
- Run the container with the fewest rights possible, and keep it off networks that hold other services.
Why it matters
The weakness is CWE-285, improper authorization. The advisory names three factors that combine. MCP server creation is enabled for all users by default, the stdio command field accepts arbitrary shell commands with no validation, and commands run immediately when the server is created during inspection.
MCP stdio servers are designed to start a local process, so a tool that lets users define the command has to treat that field as code execution. Here the control that should have limited it, permission to create servers, was open to everyone. The result is root inside the container, from the API, for an ordinary account.
The record does not say the flaw is exploited in the wild, and it is not on the CISA KEV list. The advisory does include reproduction steps. This post leaves them out.
Try it yourself
Severity alone does not decide urgency. This demo walks through checking whether a flaw is practical to exploit in your setup.
Click through it at your own pace, or open it full screen.
Quick check
Do attackers need an account?
Yes. The advisory says any authenticated user can do it, and registration may be open on your instance.
Does the container isolate me?
It limits the blast radius, but the commands run as root inside it and can reach whatever the container can reach, including secrets in its environment.
Is there a workaround?
The advisory text I read does not list one. Upgrading is the fix, and removing the MCP creation permission from ordinary users reduces exposure in the meantime.
Sources
Last reviewed: 19 October 2026.
