GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-532

Allowed

Insertion of Sensitive Information into Log File

Abstraction: Base · Status: Incomplete

The product writes sensitive information to a log file.

1891 vulnerabilities reference this CWE, most recent first.

GHSA-G6XQ-892H-64W3

Vulnerability from github – Published: 2026-07-20 21:55 – Updated: 2026-07-20 21:55
VLAI
Summary
Composer: URL-embedded HTTP-Basic username leaks to verbose logs (GitHub PAT exposure)
Details

Summary

When Composer is run with -vvv (debug verbosity), it could print a credential that was embedded directly in a repository or package URL, but not as a password, to its debug output. Composer already masked the password portion of such URLs, but the username portion was shown in clear text. Because GitHub and several other services support placing an access token in the username position of a URL (for example https://[token]@github.com/owner/repo), a token used that way could end up written to the verbose log in full.

This is an information disclosure issue. The credential is only ever exposed to whoever can already read Composer's debug output.

Am I affected?

You are potentially affected only if all of the following apply:

  • A credential is embedded inside a URL that Composer handles, e.g. in a repositories entry in composer.json, in a package dist/source URL - rather than being supplied through auth.json or the COMPOSER_AUTH environment variable.
  • The secret sits in the username slot of that URL (e.g. https://TOKEN@host/…). A normal username:password@host pair where the username is an ordinary account name did not expose the password, that was already masked.
  • Composer is run with -vvv (debug verbosity), and that output is retained or shared somewhere others can read it: public CI build logs, output pasted into an issue or chat, archived terminal sessions, and so on.

If you keep credentials in auth.json or environment variables, or you never run Composer at debug verbosity, you were not exposed.

The most realistic exposure is the documented pattern of embedding a GitHub Personal Access Token in a URL's username position on a machine (often CI) that captures verbose output.

Patched versions

The username is now masked the same way the password already was, so an embedded token no longer appears in verbose output (a short, non-secret prefix may be shown to aid debugging, but never the full value).

Fixed in Composer 2.10.2 and the 2.2.29.

Workarounds

There is no configuration setting that prevents outputting credentials while keeping normal behavior.

If you cannot upgrade right away, you can reduce exposure by:

  • Not running Composer with -vvv (debug verbosity) in environments where output is captured or shared.
  • Moving credentials out of URLs and into auth.json or COMPOSER_AUTH.
  • Scrubbing existing CI/build logs that may already contain a leaked token.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "composer/composer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "composer/composer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "2.2.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T21:55:05Z",
    "nvd_published_at": "2026-07-08T20:16:59Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhen Composer is run with -vvv (debug verbosity), it could print a credential that was embedded directly in a repository or package URL, but not as a password, to its debug output. Composer already masked the password portion of such URLs, but the username portion was shown in clear text. Because GitHub and several other services support placing an access token in the username position of a URL (for example https://[token]@github.com/owner/repo), a token used that way could end up written to the verbose log in full.\n\nThis is an information disclosure issue. The credential is only ever exposed to whoever can already read Composer\u0027s debug output.\n\n## Am I affected?\n\nYou are potentially affected only if **all** of the following apply:\n\n- A credential is embedded inside a URL that Composer handles, e.g. in a `repositories` entry in composer.json, in a package dist/source URL - rather than being supplied through auth.json or the COMPOSER_AUTH environment variable.\n- The secret sits in the username slot of that URL (e.g. `https://TOKEN@host/\u2026`). A normal `username:password@host` pair where the username is an ordinary account name did not expose the password, that was already masked.\n- Composer is run with -vvv (debug verbosity), and that output is retained or shared somewhere others can read it: public CI build logs, output pasted into an issue or chat, archived terminal sessions, and so on.\n\nIf you keep credentials in auth.json or environment variables, or you never run Composer at debug verbosity, you were not exposed.\n\nThe most realistic exposure is the documented pattern of embedding a GitHub Personal Access Token in a URL\u0027s username position on a machine (often CI) that captures verbose output.\n\n## Patched versions\n\nThe username is now masked the same way the password already was, so an embedded token no longer appears in verbose output (a short, non-secret prefix may be shown to aid debugging, but never the full value).\n\nFixed in Composer 2.10.2 and the 2.2.29.\n\n## Workarounds\n\nThere is no configuration setting that prevents outputting credentials while keeping normal behavior.\n\nIf you cannot upgrade right away, you can reduce exposure by:\n\n- Not running Composer with -vvv (debug verbosity) in environments where output is captured or shared.\n- Moving credentials out of URLs and into auth.json or COMPOSER_AUTH.\n- Scrubbing existing CI/build logs that may already contain a leaked token.",
  "id": "GHSA-g6xq-892h-64w3",
  "modified": "2026-07-20T21:55:05Z",
  "published": "2026-07-20T21:55:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/composer/composer/security/advisories/GHSA-g6xq-892h-64w3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59947"
    },
    {
      "type": "WEB",
      "url": "https://github.com/composer/composer/commit/6bd66874ae523ecb69aca5964487a0cdfda03ef8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/composer/composer/commit/8887ad76fbd830cb1861a2b1fd8ead78ed1fa1ec"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/composer/composer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/composer/composer/releases/tag/2.10.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/composer/composer/releases/tag/2.2.29"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Composer: URL-embedded HTTP-Basic username leaks to verbose logs (GitHub PAT exposure)"
}

GHSA-G732-PFFP-45RC

Vulnerability from github – Published: 2023-08-02 00:30 – Updated: 2024-02-14 00:35
VLAI
Details

The Brocade Fabric OS Commands “configupload” and “configdownload” before Brocade Fabric OS v9.1.1c, v8.2.3d, v9.2.0 print scp, sftp, ftp servers passwords in supportsave. This could allow a remote authenticated attacker to access sensitive information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-31426"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-01T22:15:13Z",
    "severity": "MODERATE"
  },
  "details": "\n\n\nThe Brocade Fabric OS Commands \u201cconfigupload\u201d and \u201cconfigdownload\u201d before Brocade Fabric OS v9.1.1c, v8.2.3d, v9.2.0 print scp, sftp, ftp servers passwords in supportsave. This could allow a remote authenticated attacker to access sensitive information.\n\n\n\n\n\n",
  "id": "GHSA-g732-pffp-45rc",
  "modified": "2024-02-14T00:35:40Z",
  "published": "2023-08-02T00:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31426"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230908-0007"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/external/content/SecurityAdvisories/0/22407"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/22377"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G75J-C66M-V892

Vulnerability from github – Published: 2024-09-10 12:30 – Updated: 2024-09-10 12:30
VLAI
Details

A vulnerability has been identified in SINUMERIK 828D V4 (All versions < V4.95 SP3), SINUMERIK 840D sl V4 (All versions < V4.95 SP3 in connection with using Create MyConfig (CMC) <= V4.8 SP1 HF6), SINUMERIK ONE (All versions < V6.23 in connection with using Create MyConfig (CMC) <= V6.6), SINUMERIK ONE (All versions < V6.15 SP4 in connection with using Create MyConfig (CMC) <= V6.6). Affected systems, that have been provisioned with Create MyConfig (CMC), contain a Insertion of Sensitive Information into Log File vulnerability. This could allow a local authenticated user with low privileges to read sensitive information and thus circumvent access restrictions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-43781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T10:15:12Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SINUMERIK 828D V4 (All versions \u003c V4.95 SP3), SINUMERIK 840D sl V4 (All versions \u003c V4.95 SP3 in connection with using Create MyConfig (CMC) \u003c= V4.8 SP1 HF6), SINUMERIK ONE (All versions \u003c V6.23 in connection with using Create MyConfig (CMC) \u003c= V6.6), SINUMERIK ONE (All versions \u003c V6.15 SP4 in connection with using Create MyConfig (CMC) \u003c= V6.6). Affected systems, that have been provisioned with Create MyConfig (CMC), contain a Insertion of Sensitive Information into Log File vulnerability. This could allow a local authenticated user with low privileges to read sensitive information and thus circumvent access restrictions.",
  "id": "GHSA-g75j-c66m-v892",
  "modified": "2024-09-10T12:30:38Z",
  "published": "2024-09-10T12:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43781"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-097786.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-G767-52F6-24GR

Vulnerability from github – Published: 2021-11-19 00:00 – Updated: 2021-11-23 00:00
VLAI
Details

A flaw was divered in Puppet Enterprise and other Puppet products where sensitive plan parameters may be logged

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-27026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-18T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was divered in Puppet Enterprise and other Puppet products where sensitive plan parameters may be logged",
  "id": "GHSA-g767-52f6-24gr",
  "modified": "2021-11-23T00:00:56Z",
  "published": "2021-11-19T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27026"
    },
    {
      "type": "WEB",
      "url": "https://puppet.com/security/cve/cve-2021-27026"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G768-79G3-C28J

Vulnerability from github – Published: 2022-05-13 01:02 – Updated: 2022-05-13 01:02
VLAI
Details

aria2c in aria2 1.33.1, when --log is used, can store an HTTP Basic Authentication username and password in a file, which might allow local users to obtain sensitive information by reading this file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-3500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-02T07:29:00Z",
    "severity": "HIGH"
  },
  "details": "aria2c in aria2 1.33.1, when --log is used, can store an HTTP Basic Authentication username and password in a file, which might allow local users to obtain sensitive information by reading this file.",
  "id": "GHSA-g768-79g3-c28j",
  "modified": "2022-05-13T01:02:45Z",
  "published": "2022-05-13T01:02:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aria2/aria2/issues/1329"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00012.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/12/msg00039.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/532M22TAOOIY3J4XX4R7BLZHXJRUSBQ2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7MUUYDELHRLVE2AFNVR3OJ6ILUKVLY4B"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U5OLPTVYHJZJ2MVEXJCNPXBSFPVPE4XX"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3965-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G78P-M98V-8PRX

Vulnerability from github – Published: 2024-01-30 18:30 – Updated: 2024-01-30 18:30
VLAI
Details

In Splunk Add-on Builder versions below 4.1.4, the application writes user session tokens to its internal log files when you visit the Splunk Add-on Builder or when you build or edit a custom app or add-on.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-46231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-30T17:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In Splunk Add-on Builder versions below 4.1.4, the application writes user session tokens to its internal log files when you visit the Splunk Add-on Builder or when you build or edit a custom app or add-on.",
  "id": "GHSA-g78p-m98v-8prx",
  "modified": "2024-01-30T18:30:20Z",
  "published": "2024-01-30T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46231"
    },
    {
      "type": "WEB",
      "url": "https://advisory.splunk.com/advisories/SVD-2024-0110"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G82W-58JF-GCXX

Vulnerability from github – Published: 2023-05-26 13:59 – Updated: 2025-02-13 18:57
VLAI
Summary
secrets-store-csi-driver discloses service account tokens in logs
Details

A security issue was discovered in secrets-store-csi-driver where an actor with access to the driver logs could observe service account tokens. These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions. Tokens are only logged when TokenRequests is configured in the CSIDriver object and the driver is set to run at log level 2 or greater via the -v flag.

This issue has been rated MEDIUM CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N (6.5), and assigned CVE-2023-2878

Am I vulnerable?

You may be vulnerable if TokenRequests is configured in the CSIDriver object and the driver is set to run at log level 2 or greater via the -v flag.

To check if token requests are configured, run the following command:

kubectl get csidriver secrets-store.csi.k8s.io -o jsonpath="{.spec.tokenRequests}"

To check if tokens are being logged, examine the secrets-store container log:

kubectl logs -l app=secrets-store-csi-driver -c secrets-store -f | grep --line-buffered "csi.storage.k8s.io/serviceAccount.tokens"

Affected Versions

  • secrets-store-csi-driver < 1.3.3

How do I mitigate this vulnerability?

Prior to upgrading, this vulnerability can be mitigated by running secrets-store-csi-driver at log level 0 or 1 via the -v flag.

Fixed Versions

  • secrets-store-csi-driver >= 1.3.3

To upgrade, refer to the documentation: https://secrets-store-csi-driver.sigs.k8s.io/getting-started/upgrades.html#upgrades

Detection

Examine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud vault secrets.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "sigs.k8s.io/secrets-store-csi-driver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-2878"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-26T13:59:19Z",
    "nvd_published_at": "2023-06-07T15:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A security issue was discovered in secrets-store-csi-driver where an actor with access to the driver logs could observe service account tokens.  These tokens could then potentially be exchanged with external cloud providers to access secrets stored in cloud vault solutions.  Tokens are only logged when [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag.\n\n\nThis issue has been rated MEDIUM [CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) (6.5), and assigned CVE-2023-2878\n\n\n### Am I vulnerable?\n\nYou may be vulnerable if [TokenRequests is configured in the CSIDriver object](https://kubernetes-csi.github.io/docs/token-requests.html) and the driver is set to run at log level 2 or greater via the -v flag.\n\n\nTo check if token requests are configured, run the following command:\n\n```bash\nkubectl get csidriver secrets-store.csi.k8s.io -o jsonpath=\"{.spec.tokenRequests}\"\n```\n\nTo check if tokens are being logged, examine the secrets-store container log:\n\n```bash\nkubectl logs -l app=secrets-store-csi-driver -c secrets-store -f | grep --line-buffered \"csi.storage.k8s.io/serviceAccount.tokens\"\n```\n\n### Affected Versions\n\n- secrets-store-csi-driver \u003c 1.3.3\n\n\n### How do I mitigate this vulnerability?\n\nPrior to upgrading, this vulnerability can be mitigated by running secrets-store-csi-driver at log level 0 or 1 via the -v flag.\n\n\n### Fixed Versions\n\n\n- secrets-store-csi-driver \u003e= 1.3.3\n\n\nTo upgrade, refer to the documentation: https://secrets-store-csi-driver.sigs.k8s.io/getting-started/upgrades.html#upgrades\n\n\n### Detection\n\n\nExamine cloud provider logs for unexpected token exchanges, as well as unexpected access to cloud vault secrets.\n\n\nIf you find evidence that this vulnerability has been exploited, please contact [security@kubernetes.io](https://groups.google.com/)",
  "id": "GHSA-g82w-58jf-gcxx",
  "modified": "2025-02-13T18:57:13Z",
  "published": "2023-05-26T13:59:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes-sigs/secrets-store-csi-driver/security/advisories/GHSA-g82w-58jf-gcxx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2878"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/118419"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubernetes-sigs/secrets-store-csi-driver"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes-sigs/secrets-store-csi-driver/releases/tag/v1.3.3"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/kubernetes-security-announce/c/5K8ghQHBDdQ/m/Udee6YUgAAAJ"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230814-0003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "secrets-store-csi-driver discloses service account tokens in logs"
}

GHSA-G86G-CHM8-7R2P

Vulnerability from github – Published: 2022-07-29 19:56 – Updated: 2022-07-29 19:56
VLAI
Summary
check-spelling workflow vulnerable to token leakage via symlink attack
Details

Impact

For a repository with the check-spelling action enabled that triggers on pull_request_target (or schedule), an attacker can send a crafted Pull Request that causes a GITHUB_TOKEN to be exposed.

With the GITHUB_TOKEN, it's possible to push commits to the repository bypassing standard approval processes. Commits to the repository could then steal any/all secrets available to the repository.

Workarounds

You can either: * Disable the workflow until you've fixed all branches.

or * Set repository to Allow specific actions. You can check: - [x] Allow actions created by GitHub - [x] Allow Marketplace actions by verified creators

check-spelling isn't a verified creator and it certainly won't be anytime soon. You could then explicitly add other actions that your repository uses.

or * Set repository Workflow permissions to Read repository contents permission.

Solution

Workflows using check-spelling/check-spelling@main were fixed automatically with the release of v0.0.19.

Workflows using a pinned sha or tagged version will need to change the affected workflows for all repository branches to the latest version.

The simple case

In the simple case, you have few enough open branches that you can do the following on all branches.

  • Edit the workflow to use check-spelling/check-spelling@main, or
  • Edit the workflow to use check-spelling/check-spelling@v0.0.19, or
  • Delete the workflow file, or
  • Change the workflow to only use on: push
  • this will result in PRs losing status checks (commits will still have statuses)

The complex case

If you have too many open branches to feasibly fix all of them as per the above, you can instead do the following:

  1. Perform the above solution on all open branches for which you need check-spelling to be active.
  2. On all open branches on which you need check-spelling to be active, rename the workflow file (e.g. to spelling2.yml)
  3. On the default branch, create a dummy workflow file with the old name (this is usually spelling.yml).
  4. Use the GitHub Actions UI to disable the workflow with the old name (this is usually spelling.yml).

This should prevent the vulnerable workflow from executing on any branches that you have not applied the proper solution to.

The reason for creating the dummy file (Step 3) before disabling the workflow (Step 4) is that, in our testing, GitHub may un-disable a workflow if it does not exist on your default branch.

Example dummy workflow file (For step 3):

# spelling.yml is disabled per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p
name: Workflow should not run!
on:
  push:
    branches: ''

jobs:
  placeholder:
    name: Should be disabled
    runs-on: ubuntu-latest
    if: false
    steps:
    - name: Task
      run: |
        echo 'Running this task would be bad'
        exit 1

You should also include a comment in the new workflow to remind people not to resurrect the old name, for example:

# spelling.yml is disabled per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p

Finally, you should consider sending a Pull Request to an open branch in which you have not performed the proper solution to verify that the old version of check-spelling does not execute.

How to upgrade

Perform this change to your impacted workflow file (typically .github/workflows/spelling.yml):

@@ -24 +24 @@
-    - uses: check-spelling/check-spelling@v0.0.18
+    - uses: check-spelling/check-spelling@v0.0.19

As noted above, if you have many branches, you should additionally rename the workflow and include a comment to remind people not to use the old workflow file name:

# spelling.yml is blocked per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p

Reviewing workflow runs

Users can verify who and which Pull Requests have been running the action by looking up the spelling.yml action in the Actions tab of their repositories, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml - you can filter PRs by adding ?query=event%3Apull_request_target, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml?query=event%3Apull_request_target.

References

Credit

Thanks to @justinsteven for reporting as well as in helping validate the fix.

For more information

For questions or comments about this advisory: * Email us at check-spelling@check-spelling.dev

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "check-spelling/check-spelling"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-29T19:56:34Z",
    "nvd_published_at": "2021-09-09T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nFor a repository with the [check-spelling action](https://github.com/marketplace/actions/check-spelling) enabled that triggers on `pull_request_target` (or `schedule`), an attacker can send a crafted Pull Request that causes a `GITHUB_TOKEN` to be exposed.\n\nWith the `GITHUB_TOKEN`, it\u0027s possible to push commits to the repository bypassing standard approval processes. Commits to the repository could then steal any/all secrets available to the repository.\n\n### Workarounds\n\nYou can either:\n* [Disable the workflow](https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow) until you\u0027ve fixed **all branches**.  \n\nor\n* Set repository to [Allow specific actions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#allowing-specific-actions-to-run). You can check: \n   - [x] `Allow actions created by GitHub`\n   - [x] `Allow Marketplace actions by verified creators`\n\n[check-spelling](https://github.com/check-spelling) isn\u0027t a verified creator and it certainly won\u0027t be anytime soon. You could then explicitly add other actions that your repository uses.\n\nor\n* Set repository [Workflow permissions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#setting-the-permissions-of-the-github_token-for-your-repository) to `Read repository contents permission`.\n\n### Solution\n\nWorkflows using `check-spelling/check-spelling@main` were fixed automatically with the release of [v0.0.19](https://github.com/check-spelling/check-spelling/releases/tag/v0.0.19).\n\nWorkflows using a pinned sha or tagged version will need to change the affected workflows for *all* repository branches to the latest version.\n\n#### The simple case\n\nIn the simple case, you have few enough open branches that you can do the following on **all branches**.\n\n- Edit the workflow to use `check-spelling/check-spelling@main`, or\n- Edit the workflow to use `check-spelling/check-spelling@v0.0.19`, or\n- Delete the workflow file, or\n- Change the workflow to only use `on: push`\n  - this will result in PRs losing status checks (commits will still have statuses)\n\n#### The complex case\n\nIf you have too many open branches to feasibly fix all of them as per the above, you can instead do the following:\n\n1. Perform the above solution on all open branches for which you need `check-spelling` to be active.\n2. On all open branches on which you need `check-spelling` to be active, rename the workflow file (e.g. to `spelling2.yml`)\n3. On the default branch, create a dummy workflow file with the old name (this is usually `spelling.yml`).\n4. Use the GitHub Actions UI to disable the workflow with the old name (this is usually `spelling.yml`).\n\nThis should prevent the vulnerable workflow from executing on any branches that you have not applied the proper solution to.\n\nThe reason for creating the dummy file (Step 3) before disabling the workflow (Step 4) is that, in our testing, GitHub may un-disable a workflow if it does not exist on your default branch.\n\nExample dummy workflow file (For step 3):\n\n```yml\n# spelling.yml is disabled per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p\nname: Workflow should not run!\non:\n  push:\n    branches: \u0027\u0027\n\njobs:\n  placeholder:\n    name: Should be disabled\n    runs-on: ubuntu-latest\n    if: false\n    steps:\n    - name: Task\n      run: |\n        echo \u0027Running this task would be bad\u0027\n        exit 1\n```\n\nYou *should also* include a comment in the new workflow to remind people not to resurrect the old name, for example:\n\n```yml\n# spelling.yml is disabled per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p\n```\n\nFinally, you should consider sending a Pull Request to an open branch in which you have not performed the proper solution to verify that the old version of `check-spelling` does not execute.\n\n#### How to upgrade\n\nPerform this change to your impacted workflow file (typically `.github/workflows/spelling.yml`):\n```diff\n@@ -24 +24 @@\n-    - uses: check-spelling/check-spelling@v0.0.18\n+    - uses: check-spelling/check-spelling@v0.0.19\n```\n\nAs noted above, if you have many branches, you should additionally rename the workflow and include a comment to remind people not to use the old workflow file name:\n```\n# spelling.yml is blocked per https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p\n```\n\n### Reviewing workflow runs\n\nUsers can verify who and which Pull Requests have been running the action by looking up the spelling.yml action in the Actions tab of their repositories, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml - you can filter PRs by adding `?query=event%3Apull_request_target`, e.g., https://github.com/check-spelling/check-spelling/actions/workflows/spelling.yml?query=event%3Apull_request_target.\n\n\n### References\n\n* For more information on `pull_request_target` attacks, see [GitHub Security Lab: Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)\n* For information on workflow hardening techniques, see [GitHub: Security hardening for GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions)\n\n### Credit\nThanks to [@justinsteven](https://twitter.com/justinsteven) for reporting as well as in helping validate the fix.\n\n### For more information\n\nFor questions or comments about this advisory:\n* Email us at [check-spelling@check-spelling.dev](mailto:check-spelling@check-spelling.dev)",
  "id": "GHSA-g86g-chm8-7r2p",
  "modified": "2022-07-29T19:56:34Z",
  "published": "2022-07-29T19:56:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/check-spelling/check-spelling/security/advisories/GHSA-g86g-chm8-7r2p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32724"
    },
    {
      "type": "WEB",
      "url": "https://github.com/check-spelling/check-spelling/commit/436362fc6b588d9d561cbdb575260ca593c8dc56"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/check-spelling/check-spelling"
    },
    {
      "type": "WEB",
      "url": "https://github.com/check-spelling/check-spelling/releases/tag/v0.0.19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "check-spelling workflow vulnerable to token leakage via symlink attack"
}

GHSA-G8HG-RJF5-VFRM

Vulnerability from github – Published: 2024-09-12 21:32 – Updated: 2024-09-12 21:32
VLAI
Details

An issue was discovered in GitLab CE/EE affecting all versions starting from 16.5 prior to 17.1.7, starting from 17.2 prior to 17.2.5, and starting from 17.3 prior to 17.3.2, where dependency proxy credentials are retained in graphql Logs.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-4472"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-12T19:15:04Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in GitLab CE/EE affecting all versions starting from 16.5 prior to 17.1.7, starting from 17.2 prior to 17.2.5, and starting from 17.3 prior to 17.3.2, where dependency proxy credentials are retained in graphql Logs.",
  "id": "GHSA-g8hg-rjf5-vfrm",
  "modified": "2024-09-12T21:32:02Z",
  "published": "2024-09-12T21:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4472"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2477062"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/460289"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G8XM-P2H4-V6JP

Vulnerability from github – Published: 2023-03-24 21:30 – Updated: 2023-04-04 15:24
VLAI
Summary
OpenShift Assisted Installer leaks image pull secrets as plaintext in installation logs
Details

A vulnerability was found in OpenShift Assisted Installer. During generation of the Discovery ISO, image pull secrets were leaked as plaintext in the installation logs. An authenticated user could exploit this by re-using the image pull secret to pull container images from the registry as the associated user.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openshift/assisted-installer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.25.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-532"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-24T21:59:18Z",
    "nvd_published_at": "2023-03-24T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in OpenShift Assisted Installer. During generation of the Discovery ISO, image pull secrets were leaked as plaintext in the installation logs. An authenticated user could exploit this by re-using the image pull secret to pull container images from the registry as the associated user.",
  "id": "GHSA-g8xm-p2h4-v6jp",
  "modified": "2023-04-04T15:24:49Z",
  "published": "2023-03-24T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3684"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/assisted-installer/commit/2403dad3795406f2c5d923af0894e07bc8b0bdc4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/assisted-installer/commit/f3800cfa3d64ce6dcd6f7b73f0578bb99bfdaf7a"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1985962"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openshift/assisted-installer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenShift Assisted Installer leaks image pull secrets as plaintext in installation logs"
}

Mitigation
Architecture and Design Implementation

Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.

Mitigation
Distribution

Remove debug log files before deploying the application into production.

Mitigation
Operation

Protect log files against unauthorized read/write.

Mitigation
Implementation

Adjust configurations appropriately when software is transitioned from a debug state to production.

CAPEC-215: Fuzzing for application mapping

An attacker sends random, malformed, or otherwise unexpected messages to a target application and observes the application's log or error messages returned. The attacker does not initially know how a target will respond to individual messages but by attempting a large number of message variants they may find a variant that trigger's desired behavior. In this attack, the purpose of the fuzzing is to observe the application's log and error messages, although fuzzing a target can also sometimes cause the target to enter an unstable state, causing a crash.