The State of DeepSeek Harness Security, Two Weeks In

Two weeks after launch, DeepSeek Harness (dsh) has one confirmed, officially fixed vulnerability (a Bubblewrap sandbox escape, patched in 0.1.1-rc.1) and a longer list of community-reported trust-model concerns that remain open as of this writing — none of them independently verified by us. This post is a defensive roundup, not a how-to: it tells you what's fixed, what's reported but unconfirmed, and the concrete steps you can take today to reduce your exposure.

What's officially fixed

The only vulnerability with a clear official fix trail is a Bubblewrap sandbox bypass via /proc/<pid>/root, patched in the v0.1.1-rc.1 release (2026-08-21). The release notes list it under "fixes," alongside a table-layout fix and cache-hit-rate display precision — dsh doesn't publish a dedicated security advisory format, so this line item in the regular release notes is the closest thing to a confirmed CVE-style disclosure currently available. We don't reproduce exploitation details here; if you want the mechanics, they're implicit in the phrase "restricted process could bypass sandbox restrictions via /proc/<pid>/root" in the release notes themselves.

The second confirmed fix is process-level rather than code-level: dsh's documentation site used to deploy on every push to master, meaning unreleased content could leak to the public, unauthenticated Pages site before it ever reached a tagged release. That was changed to a release-tag-gated deployment — the docs site now only rebuilds on workflow_dispatch, reusing the same ref-validation gate as the npm publish flow. It's a supply-chain hygiene fix more than a runtime security fix, but it closes a real "read the unreleased roadmap early" leak.

Both fixes date from the same release cycle, which tracks with dsh's stated posture: it's a developer preview with no SemVer guarantee and a fast release cadence (three npm versions in five days as of 2026-08-21 — see DeepSeek Harness Upgrade Guide for what changed between them). If you want the general permission model these fixes sit on top of, start with DeepSeek Harness Permissions and Sandbox Explained.

Community-reported trust-model concerns

On 2026-08-18, a fairly systematic third-party summary of open trust-model issues circulated on X (source, community-reported, not independently verified by us). We're listing the items here in defensive, non-exploitable terms — what the risk is and how to reduce it, not how to trigger it.

Reported issue	Why it matters	Community source
Web UI has no authentication layer (no token, cookie, or TLS)	Any local process that can reach the port can act on your behalf	community-reported
Binding to 0.0.0.0 auto-adds LAN IPs to the trusted-host list	Anyone on your local network segment could gain the same unauthenticated control	community-reported
Unauthenticated loopback RPC can read full session content	A local process without dsh's own UI can still read what you've been doing	community-reported
Plugin install runs JS in the host process immediately, and may leave residue after dsh plugin remove	"Installing" a plugin is not a sandboxed preview — it executes on your machine right away	community-reported
AGENTS.md/CLAUDE.md instruction injection can trigger without install or approval	Untrusted repo content can steer the agent before you've consciously granted it anything	community-reported
Workflow-tool VM sandbox isolation can reportedly be bypassed	The "no filesystem/network/timer access" claim for workflow scripts is disputed	community-reported
Under workspace-write, the model can reportedly self-approve via a web approval loopback and escalate to danger-full-access	The one guardrail meant to require a human click can reportedly be routed around	community-reported

The thread frames all of this as one underlying tension: dsh's model behavior is treated as production-grade, but plugin code execution has comparatively little security design around it. That's a fair way to read the list — none of these are exotic zero-days, they're mostly "the trust boundary you'd assume exists, doesn't yet." The same thread notes the community is already building defenses in response — see the "tools you can add today" section below.

We're not able to independently verify any item in that list (we don't have a reproduction environment set up for this), so treat this table as "things to be cautious about and watch for official acknowledgment," not confirmed CVEs.

Independent evaluator perspective

Two more measured, attributed takes worth reading in full:

• magnus919.com points out that dsh's local sandbox restricts write locations, but does not restrict process visibility or network egress — a narrower scope of protection than "sandboxed" might imply to someone coming from a container-based mental model.
• Wavect frames dsh as suitable for small-scale pilots, not yet a control plane you'd hand production workloads to without additional guardrails, given the developer-preview status and the trust-model gaps above.

Neither source is a formal security audit; both are read as informed technical commentary, and we're citing them as such.

Your protection checklist

This is the actionable part. None of these require deep security expertise — they're configuration choices and habits.

1. Never bind to 0.0.0.0. Keep the Web UI on 127.0.0.1 only. If you need remote access, use your own authenticated tunnel (SSH port-forward, Tailscale, etc.) rather than exposing the port directly — dsh itself calls 0.0.0.0 support "intentionally not supported yet for safety."
2. Default to workspace-write with careful approval, not danger-full-access. Understand what each permission preset actually restricts before you loosen it — see DeepSeek Harness Permissions and Sandbox Explained for the full breakdown of sandbox modes and approval policies.
3. Review a plugin before installing it, not after. Since installation runs code in your host process immediately, treat dsh plugin add the way you'd treat npm install from an unfamiliar registry. Use our DeepSeek Harness Plugin Security Checklist before adding anything you haven't vetted.
4. Try new or unfamiliar plugins in an isolated profile, not your daily-driver one — dsh plugin --profile <name> add ... scopes installs per profile, so a bad plugin in a throwaway profile doesn't touch your main workspace.
5. Pin a commit or version rather than always tracking latest, especially in CI or automation. It also protects you from picking up a regression the day it lands.
6. Upgrade to 0.1.1-rc.1 promptly to pick up the sandbox fix above — see the DeepSeek Harness Upgrade Guide for what else changed and any breaking-change notes from the rc.6→rc.8 cycle.
7. Keep sensitive repositories out of the workspace you point dsh at, especially while trust-boundary questions like the ones above remain open. Treat the workspace root as semi-trusted, not private.
8. Consider community scanning tools — a few plugins exist specifically to add a layer of defense dsh doesn't ship natively: dsh-poison-guard (plugin-poisoning scanner), dsh-skill-security-guard (scans a Skill before you trust it), and dsh-guardian (runtime guardrails for dangerous commands). These are community projects, not official endorsements — vet them with the same checklist in item 3 before installing.

Prompt injection: a shared risk, not a dsh-specific one

AGENTS.md/CLAUDE.md and other in-repo file content being a vector for instruction injection isn't unique to dsh — it's a structural risk in every agent harness that folds workspace files into context automatically (dsh renders up to 65,536 bytes of AGENTS.md/CLAUDE.md into every new session by default). An arXiv paper has evaluated indirect prompt injection success rates against agent harnesses, but we haven't independently verified its methodology or numbers, so we're not citing specific figures here — only noting that the risk category is real and actively being studied. The practical mitigation is the same one that applies to any untrusted input: review what's in a repo's AGENTS.md before you point an agent at it, and don't grant danger-full-access to workspaces you didn't create yourself.

Outlook

dsh is still a developer preview with no SemVer promise, a release every couple of days, and — per its own README — an explicit warning that breaking changes will happen. Security posture at this stage is a moving target: today's community-reported gap could be next week's patched release, or it could sit open for a while precisely because there's no formal CVE process and feedback flows through GitHub Discussions rather than a security mailing list. The most useful habit right now is simply staying current — watch the Discussions tab and the release notes rather than assuming today's threat model still holds next month.

FAQ

Is DeepSeek Harness safe to use?

It's safe enough for a scoped, non-sensitive local workflow if you follow the checklist above — bind to 127.0.0.1, use workspace-write with approvals on, and review plugins before installing. It is not yet something we'd recommend handing production credentials or sensitive repositories to without extra guardrails, given it's a developer preview with several open, community-reported trust-model gaps.

What's the one confirmed dsh vulnerability so far?

A Bubblewrap sandbox bypass via /proc/<pid>/root, fixed in v0.1.1-rc.1. It's the only issue with an official patch and public release-note reference; everything else in this post is either community-reported and unverified, or independent commentary.

Why shouldn't I bind the Web UI to 0.0.0.0?

Because there's no authentication layer on the Web UI — no token, cookie, or TLS — binding to all interfaces exposes local remote-code-execution-equivalent control to anyone on your network segment. dsh's own docs describe 0.0.0.0 support as intentionally withheld for safety reasons.

Are dsh-poison-guard, dsh-skill-security-guard, and dsh-guardian official security tools?

No — they're community-built plugins, not an official dsh security product. Treat them as a useful extra layer, and vet each one with the same install-review checklist you'd apply to any other plugin before adding it to a trusted profile.

Does the sandbox fully isolate what an agent can do?

Not entirely, per independent commentary: the local sandbox restricts write locations, but reportedly does not restrict process visibility or network egress. Combine sandboxing with the approval-policy and workspace-scoping practices above rather than treating "sandboxed" as equivalent to "fully isolated."

Next steps

For the fuller permission model these fixes and reports sit on top of, read DeepSeek Harness Permissions and Sandbox Explained, then work through the DeepSeek Harness Plugin Security Checklist before installing anything new. If you're on an older version, the DeepSeek Harness Upgrade Guide covers the path to 0.1.1-rc.1 and what breaks along the way. Browse vetted, categorized plugins — including the security tools mentioned above — under Security & Permissions on FindHarness.