Security researchers have disclosed a design-level flaw in DeepSeek Harness, DeepSeek's open-source framework for running AI coding agents directly on developer machines. The defect allows an agent operating inside the tool's OS-level file sandbox to turn that sandbox off itself — with a single command and no human approval. The agent simply calls Harness's own local web control interface and flips the sandbox off.
This is not a theoretical concern. The entire purpose of the Harness sandbox is to let teams run autonomous or semi-autonomous agents against untrusted files, untrusted repositories, and model-generated code with a guarantee that the agent cannot write outside its designated workspace. When the sandboxed process itself holds the keys to the sandbox, that guarantee evaporates. Any prompt-injection payload embedded in a file the agent is asked to review, any malicious dependency the agent pulls, or any hostile instruction smuggled through a README or issue comment can now escalate from 'confined agent' to 'unrestricted code execution on a developer workstation' — a workstation that almost certainly holds source code, cloud credentials, SSH keys, and access to internal CI/CD.
If your organization runs AI coding agents locally — with DeepSeek Harness or any comparable framework — treat this as a prompt-injection-to-workstation-compromise path and act accordingly.
Technical Analysis
Affected Product
- Product: DeepSeek Harness (open-source AI coding agent runner)
- Platform: Developer workstations running the Harness agent runtime (Linux and macOS are the primary targets for this class of tooling; any platform where the Harness daemon exposes its local control interface is affected)
- Affected component: The local web control API exposed by the Harness daemon, and the trust boundary between the sandboxed agent process and that control plane
No CVE identifier has been published in the reporting at the time of writing. Track the DeepSeek Harness GitHub repository and its security advisories for a formal assignment.
How the Flaw Works — Defender's View
DeepSeek Harness isolates agent-executed commands inside an operating-system sandbox so that file writes are confined to the agent's workspace directory. The failure is an authorization and trust-boundary defect, not a memory corruption bug:
- The Harness daemon runs a local web control service that manages agent lifecycle and configuration — including the toggle that enables or disables the file sandbox.
- That control service is reachable from inside the sandbox. The sandboxed agent process can issue a request (or invoke the Harness CLI, which talks to the same interface) to disable sandbox enforcement.
- There is no authentication, no human-in-the-loop approval, and no privilege separation gating that state change. A single command from the sandboxed context flips enforcement off.
- Once disabled, subsequent agent commands execute with the full filesystem privileges of the user running Harness — reads and writes to
~/.ssh,~/.aws,~/.config, shell startup files, git hooks, and any project on the machine are all in play.
The exploitation requirement is trivial: the agent must simply be induced to issue the command. That inducement does not need to come from the operator. Prompt injection via untrusted content — a poisoned source file, a malicious test fixture, a crafted issue or PR the agent is asked to triage — is the realistic delivery mechanism. The agent reads the file, follows the embedded instruction, calls the control interface, and the sandbox is gone. From the attacker's perspective this converts every document the agent touches into a potential workstation-compromise vector.
Exploitation Status
The flaw was publicly demonstrated by researchers; the disclosure describes a working, single-command escape. No mass in-the-wild exploitation campaign has been confirmed at the time of writing, but the barrier to weaponization is effectively zero for any threat actor already poisoning content that AI coding agents consume. Treat it as trivially exploitable and likely to be abused in targeted developer-environment intrusions and supply-chain scenarios.
Why This Matters Beyond DeepSeek
This is a structural pattern, not a one-off bug. Any agent framework where the sandboxed workload can reach the sandbox's own control plane shares this failure mode. If you run other local agent runners, audit them for the same property: can the confined process modify its own confinement? If yes, the sandbox is decorative.
Detection & Response
The highest-fidelity signals are (a) an agent-context process invoking the Harness CLI or control API to change sandbox state, (b) localhost HTTP calls to the Harness control endpoint carrying sandbox-disable semantics originating from agent child processes, and (c) Harness-spawned processes writing to paths outside the workspace after such a state change.
Sigma Rules
---
title: DeepSeek Harness Sandbox Disabled via CLI by Agent Context
id: 3f8a1c2e-7b4d-4e9a-b6f1-2c5d8e0a1b34
status: experimental
description: Detects invocation of the DeepSeek Harness CLI or configuration change that disables the agent file sandbox, particularly when issued from an agent-spawned process tree rather than an interactive operator shell.
references:
- https://thehackernews.com/2026/09/deepseek-harness-flaw-let-ai-agents.html
author: Security Arsenal
date: 2026/09/25
tags:
- attack.defense_evasion
- attack.t1562
logsource:
category: process_creation
product: linux
detection:
selection_cli:
CommandLine|contains:
- 'harness'
selection_action:
CommandLine|contains:
- 'sandbox'
selection_disable:
CommandLine|contains:
- 'disable'
- '--no-sandbox'
- 'sandbox=false'
- 'off'
condition: selection_cli and selection_action and selection_disable
falsepositives:
- Operator intentionally disabling the sandbox for debugging — validate against change tickets and interactive TTY context
level: high
---
title: Agent Process Calling Local Harness Control API to Modify Sandbox
id: 9d2e4f6a-1c3b-4d5e-8a7f-0b9c1d2e3f45
status: experimental
description: Detects HTTP clients spawned within the agent workspace issuing requests to the localhost Harness control endpoint with sandbox-related paths, consistent with self-escape from the file sandbox.
references:
- https://thehackernews.com/2026/09/deepseek-harness-flaw-let-ai-agents.html
author: Security Arsenal
date: 2026/09/25
tags:
- attack.defense_evasion
- attack.command_and_control
- attack.t1071.001
logsource:
category: process_creation
product: linux
detection:
selection_client:
Image|endswith:
- '/curl'
- '/wget'
- '/python'
- '/python3'
- '/node'
selection_target:
CommandLine|contains:
- '127.0.0.1'
- 'localhost'
- '[::1]'
selection_endpoint:
CommandLine|contains:
- 'sandbox'
- 'config'
- 'settings'
condition: selection_client and selection_target and selection_endpoint
falsepositives:
- Legitimate local development tooling querying localhost services — filter on parent process ancestry belonging to the Harness agent runtime
level: medium
---
title: Harness Agent Child Process Writing Outside Workspace
id: 5b7c9d1e-2f4a-4b6c-9d0e-1f2a3b4c5d67
status: experimental
description: Detects file writes to sensitive user and system paths by processes executing from an AI agent workspace directory, indicating sandbox escape or post-escape activity such as credential theft or persistence via shell startup files and SSH configuration.
references:
- https://thehackernews.com/2026/09/deepseek-harness-flaw-let-ai-agents.html
author: Security Arsenal
date: 2026/09/25
tags:
- attack.persistence
- attack.credential_access
- attack.t1546.004
logsource:
category: file_event
product: linux
detection:
selection_sensitive_path:
TargetFilename|contains:
- '/.ssh/'
- '/.bashrc'
- '/.zshrc'
- '/.profile'
- '/.aws/'
- '/.config/git'
- '/etc/'
- '/.git/hooks/'
selection_agent_origin:
Image|contains:
- '/harness/'
- '/workspace/'
- '/agent/'
condition: selection_sensitive_path and selection_agent_origin
falsepositives:
- Agent tasks that legitimately scaffold dotfiles inside the workspace — tune Image path filters to your actual workspace root
level: high
KQL — Microsoft Sentinel / Defender
This query hunts across both Defender endpoint telemetry (workstations onboarded to MDE) and Syslog-ingested Linux developer machines for the two core behaviors: sandbox-disable invocation and agent-context localhost control-plane calls followed by out-of-workspace writes.
let SandboxTerms = dynamic(["sandbox", "--no-sandbox", "sandbox=false"]);
let LocalControl = dynamic(["127.0.0.1", "localhost", "[::1]"]);
let SensitivePaths = dynamic(["/.ssh/", "/.bashrc", "/.zshrc", "/.aws/", "/etc/", "/.git/hooks/"]);
let AgentProc =
union isfuzzy=true
(DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where ProcessCommandLine has_any (LocalControl) and ProcessCommandLine has "sandbox"
| where FileName in~ ("curl", "wget", "python", "python3", "node")
or (ProcessCommandLine has "harness" and ProcessCommandLine has_any (SandboxTerms))
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, Source="MDE"),
(Syslog
| where TimeGenerated > ago(7d)
| where Facility == "user" or SyslogMessage has "harness"
| where SyslogMessage has_any (SandboxTerms) and SyslogMessage has "harness"
| project TimeGenerated, DeviceName=HostName, AccountName=HostIP, FileName=ProcessName, ProcessCommandLine=SyslogMessage, InitiatingProcessCommandLine="", Source="Syslog");
let Escapes = AgentProc;
Escapes
| extend EscapeTime = TimeGenerated, EscapeDevice = DeviceName;
AgentProc
| join kind=leftouter (
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any (SensitivePaths)
| where InitiatingProcessFolderPath has_any ("harness", "workspace", "agent")
| project WriteTime=TimeGenerated, DeviceName, FolderPath, FileName, InitiatingProcessCommandLine
) on $left.DeviceName == $right.DeviceName
| where isempty(WriteTime) or WriteTime between (TimeGenerated .. TimeGenerated + 2h)
| summarize FirstSeen=min(TimeGenerated), Writes=make_set_if(FolderPath, isnotempty(FolderPath)) by DeviceName, AccountName, FileName, ProcessCommandLine, Source
| order by FirstSeen desc
Run the AgentProc portion alone as a broad hunt if you lack file-event coverage; any hit on a sandbox-disable command from a non-interactive context warrants immediate triage of that workstation.
Velociraptor VQL
Use this artifact to sweep developer fleets for live evidence: Harness/agent process trees, localhost control-plane listeners, and command lines referencing sandbox state changes.
-- Hunt for DeepSeek Harness sandbox tampering and exposed local control planes
LET procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)harness|agent'
OR Exe =~ '(?i)harness'
LET sandbox_tamper = SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(sandbox.{0,20}(disable|off|false)|--no-sandbox)'
LET control_plane = SELECT Pid, Name, CommandLine,
Laddr AS LocalAddr, Lport AS LocalPort, Status
FROM netstat()
WHERE Laddr =~ '127.0.0.1|::1'
AND Status =~ 'LISTEN'
AND (CommandLine =~ '(?i)harness' OR Name =~ '(?i)harness|node|python')
SELECT * FROM procs
UNION ALL
SELECT *, NULL, NULL, NULL FROM sandbox_tamper
UNION ALL
SELECT Pid, NULL, Name, CommandLine, NULL, NULL, NULL, LocalAddr, LocalPort, Status FROM control_plane
Correlate any sandbox_tamper hits against the process tree in procs: if the tampering command's parent chain roots in the Harness agent runtime rather than an operator shell, you are looking at a self-escape event.
Remediation / Audit Script
The following Bash script audits a Linux or macOS developer workstation: it verifies the installed Harness version, checks whether the sandbox is currently enforced, greps local logs for prior disable events, and applies a network-level guardrail blocking the agent's uid from reaching the control port (adjust HARNESS_PORT to your deployment).
#!/usr/bin/env bash
# Security Arsenal - DeepSeek Harness sandbox-escape audit & hardening
# Run as root or via sudo on developer workstations.
set -euo pipefail
HARNESS_PORT="${HARNESS_PORT:-8787}" # Adjust to your Harness control-plane port
AGENT_USER="${AGENT_USER:-agent}" # Dedicated user the agent sandbox runs under (recommended)
echo "[*] Checking installed DeepSeek Harness version..."
if command -v harness >/dev/null 2>&1; then
harness --version || true
echo "[!] ACTION: Upgrade to the latest patched release from the official repo before relying on sandbox enforcement."
else
echo "[+] harness CLI not on PATH; checking for running daemon..."
fi
echo "[*] Checking for running Harness daemon and control-plane listeners..."
ss -lntp 2>/dev/null | grep -E "127.0.0.1|::1" | grep -iE "harness|node|python" || echo "[+] No obvious Harness control listener found."
echo "[*] Auditing recent logs for sandbox-disable events..."
if command -v journalctl >/dev/null 2>&1; then
journalctl --since "14 days ago" 2>/dev/null | grep -iE "harness.*sandbox.*(disable|off|false)" || echo "[+] No journal hits."
fi
grep -riE "sandbox.*(disable|off|false)" /var/log/ 2>/dev/null | grep -i harness || echo "[+] No /var/log hits."
grep -riE "sandbox.*(disable|off|false)" "$HOME/.harness" "$HOME/.local/share/harness" 2>/dev/null || echo "[+] No Harness state/log hits in home directory."
echo "[*] Verifying sandbox enforcement state..."
if [ -f "$HOME/.harness/config.json" ]; then
grep -o '"sandbox"[^,}]*' "$HOME/.harness/config.json" || true
if grep -q '"sandbox"[[:space:]]*:[[:space:]]*false' "$HOME/.harness/config.json"; then
echo "[CRITICAL] Sandbox is DISABLED in Harness config. Re-enable immediately and investigate how it was turned off."
fi
else
echo "[-] Harness config not found at ~/.harness/config.json - check your install path."
fi
echo "[*] Applying guardrail: block the agent user from reaching the local control port..."
if command -v iptables >/dev/null 2>&1 && id "$AGENT_USER" >/dev/null 2>&1; then
iptables -C OUTPUT -m owner --uid-owner "$AGENT_USER" -p tcp -d 127.0.0.1 --dport "$HARNESS_PORT" -j REJECT 2>/dev/null \
|| iptables -A OUTPUT -m owner --uid-owner "$AGENT_USER" -p tcp -d 127.0.0.1 --dport "$HARNESS_PORT" -j REJECT
echo "[+] iptables rule installed: uid $AGENT_USER cannot reach 127.0.0.1:$HARNESS_PORT"
echo " Persist via iptables-save / netfilter-persistent, or your configuration manager."
else
echo "[-] Skipped firewall rule (iptables missing or agent user not present)."
echo " Alternative: run Harness inside a container with no host loopback access to the control plane."
fi
echo "[*] Done. Investigate any CRITICAL findings as potential sandbox-escape incidents."
Remediation
- Upgrade DeepSeek Harness immediately. Pull the latest release from the official DeepSeek Harness GitHub repository and confirm via its security advisories that the sandbox self-disable issue is addressed. If your deployment pins a version, update the pin and redeploy across the developer fleet — this is a workstation-fleet patch, not a server patch, so use your MDM/software distribution channel rather than waiting for developers to self-update.
- Treat sandbox-state changes as privileged operations. Until a vendor fix is confirmed, deploy the compensating control that matters most: prevent the sandboxed context from reaching the control plane. Run the agent under a dedicated uid and use host firewall rules (per the script above) or container network namespaces so the agent cannot reach the Harness control port. Ideally, the daemon should bind a Unix socket with filesystem permissions excluding the agent uid.
- Do not run agents against untrusted content on bare-metal developer workstations while unpatched. Move Harness execution into a disposable container or VM with no mounted credentials, no host Docker socket, and egress filtering. The sandbox was your only file-write barrier and it is currently agent-controlled.
- Hunt for prior abuse. Run the KQL query and VQL artifact above across your fleet covering at least the last 14 days. Any non-operator sandbox-disable event is an incident: image the workstation, rotate every credential reachable from that user's home directory (SSH keys, cloud CLI tokens, git credentials, kubeconfigs), and review shell startup files and git hooks for persistence.
- Institute human-in-the-loop gates. Configure agent workflows so that any action outside the workspace requires explicit operator approval, and alert on its absence. An agent that can silently escalate its own privileges will eventually be told to do so by injected content.
- Audit your other agent frameworks for the same structural flaw: can the confined workload modify its own confinement? File this under your AI/LLM security review for every agentic tool in the environment — this class of defect will recur across the ecosystem.
- Update your threat model. Add 'prompt injection → agent self-escape → developer workstation compromise → source code / CI/CD access' as a named kill chain in your IR playbooks. The downstream value of a developer workstation (signing keys, deployment credentials, internal repo access) makes this a supply-chain-grade risk, not a local nuisance.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.