Dagu's MCP tools reopen a patched path traversal flaw
An advisory published on 10 November 2026 says the workflow engine's agent interface skips the HTTP middleware that blocks arbitrary YAML file reads.
By The Agentic Times ·

A fix for a path traversal bug in the Dagu workflow scheduler can be bypassed through the project's Model Context Protocol service, according to a GitHub security advisory published on 10 November 2026. The issue, tracked as CVE-2026-102943, affects the Go package github.com/dagu-org/dagu/v2 and lets a caller with a viewer-role API key read YAML files from anywhere on the host, outside the configured workspace.
The advisory describes the problem as a residual of an earlier fix. The patch for CVE-2026-33344 was written as HTTP middleware, a piece of code that inspects incoming web requests before they reach the application. It checks a request field named FileName and rejects anything that is not a plain file name. According to the advisory, that middleware is installed in exactly one place: the chi strict-handler chain used for the REST interface.
Dagu's MCP service, which exposes the same functionality to AI agents, does not use that chain. The advisory says the MCP server calls the GetDAGSpec API method directly as an in-process Go function call. Because no HTTP request is ever constructed, no middleware runs, and the underlying file resolver is reached unguarded. That resolver, locateDAG, takes any string containing a path separator and hands back the file it finds, with no check that the result sits under the base directory or a configured search path. An absolute path contains a separator, so it passes straight through.
The reporter says the behaviour was verified end to end against a running HTTP server using the project's own conformance and MCP test harness, rather than by reading the source. A dagu_read call naming an absolute path outside the workspace returned HTTP 200 with the full file contents in the response. The same request succeeded with a viewer-role API key on a server with built-in authentication enabled, so it is not limited to administrators. A control test confirmed that the equivalent REST request is still correctly rejected with a 400 error. The advisory says the finding was confirmed at commit f6c039f, after release v2.10.7.
The impact is bounded. The advisory states the flaw is read-only and limited to .yaml and .yml targets, and that the dagu_change and dagu_execute tools were both tested and found to be blocked by name validation at the specification level. As a secondary issue, GetDAGSpec skips the requireWorkspaceVisible check that neighbouring handlers perform, so the read also crosses workspace isolation boundaries.
The suggested fix is to move the containment check out of the HTTP middleware and into locateDAG itself, rejecting any resolved path outside the base directory or search paths. The advisory argues the resolver is the correct chokepoint because both transports converge there, and that middleware covering only one of two routes into the same API cannot hold the boundary. It adds that AI assistance was used during the investigation.
Sources
- github.comhttps://github.com/advisories/GHSA-5m6c-38r8-5w76
