CVE-2026-33344: 
Homebrew vulnerability analysis and mitigation

CVE-2026-33344 is a path traversal vulnerability in dagu, an open-source DAG-based workflow orchestration tool, representing an incomplete fix for the previously patched CVE-2026-27598. The prior fix (commit e2ed589, PR #1691) added ValidateDAGName only to the CreateNewDAG endpoint, leaving the GET, DELETE, RENAME, and EXECUTE API endpoints unprotected. Affected versions are dagu v2.0.0 through v2.3.0; the issue is patched in v2.3.1. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Dagu Security Advisory).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The vulnerable locateDAG function in internal/persis/filedag/store.go (lines 508–513) checks whether the input contains a filepath separator and, if so, calls findDAGFile, which resolves the path with filepath.Abs and only verifies the file has a YAML extension — with no containment check against the base DAGs directory. The chi v5 router captures %2F-encoded forward slashes as a single path segment via r.URL.RawPath; the oapi-codegen runtime then calls url.PathUnescape, delivering a decoded traversal string (e.g., ../../etc/passwd) directly to locateDAG. Go's net/http.ServeMux path-cleaning redirect does not fire because dagu binds the chi mux directly to &http.Server{Handler: r}. The fix (commit 7d07fda, PR #1803) introduces a validateDAGFileNameMiddleware applied to all API endpoints that calls core.ValidateDAGName on the FileName field before any handler logic executes (GitHub Advisory, Fix Commit).

A low-privileged authenticated attacker can read any .yaml or .yml file accessible to the dagu process on the server filesystem, including Kubernetes secrets, application configuration files, and other sensitive YAML-formatted data. The DELETE endpoint allows arbitrary deletion of such files, causing data loss or service disruption. Additionally, the POST /dags/{fileName}/start execute endpoint can load an arbitrary YAML file as a DAG definition; if the target file contains valid DAG syntax with shell commands, those commands execute as the dagu process user, enabling potential remote code execution. Deployments with auth.mode=none or pre-v2.0.0 configurations are exploitable without any credentials (Dagu Security Advisory).

A proof-of-concept (PoC) is publicly documented in the GitHub security advisory, providing concrete HTTP-level attack steps including exact crafted URLs (e.g., GET /dags/..%2F..%2Fetc%2Ftarget.yaml/spec) with confirmed HTTP 200 responses. No evidence of in-the-wild exploitation has been reported as of the time of writing. The EPSS score is approximately 0.016% (0.031% per the advisory), indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No specific threat actor attribution has been identified (Dagu Security Advisory, GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible dagu instances running versions v2.0.0–v2.3.0. Check for the presence of the dagu web UI or API (default port 8080) using tools like Shodan, Censys, or direct network scanning.
2. Authentication: Obtain low-privileged credentials for the dagu instance. If auth.mode=none is configured, no credentials are required. Authentication has been enabled by default since v2.0.0 (PR #1688), but any valid user account suffices.
3. Craft traversal URL: Construct a request with %2F-encoded path separators in the {fileName} segment to traverse outside the DAGs directory. For example, to read /etc/passwd: GET /api/v1/dags/..%2F..%2Fetc%2Fpasswd/spec.
4. Send request: Issue the crafted HTTP request to the dagu server. The chi router captures the encoded segment as a single path token; oapi-codegen decodes %2F to /, and locateDAG resolves the resulting path without boundary checks, returning the file contents with HTTP 200.
5. Arbitrary file deletion: Replace GET .../spec with DELETE /api/v1/dags/..%2F..%2Fpath%2Fto%2Ftarget to delete any accessible .yaml/.yml file.
6. Remote code execution (conditional): Use POST /api/v1/dags/..%2F..%2Fpath%2Fto%2Fmalicious.yaml/start pointing to a YAML file containing valid dagu DAG syntax with shell commands. If the file is loaded successfully, the commands execute as the dagu process user (Dagu Security Advisory).

• Network: HTTP GET/DELETE/POST requests to dagu API endpoints (e.g., /api/v1/dags/) containing %2F in the {fileName} path segment (e.g., ..%2F..%2F); unusual outbound connections from the dagu server process following a POST to a /start endpoint.
• Logs: Dagu access logs showing requests to paths like /api/v1/dags/..%2F..%2Fetc%2F*/spec or /api/v1/dags/..%2F..%2F*/start returning HTTP 200; log entries referencing YAML files outside the configured DAGs base directory.
• File System: Missing .yaml/.yml files outside the DAGs directory that were previously present (indicating exploitation of the DELETE endpoint); unexpected execution of shell commands or processes spawned by the dagu process user.
• Process: Unusual child processes (e.g., /bin/sh, curl, wget) spawned by the dagu server process, potentially indicating successful workflow execution via a traversed YAML file (Dagu Security Advisory).

Upgrade dagu to version v2.3.1 or later, which introduces a validateDAGFileNameMiddleware applied globally to all API endpoints, calling core.ValidateDAGName on the FileName parameter before any handler logic executes (commit 7d07fda, PR #1803). No configuration-based workaround fully mitigates the issue; restricting network access to the dagu API to trusted users only can reduce exposure as a temporary measure. Organizations using auth.mode=none should enable authentication immediately and restrict API access to the minimum required user set (Fix Commit, Dagu Security Advisory).

The vulnerability was reported by researcher vnykmshr and published by dagu maintainer yohamta0 on March 19, 2026. A Mastodon post from @thehackerwire noted the disclosure shortly after publication. The openSUSE security announcement list also referenced the issue in the context of Go vulnerability database updates. No significant broader media coverage or notable community debate has been identified beyond standard CVE tracking and aggregation sites (Dagu Security Advisory).