Common Weakness Enumeration

CWE-215

Allowed

Insertion of Sensitive Information Into Debugging Code

Abstraction: Base · Status: Draft

The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.

31 vulnerabilities reference this CWE, most recent first.

GHSA-95MQ-XWJ4-R47P

Vulnerability from github – Published: 2026-04-16 21:08 – Updated: 2026-04-16 21:08
VLAI
Summary
Dgraph: Unauthenticated /debug/pprof/cmdline discloses admin auth token, enabling unauthorized access to protected Alpha admin endpoints
Details

Summary

An unauthenticated debug endpoint in Dgraph Alpha exposes the full process command line, including the configured admin token from --security "token=...".

This does not break token validation logic directly; instead, it discloses the credential and enables unauthorized admin-level access by reusing the leaked token in X-Dgraph-AuthToken.

Details

The behavior occurs entirely within core Alpha HTTP routing and does not require any external proxy, plugin, or non-core integration.

The core issue is not that admin token protection is absent, but that the protected secret is exposed in cleartext through an unauthenticated core debug endpoint.

Relevant code paths: - dgraph/cmd/alpha/run.go:17 imports net/http/pprof, which registers /debug/pprof/* handlers on the default mux. - dgraph/cmd/alpha/run.go:533 uses http.Handle("/", audit.AuditRequestHttp(baseMux)), so default-mux handlers remain reachable. - dgraph/cmd/alpha/admin.go:52 enforces admin token checks in adminAuthHandler for admin endpoints. - dgraph/cmd/alpha/admin.go:74 shows /admin/config/cache_mb behind adminAuthHandler.

Credential-exposure chain: 1. /debug/pprof/cmdline is reachable without authentication. 2. Its output includes the configured admin token from process arguments. 3. The disclosed token is accepted by adminAuthHandler when sent as X-Dgraph-AuthToken. 4. An attacker gains unauthorized access to admin-only functionality.

Observed local evidence (safe validation): - Request: GET /admin/config/cache_mb without token - Status: 200 (request rejected at application layer) - Body contains error: Invalid X-Dgraph-AuthToken - The endpoint returns HTTP 200 but indicates authentication failure in the response body. - Request: GET /debug/pprof/cmdline without token - Status: 200 - Body excerpt includes: --security=token=TopSecretToken123; - Request: GET /admin/config/cache_mb with X-Dgraph-AuthToken: TopSecretToken123 - Status: 200 - Body: 4096

Important policy/triage clarification: - This issue persists even when the admin-token security feature is enabled: the token itself is exposed via an unauthenticated core debug endpoint, making this more than a misconfiguration-only concern. - Network restrictions (bind/whitelist/firewall) may reduce exposure, but they do not remediate the underlying credential disclosure behavior.

PoC

  • Branch: main
  • Commit: b15c87e93
  • Describe: v25.3.1

Preconditions: - Alpha HTTP port is reachable by attacker traffic. - Admin token is configured via supported startup flag: --security "token=...". - /debug/pprof/* is exposed on the same Alpha HTTP listener. - This behavior occurs with documented startup flags and without any non-default or unsupported configuration.

Reproduction steps: 1. Start Zero and Alpha (example local setup): - dgraph zero --my=127.0.0.1:5280 --port_offset=200 --bindall=false --wal=./zw - dgraph alpha --my=127.0.0.1:7280 --zero=127.0.0.1:5280 --port_offset=200 --bindall=false --security "token=TopSecretToken123;" --postings=./p --wal=./w --tmp=./t

  1. Verify admin endpoint rejects unauthenticated request:
  2. curl -i http://127.0.0.1:8280/admin/config/cache_mb
  3. Expected body includes Invalid X-Dgraph-AuthToken.

  4. Read token from unauthenticated debug endpoint:

  5. curl -s http://127.0.0.1:8280/debug/pprof/cmdline
  6. Expected output includes --security=token=TopSecretToken123;.

  7. Reuse leaked token against admin endpoint:

  8. curl -i -H "X-Dgraph-AuthToken: TopSecretToken123" http://127.0.0.1:8280/admin/config/cache_mb
  9. Expected: successful response (example observed: 4096).

Note: The PoC uses 127.0.0.1 only for safe local validation. The vulnerable condition is unauthenticated reachability of /debug/pprof/cmdline; in any deployment where Alpha HTTP is reachable by untrusted parties, the same token disclosure and subsequent unauthorized admin access apply.

Impact

  • Unauthenticated disclosure of a sensitive admin credential via debug endpoint, enabling unauthorized privileged administrative access through token reuse
  • Operators running Dgraph Alpha with admin token configured, where Alpha HTTP/debug routes are reachable by untrusted users or networks.

The attack requires network reachability to the Alpha HTTP port. In deployments where this interface is exposed beyond trusted boundaries, the issue is remotely exploitable without authentication.

Depending on exposed admin functionality in deployment policy, this may allow configuration changes, operational control actions, and other privileged administrative operations exposed through /admin/*.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dgraph-io/dgraph/v25"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "25.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dgraph-io/dgraph/v24"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "24.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dgraph-io/dgraph"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40173"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-215",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:08:07Z",
    "nvd_published_at": "2026-04-15T21:17:27Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn unauthenticated debug endpoint in Dgraph Alpha exposes the full process command line, including the configured admin token from `--security \"token=...\"`.\n\nThis does not break token validation logic directly; instead, it discloses the credential and enables unauthorized admin-level access by reusing the leaked token in `X-Dgraph-AuthToken`.\n\n### Details\nThe behavior occurs entirely within core Alpha HTTP routing and does not require any external proxy, plugin, or non-core integration.\n\nThe core issue is not that admin token protection is absent, but that the protected secret is exposed in cleartext through an unauthenticated core debug endpoint.\n\nRelevant code paths:\n- `dgraph/cmd/alpha/run.go:17` imports `net/http/pprof`, which registers `/debug/pprof/*` handlers on the default mux.\n- `dgraph/cmd/alpha/run.go:533` uses `http.Handle(\"/\", audit.AuditRequestHttp(baseMux))`, so default-mux handlers remain reachable.\n- `dgraph/cmd/alpha/admin.go:52` enforces admin token checks in `adminAuthHandler` for admin endpoints.\n- `dgraph/cmd/alpha/admin.go:74` shows `/admin/config/cache_mb` behind `adminAuthHandler`.\n\nCredential-exposure chain:\n1. `/debug/pprof/cmdline` is reachable without authentication.\n2. Its output includes the configured admin token from process arguments.\n3. The disclosed token is accepted by `adminAuthHandler` when sent as `X-Dgraph-AuthToken`.\n4. An attacker gains unauthorized access to admin-only functionality.\n\nObserved local evidence (safe validation):\n- Request: `GET /admin/config/cache_mb` without token\n  - Status: 200 (request rejected at application layer)\n  - Body contains error: `Invalid X-Dgraph-AuthToken`\n  - The endpoint returns HTTP 200 but indicates authentication failure in the response body.\n- Request: `GET /debug/pprof/cmdline` without token\n  - Status: 200\n  - Body excerpt includes: `--security=token=TopSecretToken123;`\n- Request: `GET /admin/config/cache_mb` with `X-Dgraph-AuthToken: TopSecretToken123`\n  - Status: 200\n  - Body: `4096`\n\nImportant policy/triage clarification:\n- This issue persists even when the admin-token security feature is enabled: the token itself is exposed via an unauthenticated core debug endpoint, making this more than a misconfiguration-only concern.\n- Network restrictions (bind/whitelist/firewall) may reduce exposure, but they do not remediate the underlying credential disclosure behavior.\n\n### PoC\n\n- Branch: `main`\n- Commit: `b15c87e93`\n- Describe: `v25.3.1`\n\nPreconditions:\n- Alpha HTTP port is reachable by attacker traffic.\n- Admin token is configured via supported startup flag: `--security \"token=...\"`.\n- `/debug/pprof/*` is exposed on the same Alpha HTTP listener.\n- This behavior occurs with documented startup flags and without any non-default or unsupported configuration.\n\nReproduction steps:\n1. Start Zero and Alpha (example local setup):\n   - `dgraph zero --my=127.0.0.1:5280 --port_offset=200 --bindall=false --wal=./zw`\n   - `dgraph alpha --my=127.0.0.1:7280 --zero=127.0.0.1:5280 --port_offset=200 --bindall=false --security \"token=TopSecretToken123;\" --postings=./p --wal=./w --tmp=./t`\n\n2. Verify admin endpoint rejects unauthenticated request:\n   - `curl -i http://127.0.0.1:8280/admin/config/cache_mb`\n   - Expected body includes `Invalid X-Dgraph-AuthToken`.\n\n3. Read token from unauthenticated debug endpoint:\n   - `curl -s http://127.0.0.1:8280/debug/pprof/cmdline`\n   - Expected output includes `--security=token=TopSecretToken123;`.\n\n4. Reuse leaked token against admin endpoint:\n   - `curl -i -H \"X-Dgraph-AuthToken: TopSecretToken123\" http://127.0.0.1:8280/admin/config/cache_mb`\n   - Expected: successful response (example observed: `4096`).\n\nNote: The PoC uses `127.0.0.1` only for safe local validation. The vulnerable condition is unauthenticated reachability of `/debug/pprof/cmdline`; in any deployment where Alpha HTTP is reachable by untrusted parties, the same token disclosure and subsequent unauthorized admin access apply.\n\n### Impact\n\n- Unauthenticated disclosure of a sensitive admin credential via debug endpoint, enabling unauthorized privileged administrative access through token reuse\n- Operators running Dgraph Alpha with admin token configured, where Alpha HTTP/debug routes are reachable by untrusted users or networks.\n\nThe attack requires network reachability to the Alpha HTTP port. In deployments where this interface is exposed beyond trusted boundaries, the issue is remotely exploitable without authentication.\n\nDepending on exposed admin functionality in deployment policy, this may allow configuration changes, operational control actions, and other privileged administrative operations exposed through `/admin/*`.",
  "id": "GHSA-95mq-xwj4-r47p",
  "modified": "2026-04-16T21:08:07Z",
  "published": "2026-04-16T21:08:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dgraph-io/dgraph/security/advisories/GHSA-95mq-xwj4-r47p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40173"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dgraph-io/dgraph"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dgraph-io/dgraph/releases/tag/v25.3.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dgraph: Unauthenticated /debug/pprof/cmdline discloses admin auth token, enabling unauthorized access to protected Alpha admin endpoints"
}

GHSA-FMXW-GFWM-67W3

Vulnerability from github – Published: 2026-02-11 15:30 – Updated: 2026-02-12 18:30
VLAI
Details

The /dbviewer/ web endpoint in METIS WIC devices is exposed without authentication. A remote attacker can access and export the internal telemetry SQLite database containing sensitive operational data. Additionally, the application is configured with debug mode enabled, causing malformed requests to return verbose Django tracebacks that disclose backend source code, local file paths, and system configuration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-2250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-11T15:16:17Z",
    "severity": "HIGH"
  },
  "details": "The /dbviewer/ web endpoint in METIS WIC devices is exposed without authentication. A remote attacker can access and export the internal telemetry SQLite database containing sensitive operational data. Additionally, the application is configured with debug mode enabled, causing malformed requests to return verbose Django tracebacks that disclose backend source code, local file paths, and system configuration.",
  "id": "GHSA-fmxw-gfwm-67w3",
  "modified": "2026-02-12T18:30:21Z",
  "published": "2026-02-11T15:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2250"
    },
    {
      "type": "WEB",
      "url": "https://cydome.io/vulnerability-advisory-cve-2026-2250-unauthenticated-data-exfilteration-and-information-disclosure-in-metis-wic-wireless-intelligent-collector"
    },
    {
      "type": "WEB",
      "url": "https://www.metis.tech"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MJVC-J6RV-9XJ8

Vulnerability from github – Published: 2022-02-24 00:00 – Updated: 2022-02-24 21:47
VLAI
Summary
Insertion of Sensitive Information Into Debugging Code in Microweber
Details

Microweber prior to 1.3 may expose sensitive information about a server and a user when running the server in debug mode.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "microweber/microweber"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-0721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-24T21:47:33Z",
    "nvd_published_at": "2022-02-23T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microweber prior to 1.3 may expose sensitive information about a server and a user when running the server in debug mode.",
  "id": "GHSA-mjvc-j6rv-9xj8",
  "modified": "2022-02-24T21:47:33Z",
  "published": "2022-02-24T00:00:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0721"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microweber/microweber/commit/b12e1a490c79460bff019f34b2e17112249b16ec"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/microweber/microweber"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/ae267d39-9750-4c69-be8b-4f915da089fb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Insertion of Sensitive Information Into Debugging Code in Microweber"
}

GHSA-P3X5-5XPX-9PHM

Vulnerability from github – Published: 2022-05-24 17:06 – Updated: 2023-10-05 18:45
VLAI
Summary
Kubernetes ingress exposes sensitive information
Details

Versions < 1.5 of the Kubernetes ingress default backend, which handles invalid ingress traffic, exposed prometheus metrics publicly.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/ingress-nginx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1002104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-215"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-20T00:04:43Z",
    "nvd_published_at": "2020-01-14T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Versions \u003c 1.5 of the Kubernetes ingress default backend, which handles invalid ingress traffic, exposed prometheus metrics publicly.",
  "id": "GHSA-p3x5-5xpx-9phm",
  "modified": "2023-10-05T18:45:30Z",
  "published": "2022-05-24T17:06:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1002104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/ingress-nginx/issues/1733"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/ingress-nginx/pull/3125"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/ingress-nginx/commit/d487a50e399100ad8db12ed1d2f92271f311f676"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubernetes/ingress-nginx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Kubernetes ingress exposes sensitive information"
}

GHSA-PRJ4-JP6F-VPF4

Vulnerability from github – Published: 2025-09-03 15:30 – Updated: 2026-04-01 18:36
VLAI
Details

Insertion of Sensitive Information Into Debugging Code vulnerability in Klarna Klarna Order Management for WooCommerce allows Retrieve Embedded Sensitive Data. This issue affects Klarna Order Management for WooCommerce: from n/a through 1.9.8.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-58598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-03T15:15:40Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of Sensitive Information Into Debugging Code vulnerability in Klarna Klarna Order Management for WooCommerce allows Retrieve Embedded Sensitive Data. This issue affects Klarna Order Management for WooCommerce: from n/a through 1.9.8.",
  "id": "GHSA-prj4-jp6f-vpf4",
  "modified": "2026-04-01T18:36:02Z",
  "published": "2025-09-03T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58598"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/klarna-order-management-for-woocommerce/vulnerability/wordpress-klarna-order-management-for-woocommerce-plugin-1-9-8-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RGRF-6MF5-M882

Vulnerability from github – Published: 2024-01-11 15:18 – Updated: 2024-09-13 17:39
VLAI
Summary
cdo-local-uuid vulnerable to insertion of artifact derived from developer's Present Working Directory into demonstration code
Details

Impact

What kind of vulnerability is it? Who is impacted?

An information leakage vulnerability is present in cdo-local-uuid at version 0.4.0, and in case-utils in unpatched versions (matching the pattern 0.x.0) at and since 0.5.0, before 0.15.0.

The vulnerability stems from a Python function, cdo_local_uuid.local_uuid(), and its original implementation case_utils.local_uuid(). Henceforth, both will be called local_uuid().

local_uuid() generates UUIDv5s using a deterministic pseudorandom number stream. This was written to make graph application demonstrations generate consistent, version-controllable output with minimal noise caused by demonstration re-runs. Part of the information used to keep individual examples' generated output distinct from one another is seed information from the caller's environment, particularly the program's argument vector. The present working directory is also included as part of the seed information, but for reasons including maintaining user environment privacy, as well as keeping generated identifiers consistent regardless of where a source tree is housed on a user's file system, the present working directory is trimmed from the left to exclude path information outside of a supplied "Top" source directory. (In context of the Make scripting language, this "top" directory is typically in a variable called top_srcdir. In context of Git-based project management, this directory is expected to be the root directory of a freshly "Cloned" project, e.g., where .git is stored.)

Under certain conditions, a user's present working directory, as an absolute path, was incorporated into seed data for the local_uuid() deterministic pseudorandom number stream. This violates an expectation made in the documented purpose of the local_uuid() function, and leaks information about a calling user's environment.

The conditions are:

  • Given a project with top source directory top_srcdir, for instance /home/user1/Documents/Project1;
  • Given a Python script housed directly in top_srcdir, for instance at ${top_srcdir}/example.py, written to support the deterministic mode of local_uuid();
  • Given a call to that Python script that follows the documentation for local_uuid();

The absolute path for top_srcdir was then included in the seed information for the UUIDv5 stream, when what was intended was a relative path spelling. That is, instead of ./example.py being in the seed data, /home/user1/Documents/Project1/example.py was in the seed data.

This does not leak the present working directory directly. But, given other knowledge of how a program had been called to generate data using local_uuid() under these conditions, it becomes possible to determine that a chosen path can lead to a known UUIDv5 value. Note that it is not necessarily knowable that the chosen path is the only solution to a sequence reconstruction; but, the path can be confirmed to be a solution.

Patches

Has the problem been patched? What versions should users upgrade to?

The issue has been patched, in the cdo-local-uuid source repository and the case-utils source repository.

Users should upgrade to any of these versions minimally:

  • case-utils == 0.5.1
  • case-utils == 0.6.1
  • case-utils == 0.7.1
  • case-utils == 0.8.1
  • case-utils == 0.9.1
  • case-utils == 0.10.1
  • case-utils == 0.11.1
  • case-utils == 0.12.1
  • case-utils == 0.13.1
  • case-utils == 0.14.1
  • case-utils >= 0.15.0
  • cdo-local-uuid == 0.5.0

All case-utils releases that contain the patch have the commit ea630cce66b26dae6d7fa7e02451d6e25456a5f2 in their Git history. Anyone interested in confirming the presence of this commit in a certain branch or tag can run the following test (written in Bash), substituting the desired branch name for the assigned value of my_git_ref_of_interest:

#!/bin/bash
# Present working directory ($PWD) should be in a clone of this repository:
# https://github.com/casework/CASE-Utilities-Python
my_git_ref_of_interest=main
test \
  "xea630cce66b26dae6d7fa7e02451d6e25456a5f2" \
  == \
  "x$(git merge-base ea630cc ${my_git_ref_of_interest})"
echo $?  # Should print '0'

Note that other releases have been posted atop some of those minimal versions recommended for upgrading, named, e.g., 0.5.1.post0. These releases were posted to update internal library version numbers, and otherwise contain no functional changes, in accordance with Python Packaging guidance:

  • https://packaging.python.org/en/latest/specifications/version-specifiers/#post-release-separators

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If the script calling cdo_local_uuid.local_uuid() is moved out of the "Top" source directory, the issue is addressed.

References

Are there any links users can visit to find out more?

The issue is addressed in this Pull Request:

  • https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/3

Tests to reproduce the issue's conditions and confirm it has been addressed are in this Pull Requested:

  • https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/4
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "cdo-local-uuid"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.4.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.5.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.6.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.7.0"
            },
            {
              "fixed": "0.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.7.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.0"
            },
            {
              "fixed": "0.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.8.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.9.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.0"
            },
            {
              "fixed": "0.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.10.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.0"
            },
            {
              "fixed": "0.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.11.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.0"
            },
            {
              "fixed": "0.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.12.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.13.0"
            },
            {
              "fixed": "0.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.13.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "case-utils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.0"
            },
            {
              "fixed": "0.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.14.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-22194"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215",
      "CWE-337"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-11T15:18:51Z",
    "nvd_published_at": "2024-01-11T03:15:10Z",
    "severity": "LOW"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nAn information leakage vulnerability is present in [`cdo-local-uuid`](https://pypi.org/project/cdo-local-uuid/) at version `0.4.0`, and in [`case-utils`](https://pypi.org/project/case-utils/) in unpatched versions (matching the pattern `0.x.0`) at and since `0.5.0`, before `0.15.0`.\n\nThe vulnerability stems from a Python function, `cdo_local_uuid.local_uuid()`, and its original implementation `case_utils.local_uuid()`.  Henceforth, both will be called `local_uuid()`.\n\n`local_uuid()` generates UUIDv5s using a deterministic pseudorandom number stream.  This was written to make graph application demonstrations generate consistent, version-controllable output with minimal noise caused by demonstration re-runs.  Part of the information used to keep individual examples\u0027 generated output distinct from one another is seed information from the caller\u0027s environment, particularly the program\u0027s argument vector.  The present working directory is also included as part of the seed information, but for reasons including maintaining user environment privacy, as well as keeping generated identifiers consistent regardless of where a source tree is housed on a user\u0027s file system, the present working directory is trimmed from the left to exclude path information outside of a supplied \"Top\" source directory.  (In context of the Make scripting language, this \"top\" directory is typically in a variable called `top_srcdir`.  In context of Git-based project management, this directory is expected to be the root directory of a freshly \"Cloned\" project, e.g., where `.git` is stored.)\n\nUnder certain conditions, a user\u0027s present working directory, as an absolute path, was incorporated into seed data for the `local_uuid()` deterministic pseudorandom number stream.  This violates an expectation made in the documented purpose of the `local_uuid()` function, and leaks information about a calling user\u0027s environment.\n\nThe conditions are:\n\n* Given a project with top source directory `top_srcdir`, for instance `/home/user1/Documents/Project1`;\n* Given a Python script housed directly in `top_srcdir`, for instance at `${top_srcdir}/example.py`, written to support the deterministic mode of `local_uuid()`;\n* Given a call to that Python script that follows the documentation for `local_uuid()`;\n\nThe absolute path for `top_srcdir` was then included in the seed information for the UUIDv5 stream, when what was intended was a relative path spelling.  That is, instead of `./example.py` being in the seed data, `/home/user1/Documents/Project1/example.py` was in the seed data.\n\nThis does not leak the present working directory directly.  But, given other knowledge of how a program had been called to generate data using `local_uuid()` under these conditions, it becomes possible to determine that a chosen path can lead to a known UUIDv5 value.  Note that it is not necessarily knowable that the chosen path is the *only* solution to a sequence reconstruction; but, the path can be confirmed to be *a* solution.\n\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nThe issue has been patched, in the `cdo-local-uuid` source repository and the `case-utils` source repository.\n\nUsers should upgrade to any of these versions minimally:\n\n* `case-utils == 0.5.1`\n* `case-utils == 0.6.1`\n* `case-utils == 0.7.1`\n* `case-utils == 0.8.1`\n* `case-utils == 0.9.1`\n* `case-utils == 0.10.1`\n* `case-utils == 0.11.1`\n* `case-utils == 0.12.1`\n* `case-utils == 0.13.1`\n* `case-utils == 0.14.1`\n* `case-utils \u003e= 0.15.0`\n* `cdo-local-uuid == 0.5.0`\n\nAll `case-utils` releases that contain the patch have the commit `ea630cce66b26dae6d7fa7e02451d6e25456a5f2` in their Git history.  Anyone interested in confirming the presence of this commit in a certain branch or tag can run the following test (written in Bash), substituting the desired branch name for the assigned value of `my_git_ref_of_interest`:\n\n```bash\n#!/bin/bash\n# Present working directory ($PWD) should be in a clone of this repository:\n# https://github.com/casework/CASE-Utilities-Python\nmy_git_ref_of_interest=main\ntest \\\n  \"xea630cce66b26dae6d7fa7e02451d6e25456a5f2\" \\\n  == \\\n  \"x$(git merge-base ea630cc ${my_git_ref_of_interest})\"\necho $?  # Should print \u00270\u0027\n```\n\nNote that other releases have been posted atop some of those minimal versions recommended for upgrading, named, e.g., `0.5.1.post0`.  These releases were posted to update internal library version numbers, and otherwise contain no functional changes, in accordance with Python Packaging guidance:\n\n* https://packaging.python.org/en/latest/specifications/version-specifiers/#post-release-separators\n\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf the script calling `cdo_local_uuid.local_uuid()` is moved out of the \"Top\" source directory, the issue is addressed.\n\n\n### References\n_Are there any links users can visit to find out more?_\n\nThe issue is addressed in this Pull Request:\n\n* https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/3\n\nTests to reproduce the issue\u0027s conditions and confirm it has been addressed are in this Pull Requested:\n\n* https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/4\n\n\u003c!--\nCVSS3.1 vector determined by rubric diagrams at this page:\nhttps://www.first.org/cvss/v3.1/user-guide\n--\u003e",
  "id": "GHSA-rgrf-6mf5-m882",
  "modified": "2024-09-13T17:39:18Z",
  "published": "2024-01-11T15:18:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/security/advisories/GHSA-rgrf-6mf5-m882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22194"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/pull/4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/fdc32414eccfcbde6be0fd91b7f491cc0779b02d#diff-e60b9cb8fb480ed27283a030a0898be3475992d78228f4045b12ce5cbb2f0509"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/fca7388f09feccd3b9ea88e6df9c7a43a5349452"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/e4ffadc3d56fd303b8f465d727c4a58213d311a1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/db428a0745dac4fdd888ced9c52f617695519f9d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/939775f956796d0432ecabbf62782ed7ad1007b5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/80551f49241c874c7c50e14abe05c5017630dad2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/7e02d18383eabbeb9fb4ec97d81438c9980a4790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/5acb929dfb599709d1c8c90d1824dd79e0fd9e10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/1cccae8eb3cf94b3a28f6490efa0fbf5c82ebd6b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/casework/CASE-Utilities-Python/commit/00864cd12de7c50d882dd1a74915d32e939c25f9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID/commit/9e78f7cb1075728d0aafc918514f32a1392cd235"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/case-utils/PYSEC-2024-5.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/cdo-local-uuid/PYSEC-2024-6.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Cyber-Domain-Ontology/CDO-Utility-Local-UUID"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "cdo-local-uuid vulnerable to insertion of artifact derived from developer\u0027s Present Working Directory into demonstration code"
}

GHSA-RJ6P-94V3-4CCP

Vulnerability from github – Published: 2024-08-13 21:31 – Updated: 2024-08-13 21:31
VLAI
Details

An information disclosure vulnerability in Ivanti ITSM on-prem and Neurons for ITSM versions 2023.4 and earlier allows an unauthenticated attacker to obtain the OIDC client secret via debug information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-13T19:15:16Z",
    "severity": "CRITICAL"
  },
  "details": "An information disclosure vulnerability in Ivanti ITSM on-prem and Neurons for ITSM versions 2023.4 and earlier allows an unauthenticated attacker to obtain the OIDC client secret via debug information.",
  "id": "GHSA-rj6p-94v3-4ccp",
  "modified": "2024-08-13T21:31:55Z",
  "published": "2024-08-13T21:31:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7569"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Neurons-for-ITSM-CVE-2024-7569-CVE-2024-7570"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9QF-M6G5-9C72

Vulnerability from github – Published: 2025-03-02 18:30 – Updated: 2025-03-02 18:30
VLAI
Details

IBM Cognos Analytics Mobile 1.1 for Android could allow a user with physical access to the device, to obtain sensitive information from debugging code log messages.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-02T16:15:35Z",
    "severity": "LOW"
  },
  "details": "IBM Cognos Analytics Mobile 1.1 for Android could allow a user with physical access to the device, to obtain sensitive information from debugging code log messages.",
  "id": "GHSA-v9qf-m6g5-9c72",
  "modified": "2025-03-02T18:30:53Z",
  "published": "2025-03-02T18:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0895"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7184430"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQF5-2XX6-9WFM

Vulnerability from github – Published: 2025-01-24 18:44 – Updated: 2025-03-31 21:55
VLAI
Summary
GitHub PAT written to debug artifacts
Details

Impact summary

In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment.

For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid GITHUB_TOKEN for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The GITHUB_TOKEN is valid until the job completes or 24 hours has elapsed, whichever comes first.

Environment variables are exposed only from workflow runs that satisfy all of the following conditions: - Code scanning workflow configured to scan the Java/Kotlin languages. - Running in a repository containing Kotlin source code. - Running with debug artifacts enabled. - Using CodeQL Action versions <= 3.28.2, and CodeQL CLI versions >= 2.9.2 (May 2022) and <= 2.20.2. - The workflow run fails before the CodeQL database is finalized within the github/codeql-action/analyze step. - Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. (Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo.)

The GITHUB_TOKEN exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above: - Using CodeQL Action versions >= 3.26.11 (October 2024) and <= 3.28.2, or >= 2.26.11 and < 3. - Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server).

In rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory GHSA-gqh3-9prg-j95m for more details.

Impact details

In CodeQL CLI versions >= 2.9.2 and <= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. This is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories. On Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned.

The intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode.

Therefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the GITHUB_TOKEN and any user-configured secrets made available via environment variables.

The impact of the GITHUB_TOKEN leaked in this environment is limited: - For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions >= 3.26.11 and <= 3.28.2, or >= 2.26.11 and < 3, which in turn use the actions/artifacts v4 library, the debug artifact is uploaded before the workflow job completes. During this time the GITHUB_TOKEN is still valid, providing an opportunity for attackers to gain access to the repository. - For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked GITHUB_TOKEN has been revoked and cannot be used to access the repository.

Mitigations

Update to CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later.

Patches

This vulnerability has been fixed in CodeQL Action version 3.28.3, which no longer uploads database artifacts in debug mode. This vulnerability will be fixed in CodeQL CLI version 2.20.3, in which database creation for all languages no longer logs the complete environment by default.

References

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.28.2"
      },
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "github/codeql-action"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.26.11"
            },
            {
              "fixed": "3.28.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.0.0"
      },
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "github/codeql-action"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.26.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215",
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-24T18:44:55Z",
    "nvd_published_at": "2025-01-24T18:15:32Z",
    "severity": "HIGH"
  },
  "details": "### Impact summary\n\nIn some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment.\n\nFor some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first.\n\nEnvironment variables are exposed only from workflow runs that satisfy all of the following conditions:\n- Code scanning workflow configured to scan the Java/Kotlin languages.\n- Running in a repository containing Kotlin source code.\n- Running with [debug artifacts enabled](https://docs.github.com/en/code-security/code-scanning/troubleshooting-code-scanning/logs-not-detailed-enough).\n- Using CodeQL Action versions \u003c= 3.28.2, and CodeQL CLI versions \u003e= 2.9.2 (May 2022) and \u003c= 2.20.2.\n- The workflow run fails before the CodeQL database is finalized within the `github/codeql-action/analyze` step.\n- Running in any GitHub environment: GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server. (Note: artifacts are only accessible to users within the same GitHub environment with access to the scanned repo.)\n\nThe `GITHUB_TOKEN` exposed in this way would only have been valid for workflow runs that satisfy all of the following conditions, in addition to the conditions above:\n- Using CodeQL Action versions \u003e= 3.26.11 (October 2024) and \u003c= 3.28.2, or \u003e= 2.26.11 and \u003c 3.\n- Running in GitHub.com or GitHub Enterprise Cloud only (not valid on GitHub Enterprise Server).\n\nIn rare cases during advanced setup, logging of environment variables may also occur during database creation of Java, Swift, and C/C++. Please read the corresponding CodeQL CLI advisory [GHSA-gqh3-9prg-j95m](https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gqh3-9prg-j95m) for more details.\n\n\n### Impact details\n\nIn CodeQL CLI versions \u003e= 2.9.2 and \u003c= 2.20.2, the CodeQL Kotlin extractor logs all environment variables by default into an intermediate file during the process of creating a CodeQL database for Kotlin code. \nThis is a part of the CodeQL CLI and is invoked by the CodeQL Action for analyzing Kotlin repositories. \nOn Actions, the environment variables logged include GITHUB_TOKEN, which grants permissions to the repository being scanned.\n\nThe intermediate file containing environment variables is deleted when finalizing the database, so it is not included in a successfully created database. It is, however, included in the debug artifact that is uploaded on a failed analysis run if the CodeQL Action was invoked in debug mode.\n\nTherefore, under these specific circumstances (incomplete database creation using the CodeQL Action in debug mode) an attacker with access to the debug artifact would gain unauthorized access to repository secrets from the environment, including both the `GITHUB_TOKEN` and any user-configured secrets made available via environment variables.\n\nThe impact of the `GITHUB_TOKEN` leaked in this environment is limited:\n- For workflows on GitHub.com and GitHub Enterprise Cloud using CodeQL Action versions \u003e= 3.26.11 and \u003c= 3.28.2, or \u003e= 2.26.11 and \u003c 3, which in turn use the `actions/artifacts v4` library, the debug artifact is uploaded before the workflow job completes. During this time the `GITHUB_TOKEN` is still valid, providing an opportunity for attackers to gain access to the repository.\n- For all other workflows, the debug artifact is uploaded after the workflow job completes, at which point the leaked `GITHUB_TOKEN` has been revoked and cannot be used to access the repository.\n\n### Mitigations\n\nUpdate to CodeQL Action version 3.28.3 or later, or CodeQL CLI version 2.20.3 or later.\n\n### Patches\n\nThis vulnerability has been fixed in CodeQL Action version 3.28.3, which no longer uploads database artifacts in debug mode.\nThis vulnerability will be fixed in CodeQL CLI version 2.20.3, in which database creation for all languages no longer logs the complete environment by default.\n\n### References\n\n- [Pull request that bundled CodeQL CLI 2.9.2 with Kotlin extractor environment variable logging ](https://github.com/github/codeql-action/pull/1074)\n- [Pull request that introduced the `actions/artifacts v4` library, allowing for `GITHUB_TOKEN` exposure in the CodeQL Action debug artifacts before the token was revoked](https://github.com/github/codeql-action/pull/2482)\n- [Related security advisory for the CodeQL CLI](https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gqh3-9prg-j95m)",
  "id": "GHSA-vqf5-2xx6-9wfm",
  "modified": "2025-03-31T21:55:42Z",
  "published": "2025-01-24T18:44:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/security/advisories/GHSA-vqf5-2xx6-9wfm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-cli-binaries/security/advisories/GHSA-gqh3-9prg-j95m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24362"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/pull/1074"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/pull/2482"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/codeql-action/commit/519de26711ecad48bde264c51e414658a82ef3fa"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/code-security/code-scanning/troubleshooting-code-scanning/logs-not-detailed-enough"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/github/codeql-action"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=43527044"
    },
    {
      "type": "WEB",
      "url": "https://www.praetorian.com/blog/codeqleaked-public-secrets-exposure-leads-to-supply-chain-attack-on-github-codeql"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GitHub PAT written to debug artifacts"
}

GHSA-X6G4-F6Q3-FQVV

Vulnerability from github – Published: 2026-03-24 20:44 – Updated: 2026-03-27 20:57
VLAI
Summary
NATS credentials are exposed in monitoring port via command-line argv
Details

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an optional monitoring port, which provides access to sensitive data. The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.

Problem Description

If a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.

The /debug/vars end-point contains an unredacted copy of argv.

Patches

Fixed in nats-server 2.12.6 & 2.11.15

Workarounds

The NATS Maintainers are bemused at the concept of someone deploying a real configuration using --pass to avoid a config file, but also enabling monitoring.

Configure credentials inside a configuration file instead of via argv.

Do not enable the monitoring port if using secrets in argv.

Best practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0-RC.1"
            },
            {
              "fixed": "2.12.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-215"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T20:44:00Z",
    "nvd_published_at": "2026-03-25T20:16:33Z",
    "severity": "HIGH"
  },
  "details": "### Background\n\nNATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.\n\nThe nats-server provides an optional monitoring port, which provides access to sensitive data.  The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.\n\n\n### Problem Description\n\nIf a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.\n\nThe `/debug/vars` end-point contains an unredacted copy of argv.\n\n### Patches\n\nFixed in nats-server 2.12.6 \u0026 2.11.15\n\n### Workarounds\n\nThe NATS Maintainers are bemused at the concept of someone deploying a real configuration using `--pass` to avoid a config file, but also enabling monitoring.\n\nConfigure credentials inside a configuration file instead of via argv.\n\nDo not enable the monitoring port if using secrets in argv.\n\nBest practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.",
  "id": "GHSA-x6g4-f6q3-fqvv",
  "modified": "2026-03-27T20:57:01Z",
  "published": "2026-03-24T20:44:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-x6g4-f6q3-fqvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33247"
    },
    {
      "type": "WEB",
      "url": "https://advisories.nats.io/CVE/secnote-2026-14.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nats-io/nats-server"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NATS credentials are exposed in monitoring port via command-line argv"
}

Mitigation
Implementation

Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software.

Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

  • Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

No CAPEC attack patterns related to this CWE.