CWE-532
AllowedInsertion of Sensitive Information into Log File
Abstraction: Base · Status: Incomplete
The product writes sensitive information to a log file.
1744 vulnerabilities reference this CWE, most recent first.
GHSA-G767-52F6-24GR
Vulnerability from github – Published: 2021-11-19 00:00 – Updated: 2021-11-23 00:00A flaw was divered in Puppet Enterprise and other Puppet products where sensitive plan parameters may be logged
{
"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:02aria2c 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.
{
"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:30In 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.
{
"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:57A 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
{
"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:56Impact
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:
- Perform the above solution on all open branches for which you need
check-spellingto be active. - On all open branches on which you need
check-spellingto be active, rename the workflow file (e.g. tospelling2.yml) - On the default branch, create a dummy workflow file with the old name (this is usually
spelling.yml). - 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
- For more information on
pull_request_targetattacks, see GitHub Security Lab: Keeping your GitHub Actions and workflows secure: Preventing pwn requests - For information on workflow hardening techniques, see GitHub: Security hardening for GitHub Actions
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
{
"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:32An 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.
{
"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:24A 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.
{
"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"
}
GHSA-G9J7-W55P-JQ3W
Vulnerability from github – Published: 2024-09-04 18:30 – Updated: 2024-09-04 18:30A vulnerability in Cisco Smart Licensing Utility could allow an unauthenticated, remote attacker to access sensitive information.
This vulnerability is due to excessive verbosity in a debug log file. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to obtain log files that contain sensitive data, including credentials that can be used to access the API.
{
"affected": [],
"aliases": [
"CVE-2024-20440"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T17:15:13Z",
"severity": "HIGH"
},
"details": "A vulnerability in Cisco Smart Licensing Utility could allow an unauthenticated, remote attacker to access sensitive information.\n\nThis vulnerability is due to excessive verbosity in a debug log file. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to obtain log files that contain sensitive data, including credentials that can be used to access the API.",
"id": "GHSA-g9j7-w55p-jq3w",
"modified": "2024-09-04T18:30:58Z",
"published": "2024-09-04T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20440"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cslu-7gHMzWmw"
}
],
"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-G9QX-25VJ-RF53
Vulnerability from github – Published: 2024-04-12 15:37 – Updated: 2025-02-13 19:01Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.
This issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0.
When asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr. One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic. By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well. Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account.
Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the .solrOptions.security.authenticationType=basic option, and (2) required authentication be used on probes by setting .solrOptions.security.probesRequireAuth=true.
Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests. Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting .solrOptions.security.probesRequireAuth=false.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/apache/solr-operator"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0"
},
{
"fixed": "0.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-31391"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-12T21:16:19Z",
"nvd_published_at": "2024-04-12T15:15:26Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.\n\nThis issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0.\n\nWhen asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the \"solr\" and \"admin\" accounts for use by end-users, and a \"k8s-oper\" account which the operator uses for its own requests to Solr.\nOne common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr\u0027s health and ability to receive traffic.\nBy default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but\u00a0users may specifically request that authentication be required on probe endpoints as well.\nWhenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes \"event\" containing the username and password of the \"k8s-oper\" account.\n\nWithin the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the `.solrOptions.security.authenticationType=basic` option, and (2) required authentication be used on probes by setting `.solrOptions.security.probesRequireAuth=true`.\n\nUsers are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests.\u00a0 Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting `.solrOptions.security.probesRequireAuth=false`.",
"id": "GHSA-g9qx-25vj-rf53",
"modified": "2025-02-13T19:01:24Z",
"published": "2024-04-12T15:37:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31391"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/solr-operator"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/w7011s78lzywzwyszvy4d8zm99ybt8c7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/04/12/7"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Solr Operator liveness and readiness probes may leak basic auth credentials"
}
GHSA-GF7W-PW5X-9JH7
Vulnerability from github – Published: 2022-04-07 00:00 – Updated: 2022-04-14 00:00An issue was discovered in HTCondor 9.0.x before 9.0.10 and 9.1.x before 9.5.1. An attacker can access files stored in S3 cloud storage that a user has asked HTCondor to transfer.
{
"affected": [],
"aliases": [
"CVE-2021-45103"
],
"database_specific": {
"cwe_ids": [
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-06T01:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in HTCondor 9.0.x before 9.0.10 and 9.1.x before 9.5.1. An attacker can access files stored in S3 cloud storage that a user has asked HTCondor to transfer.",
"id": "GHSA-gf7w-pw5x-9jh7",
"modified": "2022-04-14T00:00:32Z",
"published": "2022-04-07T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45103"
},
{
"type": "WEB",
"url": "https://research.cs.wisc.edu/htcondor/security/vulnerabilities/HTCONDOR-2021-0005"
},
{
"type": "WEB",
"url": "https://research.cs.wisc.edu/htcondor/security/vulnerabilities/HTCONDOR-2022-0001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
Mitigation
Remove debug log files before deploying the application into production.
Mitigation
Protect log files against unauthorized read/write.
Mitigation
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.