The National Vulnerability Database logged CVE-2026-108789 as a CVSS 5.5, squarely “medium.” The affected product is deepseek-ai/deepseek-harness, versions up to 0.1.1-rc.2. The vulnerable function is agent, inside the dsh-workflow-worker-thread component. The flaw lets an attacker remotely manipulate workflow enforcement, and a public exploit already exists. DeepSeek was contacted early and never responded.
That last sentence is the story. Not the score. Not the component name.
What a 5.5 actually means here
CVSS is a severity score, not a risk score, and the gap between those two things is where agent frameworks live right now. A 5.5 means the base metrics landed in the middle: likely some combination of network reachability, low complexity, and limited direct confidentiality or integrity impact. But CVSS was designed for a world where a vulnerability has a bounded blast radius. A web app that leaks session tokens. A library that mishandles a buffer.
An agent harness is not that. It is the orchestration layer that decides what an AI model is allowed to do. The dsh-workflow-worker-thread component name tells you this is where workflow execution happens, where the harness enforces the sequence of steps an agent takes. The CVE description says the manipulation “leads to enforcement of behavioral workflow.” Read that carefully. The bug doesn’t just crash something. It changes what the agent is permitted to do, or forces it to do something the workflow was supposed to gate.
If you’re running deepseek-harness in a pipeline where the agent has tool access, file access, or network access, a “medium” severity workflow-enforcement flaw is not medium in practice. It is a control-plane bug. The score reflects the generic metric math. The operational reality reflects what you wired the agent into.
The vendor silence is the real finding
The disclosure says DeepSeek “was contacted early about this disclosure but did not respond in any way.” That is not an unusual outcome in open-source security. Coordinated disclosure is a volunteer sport, and maintainers get buried. But DeepSeek is not a hobbyist project. It is one of the most-watched names in AI, with a research operation that has shipped models competitive enough to move markets and provoke policy debate. A harness that carries the company’s name and ships under a release-candidate tag is not a throwaway script.
Silence from a lab of that profile is a signal about how the industry still treats agent infrastructure: as a demo surface, not as production software. The 0.1.1-rc.2 version string makes the point for me. This is pre-1.0, release-candidate code. People are nonetheless building on it, because the pull of “here’s a working agent harness” is stronger than the pull of “wait for the stable tag.”
The pattern is bigger than one CVE
This is not an isolated incident. It is the shape of the whole agent-tooling category in 2026. Frameworks from well-funded labs and scrappy open-source teams alike are shipping fast, and security review is lagging the release cadence. The attack surface is also genuinely new. Traditional software vulnerabilities are about data and execution. Agent vulnerabilities are about behavior. When you can manipulate a workflow, you can potentially manipulate what an autonomous system decides to do, which tools it reaches for, which actions it commits. That is a different category of harm than a memory-safety bug.
The public exploit matters too. The NVD entry notes the exploit “is publicly available and might be used.” For agent harnesses specifically, public exploits are a gift to anyone running these systems in multi-tenant or internet-exposed configurations. The barrier to abuse is low because the tooling is designed to be composable and accessible. That composability is the feature and the liability.
What this means for AI builders
If you are building on deepseek-harness, or on any pre-1.0 agent framework, three things follow. First, treat the harness as untrusted infrastructure. Sandbox it. Isolate the worker thread. Do not give an agent framework network egress and filesystem write access in the same process unless you have a specific reason and a specific control. Second, pin your versions and watch the advisory feeds for the frameworks you depend on, because vendor responsiveness is clearly not guaranteed. Third, and least comfortable: assume there are more of these. A component this central to agent execution, shipped at release-candidate quality, with a vendor that goes quiet on disclosure, is a leading indicator, not a one-off.
The uncomfortable truth is that the AI industry has spent two years optimizing for capability and almost no time optimizing for the security posture of the glue layer. The models get the benchmarks. The harnesses get the CVEs. And when a harness bug lets someone remotely reshape what an agent is allowed to do, the “medium” label is doing a lot of unearned work.
What to watch: whether DeepSeek patches dsh-workflow-worker-thread in a 0.1.1-rc.3 or later, and whether the fix is a real control change or a version bump that closes the specific reported path while leaving the workflow-enforcement design as-is. The CVE will be marked resolved either way. The question is whether the underlying assumption, that agent orchestration is safe to ship before it is safe, gets revisited. {/* TODO: confirm whether DeepSeek has published a patch or advisory since the NVD entry, and whether the fix changes workflow-enforcement logic or only the reported path */}