High, CVSS 8.1GoPublished
Dagu has an incomplete fix for CVE-2026-27598: path traversal via %2F-encoded slashes in locateDAG
CVE-2026-33344 · GHSA-ph8x-4jfv-v9v8
- Affected
- Go github.com/dagu-org/dagu >= 1.30.4-0.20260221021317-e2ed589105d7, < 1.30.4-0.20260319093346-7d07fda8f9de
- Fixed in
- 1.30.4-0.20260319093346-7d07fda8f9de· Vendor fix available
- Issue
- The fix for CVE-2026-27598 (commit e2ed589, PR #1691) added ValidateDAGName to CreateNewDAG and rewrote generateFilePath to use filepath.Base. This patched the CREATE path. The remaining API endpoints - GET, DELETE, RENAME, EXECUTE - all pass the {fileName} URL path parameter to locateDAG without calling ValidateDAGName. %2F-encoded forward slashes in the {fileName} segment traverse outside the DAGs directory. Vulnerable code internal/persis/filedag/store.go, lines 508-513: findDAGFile resolves the path with filepath.Abs and checks only that the file exists with a YAML extension. No containment check against baseDir. Chi v5 routes using r.URL.RawPath when set. The pattern /dags/{fileName}/spec captures ..%2F..%2Fetc%2Ftarget.yaml as a single path segment. The oapi-codegen runtime calls url.PathUnescape, producing ../../etc/target.yaml. This decoded string reaches locateDAG with the / separator intact. Go's net/http.ServeMux would normally redirect paths containing .., but dagu binds…
Recommended action: Upgrade to 1.30.4-0.20260319093346-7d07fda8f9de (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.