CrewAI's agent loader imports whatever code the repository tells it to. A year after the first report, it still does.
Trend's Zero Day Initiative published the flaw as a zero-day in September, and the National Vulnerability Database picked it up this month. We read the current source. Shared agent definitions are code, and they should be handled that way.
Photo: Abstract code lines with varying colors. // GaaS News- CVE-2026-92206, rated 8.8, covers CrewAI's load_agent_from_repository function. ZDI reported it on October 29, 2025 and published it as a zero-day on September 16, 2026.
- We read the main branch on October 31. The function still passes a module name from the API response straight to Python's import system.
- Exploitation needs a victim to load a malicious agent definition. We found no report of attacks and no fix named in CrewAI's release notes.
CrewAI's load_agent_from_repository function now has a CVE on a flaw first reported a year ago, and the framework's main branch appears to contain the same code. CVE-2026-92206, scored 8.8, entered the National Vulnerability Database on October 21. The Zero Day Initiative advisory behind it says the process "does not properly restrict a user-supplied argument before using it to import a module," which lets a remote attacker run code "in the context of the service account."
The attack needs one step from the victim. In ZDI's words, "the target must load a malicious agent configuration from the repository." That is ordinary use of the feature. A developer writes from_repository with an agent's name, and CrewAI fetches the definition.
The CrewAI disclosure timeline
The CrewAI disclosure timeline in the advisory is short. ZDI reported the vulnerability on October 29, 2025. On February 2, 2026 it "followed up asking the vendor to confirm receipt of the report." On April 2 it "notified the vendor of the intention to publish the case as a 0-day advisory," and on September 16 it did. The advisory is headed "(0Day)" and offers a single mitigation: "restrict interaction with the product." It lists no patch.
A separate public report appeared in the meantime. On April 14 a GitHub user filed issue 5446, "Remote Code Execution via Unvalidated Dynamic Module Import," pointing at the same file. Two contributors replied with CrewAI's security policy and its disclosure form, and the issue was closed under five hours after it opened, marked not planned. Sending a security report to a private channel is normal practice, so that alone proves nothing, and we cannot say whether it is the same bug ZDI filed.
What the CrewAI code does today
What the CrewAI code does today is visible in the public repository. We read agent_utils.py on the main branch on October 31. Inside load_agent_from_repository, the function walks the tools list in the API response and, for each tool, calls importlib.import_module(tool["module"]), resolves a class with getattr, and instantiates it with tool["init_params"]. We saw no allowlist on the module name in that path. The agent definition chooses which Python module gets imported and what arguments the class receives.
CrewAI shipped 1.15.33 on October 29. The release notes we checked back to September do not name this CVE, the repository lists no published security advisories, and the NVD record shows no fixed version. Its status reads "Deferred."
Why shared agent definitions are a supply chain
Shared agent definitions are a supply chain, and this flaw shows what that means in practice. Teams tend to treat an agent as configuration: a role, a goal, a list of tools. But if the list of tools names modules to import, then anyone who can publish or alter a definition in the repository your code pulls from is choosing what runs on your machine. Package managers learned this years ago, which is why allowlists, pinning and signatures exist. Coding agents that hallucinate package names are another version of the same exposure.
October's advisories show the plumbing under multi-agent systems is still immature. CVE-2026-115419 in Strands Agents, rated 8.1, describes an A2A server that "shares conversation history across callers with different context_id values." CVE-2026-111767 in the MCP TypeScript SDK let clients sharing one task store "list, read and cancel each other's tasks." Both have fixes. Both come from the same mistake: state in a shared service that was not tied to the caller.
What is not established
What is not established is whether anyone has exploited this. We found no such report. The repository call uses an authenticated client tied to a CrewAI organization, so real exposure depends on who can publish to the repository a victim loads from, and on whether a poisoned definition can reach it. A fix could exist in a hosted component we cannot see. ZDI's score assumes user interaction, and the GitHub issue's higher 9.8 estimate came from its reporter, not from NVD or ZDI.
What CrewAI users should do
CrewAI users who rely on from_repository can reduce the risk without waiting for a patch:
- List every call to from_repository and decide whether you need it.
- Limit who can publish to your CrewAI organization's repository, and review changes the way you review code.
- Run agents that load shared definitions in a container with no production secrets.
- Keep your own allowlist of tool modules and fail closed on anything else.
For more on how frameworks fit together, see our agent orchestration guide.
