Every CVE Search/ Get API key

CVE-2026-31886

Dagu has a Path Traversal via `dagRunId` in Inline DAG Execution

9.1 Critical

Dagu is a workflow engine with a built-in Web user interface. Prior to 2.2.4, the dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to. With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service. This vulnerability is fixed in 2.2.4.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
Low
User interaction
None

What an attacker can affect

Confidentiality
Low
Integrity
Low
Availability
High

Exploit likelihood

0.44%Up 0.4 points since Mar 14, 2026
90%50%10%1%

What each source reports

CVE List Score used 9.1

Dagu has a Path Traversal via `dagRunId` in Inline DAG Execution

Dagu is a workflow engine with a built-in Web user interface. Prior to 2.2.4, the dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to. With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service. This vulnerability is fixed in 2.2.4.

Record
CVE-2026-31886
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Weakness
CWE-22
Updated
2026-11-02
EUVDEUVD-2026-12089 9.1

Dagu is a workflow engine with a built-in Web user interface. Prior to 2.2.4, the dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to. With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service. This vulnerability is fixed in 2.2.4.

Record
EUVD-2026-12089
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Updated
2026-11-02
GitHub AdvisoriesGHSA-m4q3-457p-hh2x 9.1

Dagu: Path Traversal via `dagRunId` in Inline DAG Execution

1. Vulnerability Summary

The dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to.

With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service.

2. This Is Not a Duplicate of Existing Advisories

Two security advisories are already published for dagu. This vulnerability is distinct from both.

GHSA-6qr9-g2xw-cw92 fixed the fact that the default authentication mode was none, allowing unauthenticated access to the inline execution endpoint. That advisory covers authentication bypass. The dagRunId path traversal described here is a separate input-validation flaw in loadInlineDAG() that exists regardless of whether authentication is required and was not addressed by that fix.

CVE-2026-27598 fixed a path traversal in the DAG creation endpoint (POST /api/v1/dags) via the name field. The fix added filepath.Base() and a base-directory prefix check inside generateFilePath(). That fix applies only to generateFilePath() in dags.go. The function loadInlineDAG() in dagruns.go has no equivalent guard on its dagRunID argument and was not part of that patch.

3. Vulnerable Code

File: internal/service/frontend/api/v1/dagruns.go

The loadInlineDAG function (lines 202-267) constructs the temp directory at line 234:

tmpDir := filepath.Join(os.TempDir(), nameHint, dagRunID)

dagRunID is user-supplied. No validation of the value occurs before this line. The cleanup closure is then registered:

cleanup := func() {
    _ = os.RemoveAll(tmpDir)
}

In ExecuteDAGRunFromSpec (lines 52-119), the cleanup is deferred unconditionally:

dag, cleanup, err := a.loadInlineDAG(ctx, request.Body.Spec, request.Body.Name, dagRunId)
if err != nil {
    return nil, err
}
defer cleanup()  // registered after loadInlineDAG succeeds; fires on all subsequent return paths

The same pattern appears in EnqueueDAGRunFromSpec (lines 122-200), line 160:

defer cleanup()

Why the OpenAPI schema pattern does not prevent this:

The DAGRunId schema in api/v1/api.yaml (line 5738) declares:

pattern: "^[a-zA-Z0-9_-]+$"

This pattern excludes . and /, which would block path traversal values. However, enforcement of that pattern depends on the OpenAPI validator middleware, which is only activated when StrictValidation is true. That setting is defined in internal/cmn/config/config.go:

StrictValidation  bool

It is not present in the Definition struct (definition.go) and carries no mapstructure tag, which means viper/mapstructure can never populate it from a YAML configuration file; it therefore cannot be set in the config loader (loader.go) and its value is always the Go zero value for bool, which is false. The loader test at line 165 of loader_test.go confirms that StrictValidation is false even after loading a comprehensive configuration file that exercises every configurable option — because there is no mechanism by which it could ever be true. The validator middleware is never registered for any standard dagu deployment.

The file dagruns.go defines a sanitizeFilename helper at line 36 that replaces…

Record
GHSA-m4q3-457p-hh2x
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Weakness
CWE-22
Updated
2026-11-02
NVD 9.1

Dagu is a workflow engine with a built-in Web user interface. Prior to 2.2.4, the dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to. With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service. This vulnerability is fixed in 2.2.4.

Record
CVE-2026-31886
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
CVSS 3.1
7.6 HighCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
Weakness
CWE-22
Updated
2026-11-02
OSV 9.1

Dagu has a Path Traversal via `dagRunId` in Inline DAG Execution

Dagu is a workflow engine with a built-in Web user interface. Prior to 2.2.4, the dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to. With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service. This vulnerability is fixed in 2.2.4.

Record
CVE-2026-31886
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Weakness
CWE-22
Updated
2026-11-02
OSVGHSA-m4q3-457p-hh2x 9.1

Dagu: Path Traversal via `dagRunId` in Inline DAG Execution

1. Vulnerability Summary

The dagRunId request field accepted by the inline DAG execution endpoints is passed directly into filepath.Join to construct a temporary directory path without any format validation. Go's filepath.Join resolves .. segments lexically, so a caller can supply a value such as ".." to redirect the computed directory outside the intended /tmp/<name>/<id> path. A deferred cleanup function that calls os.RemoveAll on that directory then runs unconditionally when the HTTP handler returns, deleting whatever directory the traversal resolved to.

With dagRunId set to "..", the resolved directory is the system temporary directory (/tmp on Linux). On non-root deployments, os.RemoveAll("/tmp") removes all files in /tmp owned by the dagu process user, disrupting every concurrent dagu run that has live temp files. On root or Docker deployments, the call removes the entire contents of /tmp, causing a system-wide denial of service.

2. This Is Not a Duplicate of Existing Advisories

Two security advisories are already published for dagu. This vulnerability is distinct from both.

GHSA-6qr9-g2xw-cw92 fixed the fact that the default authentication mode was none, allowing unauthenticated access to the inline execution endpoint. That advisory covers authentication bypass. The dagRunId path traversal described here is a separate input-validation flaw in loadInlineDAG() that exists regardless of whether authentication is required and was not addressed by that fix.

CVE-2026-27598 fixed a path traversal in the DAG creation endpoint (POST /api/v1/dags) via the name field. The fix added filepath.Base() and a base-directory prefix check inside generateFilePath(). That fix applies only to generateFilePath() in dags.go. The function loadInlineDAG() in dagruns.go has no equivalent guard on its dagRunID argument and was not part of that patch.

3. Vulnerable Code

File: internal/service/frontend/api/v1/dagruns.go

The loadInlineDAG function (lines 202-267) constructs the temp directory at line 234:

tmpDir := filepath.Join(os.TempDir(), nameHint, dagRunID)

dagRunID is user-supplied. No validation of the value occurs before this line. The cleanup closure is then registered:

cleanup := func() {
    _ = os.RemoveAll(tmpDir)
}

In ExecuteDAGRunFromSpec (lines 52-119), the cleanup is deferred unconditionally:

dag, cleanup, err := a.loadInlineDAG(ctx, request.Body.Spec, request.Body.Name, dagRunId)
if err != nil {
    return nil, err
}
defer cleanup()  // registered after loadInlineDAG succeeds; fires on all subsequent return paths

The same pattern appears in EnqueueDAGRunFromSpec (lines 122-200), line 160:

defer cleanup()

Why the OpenAPI schema pattern does not prevent this:

The DAGRunId schema in api/v1/api.yaml (line 5738) declares:

pattern: "^[a-zA-Z0-9_-]+$"

This pattern excludes . and /, which would block path traversal values. However, enforcement of that pattern depends on the OpenAPI validator middleware, which is only activated when StrictValidation is true. That setting is defined in internal/cmn/config/config.go:

StrictValidation  bool

It is not present in the Definition struct (definition.go) and carries no mapstructure tag, which means viper/mapstructure can never populate it from a YAML configuration file; it therefore cannot be set in the config loader (loader.go) and its value is always the Go zero value for bool, which is false. The loader test at line 165 of loader_test.go confirms that StrictValidation is false even after loading a comprehensive configuration file that exercises every configurable option — because there is no mechanism by which it could ever be true. The validator middleware is never registered for any standard dagu deployment.

The file dagruns.go defines a sanitizeFilename helper at line 36 that replaces…

Record
GHSA-m4q3-457p-hh2x
CVSS 3.1
9.1 CriticalCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H
Weakness
CWE-22
Updated
2026-11-02
OSVGO-2026-4693 No score

Dagu: Path Traversal via `dagRunId` in Inline DAG Execution in github.com/dagu-org/dagu

Dagu: Path Traversal via dagRunId in Inline DAG Execution in github.com/dagu-org/dagu

Record
GO-2026-4693
Updated
2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
  • GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
  • GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
  • GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
  • GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
  • GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
  • GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
  • GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
  • GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
  • GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
  • GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
  • GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
  • GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
  • GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
  • GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
  • GO-2026-5933 GHSA-3g4q-2f67-2gvh
  • GO-2026-5934 GHSA-59qp-cfj3-rp64
  • GO-2026-5935 GHSA-7856-g3gv-9wq8
  • GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
  • GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
  • GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
  • GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
  • GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
  • GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
  • GO-2026-5942 CVE-2026-46600
  • GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
  • GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
  • GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
  • GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
  • GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
  • GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
  • GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
  • GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
  • GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
  • GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
  • GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
  • GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
  • GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
  • GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
  • GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
  • GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
  • GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
  • GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
  • GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
  • GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
  • GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
  • GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
  • GO-2026-5969 GHSA-g936-7jqj-mwv8
  • GO-2026-5970 CVE-2026-56852
  • GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
  • GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
  • GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
  • GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
  • GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
  • GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
  • GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
  • GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
  • GO-2026-5981 GHSA-mqxv-9rm6-w8qc
  • GO-2026-5982 GHSA-pqg7-v6wh-3pfp
  • GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
  • GO-2026-5985 GHSA-7rx3-5wx3-5v76
  • GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
  • GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
  • GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
  • GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
  • GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
  • GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
  • GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
  • GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
  • GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
  • GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
  • GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
  • GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
  • GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
  • GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
  • GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
  • GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
Record
openSUSE-SU-2026:21483-1
Updated
2026-11-02
OSVSUSE-SU-2026:1042-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260317T205859 2026-03-17T20:58:59Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:
    • GO-2026-4360 CVE-2026-0528 GHSA-w2gr-585j-r428
    • GO-2026-4513
    • GO-2026-4514
    • GO-2026-4518
    • GO-2026-4526
    • GO-2026-4549 CVE-2026-24005 GHSA-9fj4-3849-rv9g
    • GO-2026-4550 CVE-2026-1229 GHSA-q9hv-hpm4-hj6x
    • GO-2026-4551 CVE-2026-27575 GHSA-3ccg-x393-96v8
    • GO-2026-4552 CVE-2026-27116 GHSA-4qgr-4h56-8895
    • GO-2026-4553 CVE-2026-27616 GHSA-7jp5-298q-jg98
    • GO-2026-4554 CVE-2026-27730 GHSA-p2v6-84h2-5x4r
    • GO-2026-4556 CVE-2026-27819 GHSA-42wg-38gx-85rh
    • GO-2026-4557 CVE-2026-26186 GHSA-49xw-vfc4-7p43
    • GO-2026-4558 CVE-2026-27808 GHSA-mpf7-p9x7-96r3
    • GO-2026-4560 CVE-2026-27465 GHSA-2v6m-6xw3-6467
    • GO-2026-4561 CVE-2026-25963 GHSA-5jvp-m9h4-253h
    • GO-2026-4562 CVE-2026-27900 GHSA-5rc7-2jj6-mp64
    • GO-2026-4563 CVE-2026-24004 GHSA-9pm7-6g36-6j78
    • GO-2026-4564 CVE-2026-23999 GHSA-ppwx-5jq7-px2w
    • GO-2026-4565 CVE-2026-22728 GHSA-465p-v42x-3fmj
    • GO-2026-4566 CVE-2026-27899 GHSA-5rmx-256w-8mj9
    • GO-2026-4567 CVE-2026-27965 GHSA-8g8j-r87h-p36x
    • GO-2026-4568 GHSA-gj6x-q8rh-wj6x
    • GO-2026-4569 CVE-2026-27896 GHSA-wvj2-96wp-fq3f
    • GO-2026-4570 CVE-2026-27969 GHSA-r492-hjgh-c9gw
    • GO-2026-4571 CVE-2026-27734 GHSA-phwh-4f42-gwf3
    • GO-2026-4572 CVE-2026-27946 GHSA-282g-fhmx-xf54
    • GO-2026-4573 CVE-2026-27840 GHSA-6mq3-xmgp-pjm5
    • GO-2026-4574 CVE-2026-27945 GHSA-7777-fhq9-592v
    • GO-2026-4575 CVE-2026-28268 GHSA-rfjg-6m84-crj2
    • GO-2026-4576 CVE-2026-28280 GHSA-4rv8-5cmm-2r22
    • GO-2026-4577 CVE-2026-28407 GHSA-945p-3jhm-6rcp
    • GO-2026-4578 CVE-2025-14443 GHSA-gxvv-45f6-3ch8
    • GO-2026-4579 CVE-2026-28279 GHSA-rchw-322g-f7rm
    • GO-2026-4580 CVE-2026-28406 GHSA-6rxq-q92g-4rmf
    • GO-2026-4581 GHSA-xfx2-prg5-jq3g
    • GO-2026-4583 GHSA-54p8-x2m9-c593
    • GO-2026-4584 CVE-2026-28342 GHSA-pc8g-78pf-4xrp
    • GO-2026-4585 CVE-2026-28492 GHSA-mr74-928f-rw69
    • GO-2026-4586 CVE-2026-28789 GHSA-45m3-398w-m2m9
    • GO-2026-4587 CVE-2026-28790 GHSA-4fqm-6fmh-82mq
    • GO-2026-4588 CVE-2026-29049 GHSA-7rp8-r62p-q6wc
    • GO-2026-4589 CVE-2021-25320 GHSA-gqf8-rvrh-g7w6
    • GO-2026-4590 GHSA-hwm2-4ph6-w6m5
    • GO-2026-4591 CVE-2025-62879 GHSA-wj3p-5h3x-c74q
    • GO-2026-4592 CVE-2026-29073 GHSA-jqwg-75qf-vmf9
    • GO-2026-4593 CVE-2026-26998 GHSA-fw45-f5q2-2p4x
    • GO-2026-4594 CVE-2026-26999 GHSA-xw98-5q62-jx94
    • GO-2026-4595 CVE-2026-3351 GHSA-crmg-9m86-636r
    • GO-2026-4596 CVE-2026-29183 GHSA-6865-qjcf-286f
    • GO-2026-4597 CVE-2026-29054 GHSA-92mv-8f8w-wq52
    • GO-2026-4598 CVE-2026-29042 GHSA-95fj-3w7g-4r27
    • GO-2026-4599 CVE-2026-27137
    • GO-2026-4600 CVE-2026-27138
    • GO-2026-4601 CVE-2026-25679
    • GO-2026-4602 CVE-2026-27139
    • GO-2026-4603 CVE-2026-27142
    • GO-2026-4604 CVE-2026-29193 GHSA-25rw-g6ff-fmg8
    • GO-2026-4605 CVE-2026-29192 GHSA-6rx5-m2rc-hmf7
    • GO-2026-4606 CVE-2026-29188 GHSA-79pf-vx4x-7jmm
    • GO-2026-4607 CVE-2026-29191 GHSA-pr34-2v5x-6qjq
    • GO-2026-4608 CVE-2026-29771 GHSA-rhr9-hgcm-x289
    • GO-2026-4609 CVE-2026-29781 GHSA-hx52-cv84-jr5v
    • GO-2026-4610 CVE-2025-15558 GHSA-p436-gjf2-799p
    • GO-2026-4612 CVE-2026-28683 GHSA-3c22-5j5m-4jq7
    • GO-2026-4613 CVE-2026-28682 GHSA-c36c-7pc2-f2ph
    • GO-2026-4614 CVE-2026-27944 GHSA-g9w5-qffc-6762
    • GO-2026-4615 CVE-2026-29060 GHSA-m2hx-wjxc-9fp4
    • GO-2026-4616 CVE-2026-25921 GHSA-cj4v-437j-jq4c
    • GO-2026-4617 CVE-2026-26194 GHSA-v9vm-r24h-6rqm
    • GO-2026-4618 CVE-2026-26195 GHSA-vgvf-m4fw-938j
    • GO-2026-4619 CVE-2026-26196 GHSA-x9p5-w45c-7ffc
    • GO-2026-4620 CVE-2026-26022 GHSA-xrcr-gmf5-2r8j
    • GO-2026-4621 GHSA-fwhj-785h-43hh
    • GO-2026-4622 CVE-2026-30223 GHSA-g962-2j28-3cg9
    • GO-2026-4623 CVE-2026-30224 GHSA-gq2m-77hf-vwgh
    • GO-2026-4624 CVE-2026-29084 GHSA-hcff-qv74-7hr4
    • GO-2026-4625 CVE-2026-30225 GHSA-p443-p7w5-2f7f
    • GO-2026-4626 CVE-2026-29061…
Record
SUSE-SU-2026:1042-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/dagu-org/dagu
Go
 through 2.2.4 None known
github.com/dagu-org/dagu
Go
 All versions None known
govulncheck-vulndb
openSUSE:Leap 15.6
From an advisory covering 124 CVEs
 before 0.0.20260317T205859-150000.1.152.1
0.0.20260317T205859-150000.1.152.1
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 1734 CVEs
 before 0.0.20260723T184607-160000.1.1
0.0.20260723T184607-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-31886 is a critical vulnerability (CVSS 9.1) in Dagu, published March 13, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.44%, the 38th percentile. No source names a fixed version.

References

Show 194 moreShow less
This page doesn't list everything

Left out here: 1,542 references and the rest of 4 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open