Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-6qr9-g2xw-cw92

CRITICAL

Dagu affected by unauthenticated RCE via inline DAG spec in default configuration

Also known asGO-2026-4527
Published
Feb 19, 2026
Updated
Feb 23, 2026
Affected
1 pkg
Patched
None yet
Exploits
None indexed

Blast Radius

1 pkg affected
🐹github.com/dagu-org/dagu

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Dagu'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.

Details

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.

The 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.

PoC

curl -s -X POST http://TARGET:8080/api/v2/dag-runs \
  -H "Content-Type: application/json" \
  -d '{"name":"poc","spec":"steps:\n  - name: rce\n    command: id > /tmp/pwned\n"}'
# Response: {"dagRunId":"<uuid>"}
# /tmp/pwned contains: uid=1000(dagu) gid=1000(dagu)

Confirmed on ghcr.io/dagu-org/dagu:latest with no configuration changes.

Impact

Every 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.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/dagu-org/daguall versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/dagu-org/dagu. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Remediation status

    No patched version of github.com/dagu-org/dagu has shipped for GHSA-6qr9-g2xw-cw92 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-6qr9-g2xw-cw92 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-6qr9-g2xw-cw92. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Dagu'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. ### Details `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. The `POST /api/v2/dag-runs` endpoint accep
O3 Security · Impact-Aware SCA

Is GHSA-6qr9-g2xw-cw92 in your dependencies?

O3 detects GHSA-6qr9-g2xw-cw92 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.