Publish GHSA-6qr9-g2xw-cw92

Author: advisory-database[bot]

advisories/github-reviewed/2026/02/GHSA-6qr9-g2xw-cw92/GHSA-6qr9-g2xw-cw92.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-6qr9-g2xw-cw92",
-  "modified": "2026-02-19T22:04:39Z",
+  "modified": "2026-02-20T21:44:24Z",
   "published": "2026-02-19T22:04:39Z",
   "aliases": [],
   "summary": "Dagu affected by unauthenticated RCE via inline DAG spec in default configuration",
-  "details": "### Summary\n\nDagu's default configuration ships with authentication completely disabled. The `POST /api/v2/dag-runs` endpoint accepts an inline YAML spec and executes its shell commands immediately — no credentials, no token, nothing. Any dagu instance reachable over the network is fully compromised by default. A second issue means that even with auth properly configured, operator-role users can still execute arbitrary commands by submitting inline specs through the same endpoint.\n\n### Details\n\n**Finding 1 — Unauthenticated RCE (default config)**\n\n`internal/service/app/config/loader.go:226` sets `AuthModeNone` as the default. With no auth mode configured, `internal/frontend/api/v2/handlers/api.go:520` returns nil from `requireExecute()` — all permission checks pass without a valid session.\n\nThe `POST /api/v2/dag-runs` endpoint accepts a `spec` field containing a full YAML DAG definition. The spec is loaded, the steps are parsed, and the commands execute immediately on the host. There is no validation of the spec content beyond YAML parsing.\n\nTested on `ghcr.io/dagu-org/dagu:latest` — the endpoint responds with a `dagRunId` and the command runs within milliseconds.\n\n**Finding 2 — Operator role privilege escalation (auth-enabled instances)**\n\n`internal/frontend/api/v2/handlers/dagruns.go:56` guards the dag-runs endpoint with `requireExecute()`. The operator role has `CanExecute=true` but `CanWrite=false` (`internal/auth/role.go:63-69`) — operators are supposed to run existing DAGs, not create new ones.\n\nBut submitting an inline spec to `POST /api/v2/dag-runs` is effectively a create-and-execute operation. The endpoint never calls `requireDAGWrite()`. So an operator can paste arbitrary shell commands into the spec field and execute them — the same result as admin — while being correctly blocked from `POST /api/v2/dags`. This applies even when authentication is fully enabled and correctly configured.\n\n**Finding 3 — Backtick command injection in step parameters**\n\n`internal/cmn/eval/substitute.go:57-78` evaluates backtick-delimited expressions in step parameter values by passing them to `sh -c`. There is no sanitization on parameter values before they reach this function. Any user who can trigger a DAG run with custom parameters can inject arbitrary commands via backtick substitution.\n\n### PoC\n\nFinding 1 — no credentials needed, works on any default install:\n\n```bash\ncurl -s -X POST http://TARGET:8080/api/v2/dag-runs \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"name\":\"poc\",\"spec\":\"steps:\\n  - name: rce\\n    command: id > /tmp/pwned\\n\"}'\n\n# Response: {\"dagRunId\":\"<uuid>\"}\n# /tmp/pwned contains: uid=1000(dagu) gid=1000(dagu) groups=1000(dagu)\n```\n\nTested and confirmed on the default Docker image with no configuration changes.\n\n### Impact\n\nEvery dagu deployment using default settings — which is every Docker deployment, every install following the documentation, and every instance without explicit `DAGU_AUTH_MODE` configuration — is fully compromised without credentials. An attacker with network access gets OS command execution as the dagu process user and access to everything the process can reach.\n\nFinding 2 means the problem doesn't fully go away by enabling auth. Operator-level accounts can still escalate to arbitrary command execution regardless of the auth configuration.",
+  "details": "### Summary\nDagu's default configuration ships with authentication disabled. The `POST /api/v2/dag-runs` endpoint accepts an inline YAML spec and executes its shell commands immediately with no credentials required — any dagu instance reachable over the network is fully compromised by default.\n\n### Details\n`internal/service/app/config/loader.go:226` sets `AuthModeNone` as the default. With no auth mode configured, `internal/frontend/api/v2/handlers/api.go:520` returns `nil` from `requireExecute()` — all permission checks pass without a valid session.\n\nThe `POST /api/v2/dag-runs` endpoint accepts a `spec` field containing a full YAML DAG definition. The spec is parsed and the commands execute immediately on the host with no validation beyond YAML parsing.\n\n### PoC\n```bash\ncurl -s -X POST http://TARGET:8080/api/v2/dag-runs \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"name\":\"poc\",\"spec\":\"steps:\\n  - name: rce\\n    command: id > /tmp/pwned\\n\"}'\n# Response: {\"dagRunId\":\"<uuid>\"}\n# /tmp/pwned contains: uid=1000(dagu) gid=1000(dagu)\n```\nConfirmed on `ghcr.io/dagu-org/dagu:latest` with no configuration changes.\n\n### Impact\nEvery dagu deployment using default settings — every Docker deployment, every install following the documentation, every instance without explicit `DAGU_AUTH_MODE` configuration — is fully compromised without credentials. An attacker with network access gets OS command execution as the dagu process user.",
   "severity": [
     {
       "type": "CVSS_V3",