Dan Aridor — SPR{K3 Security Research May 2026
Over the past months, SPR{K}3 has submitted vulnerability reports to every major AI framework vendor. The bugs are real — unsafe deserialization in agent execution layers, pickle-based remote code execution in orchestration runtimes, unauthenticated network paths to arbitrary code execution in distributed training infrastructure. The proof-of-concepts work. The CVSS scores are 9.0 and above.
And yet, a remarkable pattern has emerged in vendor responses: the vulnerabilities are acknowledged, the technical details are confirmed, and the cases are closed as out of scope. The justification is always a variation of the same claim: this component operates within a trusted environment. They are all acknowledging the bug exists but declining to treat it as a security boundary violation.
The logic is consistent across vendors: if the attacker must first compromise the trusted environment to reach the vulnerable code, then the vulnerable code is not the security boundary — the environment is. Therefore, the vulnerability is not a vulnerability. It is a feature operating as designed within its expected trust context.
This reasoning has a name. We call it the Allowlist Fallacy.
The Fallacy, Stated Plainly
The Allowlist Fallacy is the assumption that a system’s security posture can be defined entirely by the trust properties of its deployment environment, rather than by the behavior of the system itself. It treats the environment as an invariant — a fixed, reliable precondition that the software can depend on without verification.
The practical consequence is that any code path reachable only from within a “trusted” context is exempt from security review. Pickle deserialization from a network socket? Not a vulnerability — the network is trusted. Agent tool execution without input validation? By design — the orchestrator is trusted. Arbitrary code execution via model loading? Expected behavior — the model repository is trusted.
The fallacy is not that trust boundaries exist. They do, and they matter. The fallacy is the assumption that trust boundaries hold.
Proof by Counterexample: CVE-2026-41940
On April 28, 2026, cPanel issued an emergency security update for CVE-2026-41940, a CVSS 9.8 authentication bypass affecting all supported versions of cPanel and WHM — the web hosting control panel that manages an estimated seventy million domains worldwide.
The vulnerability is a textbook case of what happens when trusted environments fail. cPanel and WHM serve as the administrative control plane for shared hosting infrastructure. The management ports are not supposed to be internet-exposed. The session handling layer is not supposed to accept unauthenticated administrative sessions. The entire architecture is predicated on the assumption that if you can reach the management interface, you are a trusted operator.
A CRLF injection in the session writer broke every one of those assumptions. An unauthenticated attacker could inject arbitrary session properties — including administrative identity — into pre-authentication session files. The result was complete root-level access to the hosting control plane, and through it, to every website on the affected server.
This was not a theoretical attack. In-the-wild exploitation was confirmed dating back to at least late February 2026, roughly two months before the patch was released. CISA added it to the Known Exploited Vulnerabilities catalog. Hosting providers were forced to block their own management ports as an emergency containment measure.
The scale was staggering. Shodan telemetry at the time of disclosure showed approximately 1.5 million internet-exposed cPanel instances. cPanel controls roughly ninety-four percent of the hosting control panel market. The “trusted management plane” that was never supposed to be reachable from the internet was, in fact, reachable from the internet on hundreds of thousands of servers. And it had been silently compromised for months.
This is what the Allowlist Fallacy looks like at production scale. The vendors who closed our AI framework vulnerability reports — arguing that the vulnerable code operates in a trusted environment and is therefore not a security boundary — are making the exact same architectural bet that cPanel made. cPanel lost that bet.
The Agent Layer Changes the Equation
Even if we accepted the premise that network perimeters reliably separate trusted from untrusted contexts — which CVE-2026-41940 just disproved — the argument still collapses when applied to AI agent systems. The agent layer introduces a fundamentally new class of trust boundary violation that bypasses network-level controls entirely.
In April and May 2026, security researchers published coordinated disclosures demonstrating prompt injection, hidden parameter abuse, registry poisoning, and remote command execution chains across multiple MCP (Model Context Protocol) runtimes. The affected systems included Anthropic’s own MCP SDKs, Claude Desktop, Cursor, Continue, Langflow, and Gemini CLI.
These are not obscure research prototypes. They are the production tool-calling infrastructure that enterprises are deploying right now to connect language models to business-critical systems. And the attack vectors do not require network access to a “trusted environment.” They come through the agent interface itself.
The kill chain is straightforward: an attacker crafts a prompt injection that survives into the agent’s tool-calling context. The agent, operating with delegated permissions, executes the injected instruction through whatever tools it has access to — file systems, databases, APIs, shell commands. The trust boundary the vendor claims to protect was never crossed. The agent was always inside it.
This is why the vendor rejection pattern is not just wrong — it is architecturally incoherent. The vendors argue that their code is safe because it runs inside a trusted boundary. But the agent layer — the very product these vendors are building and selling — is designed to operate inside that boundary. And the agent layer is the attack vector.
A Parallel Threat: Documentation as Executable Payload
Researchers have also identified what has been termed Document-Driven Implicit Payload Execution, or DDIPE — a pattern where malicious logic embedded in skill documentation, configuration examples, and plugin manifests causes coding agents to execute hidden payloads during routine operations.
This is not prompt injection in the traditional sense. The payload does not arrive through a conversation. It arrives through the agent’s own onboarding process — the documentation it reads to learn how to use a tool. A SKILL.md file with an embedded shell command. A YAML configuration example with an obfuscated instruction. A README with a base64-encoded directive in a code block that the agent faithfully decodes and executes.
The implication is severe: the supply chain for AI agents now includes the natural-language documentation those agents consume. Every skill marketplace, every plugin repository, every configuration template is a potential execution surface. And none of the “trusted environment” defenses that vendors invoke have anything to say about it, because the attack happens inside the trust boundary, through the front door, using the agent’s own capabilities exactly as designed.
The Vendor Rejection Pattern
Over the course of our research, SPR{K3 has documented a consistent taxonomy of vendor rejection responses:
“Trusted Network” — The component assumes a trusted network environment. Finding closed as informational. This is the PyTorch distributed training response. The assumption is that if you can send packets to a training node, you are a trusted participant. CVE-2024-50050, which demonstrated cluster-wide RCE through unauthenticated ZMQ pickle deserialization, was the first empirical refutation. The vendors patched that specific instance and continued applying the same assumption to adjacent code paths.
“By Design” — The behavior is intentional and expected within the product’s threat model. This is Vendor response to agent-layer deserialization findings. The product is designed to execute arbitrary code from trusted sources. The question of what happens when the source is compromised is outside the threat model. This is not a security response — it is a scope limitation masquerading as one.
“Defense in Depth” — The finding is acknowledged as a defense-in-depth improvement but does not represent a security boundary violation. This is the Runtime response. The vulnerability exists. It is exploitable. It has a CVSS score of 9.9. But because exploitation requires traversing a boundary that the vendor considers non-security-relevant, it is classified as a hardening recommendation rather than a security fix. The distinction is meaningful to the vendor’s internal tracking. It is meaningless to the attacker.
“Out of Scope” — The vulnerability class is not covered by the vendor’s security program. This is the other vendor response. Entire categories of findings are excluded from consideration, not because they are invalid, but because the vendor has drawn its program boundaries to exclude them.
Each of these responses is internally consistent. Each follows the vendor’s own published policies. And each transfers unpatched, exploitable risk to every enterprise that deploys these frameworks in production — enterprises that do not know the risk exists because the vendor declined to issue an advisory.
What This Means for Enterprises
The practical consequence of the Allowlist Fallacy is a growing inventory of unpatched, vendor-acknowledged vulnerabilities in production AI infrastructure. The vendors know the bugs exist. They have confirmed the technical details. They have declined to fix them.
This creates a specific and measurable risk profile for any organization deploying these frameworks:
Your distributed training clusters contain unauthenticated deserialization paths that the framework vendor has classified as “by design.” Your agent orchestration layer executes arbitrary code from sources that the vendor considers “trusted” without defining what trust verification looks like. Your model loading pipelines accept pickle-serialized objects from repositories whose integrity the vendor assumes but does not verify.
The vendor’s threat model does not match your deployment reality. And the vendor has explicitly told you — through case closure notifications that most security teams never read — that they are not going to close the gap.
The Path Forward
The Allowlist Fallacy will not be resolved by vendor bug bounty programs. The vendors have already decided these findings are out of scope. The resolution has to come from the enterprises deploying the frameworks, and it requires three things:
First, implement runtime monitoring at the trust boundaries that vendors refuse to defend. If the framework vendor will not validate inputs to deserialization sinks, your deployment must. If the agent orchestration layer does not enforce tool-calling constraints, your infrastructure must. The vendor has told you they will not do it. Believe them.
Second, demand transparency. When a vendor closes a CVSS 9.9 finding as “Defense in Depth,” ask them to publish that decision. Ask them to include it in their security advisories. Ask them to explain to their enterprise customers why a confirmed remote code execution path is not a security boundary. The decision to leave a vulnerability unpatched is a decision that should be made with full visibility, not buried in a case management system.
The allowlist fallacy persists because it is convenient. It allows vendors to maintain narrow threat models that exclude the most consequential attack surfaces in their products. It allows security teams to check a compliance box because the vendor says the finding is not a vulnerability. It allows everyone to look the other way while the actual risk accumulates.
CVE-2026-41940 demonstrated what happens when convenient assumptions meet determined attackers. The AI agent ecosystem is next.
SPR{K3 Security Research has disclosed and confirmed vulnerabilities across Meta, Microsoft, Google, Amazon, HuggingFace, NVIDIA, Intel, GitHub with Recognized and published CVE.
For enterprise threat assessments of your AI infrastructure, contact Support@sprk3.com
System D 