CWE-522
Allowed-with-ReviewInsufficiently Protected Credentials
Abstraction: Class · Status: Incomplete
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
1817 vulnerabilities reference this CWE, most recent first.
GHSA-7JF9-3FJ5-V5PX
Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2022-05-24 17:25Lindy 42633 4-Port USB 2.0 Gigabit Network Server 2.078.000 devices allow an attacker on the same network to elevate privileges because the administrative password can be discovered by sniffing unencrypted UDP traffic.
{
"affected": [],
"aliases": [
"CVE-2020-15058"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-07T22:15:00Z",
"severity": "LOW"
},
"details": "Lindy 42633 4-Port USB 2.0 Gigabit Network Server 2.078.000 devices allow an attacker on the same network to elevate privileges because the administrative password can be discovered by sniffing unencrypted UDP traffic.",
"id": "GHSA-7jf9-3fj5-v5px",
"modified": "2022-05-24T17:25:06Z",
"published": "2022-05-24T17:25:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15058"
},
{
"type": "WEB",
"url": "https://research.hisolutions.com/2020/05/critical-vulnerabilites-in-multiple-usb-network-servers"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7JHG-5V84-7GQC
Vulnerability from github – Published: 2022-12-27 18:30 – Updated: 2023-01-05 06:30Some Dahua software products have a vulnerability of unauthenticated request of AES crypto key. An attacker can obtain the AES crypto key by sending a specific crafted packet to the vulnerable interface.
{
"affected": [],
"aliases": [
"CVE-2022-45424"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-27T18:15:00Z",
"severity": "MODERATE"
},
"details": "Some Dahua software products have a vulnerability of unauthenticated request of AES crypto key. An attacker can obtain the AES crypto key by sending a specific crafted packet to the vulnerable interface.",
"id": "GHSA-7jhg-5v84-7gqc",
"modified": "2023-01-05T06:30:23Z",
"published": "2022-12-27T18:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45424"
},
{
"type": "WEB",
"url": "https://www.dahuasecurity.com/support/cybersecurity/details/1137"
}
],
"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"
}
]
}
GHSA-7M49-72Q9-9F7C
Vulnerability from github – Published: 2022-05-13 01:27 – Updated: 2022-05-13 01:27Previous releases of the Puppet cisco_ios module output SSH session debug information including login credentials to a world readable file on every run. These issues have been resolved in the 0.4.0 release.
{
"affected": [],
"aliases": [
"CVE-2018-11752"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-02T19:29:00Z",
"severity": "MODERATE"
},
"details": "Previous releases of the Puppet cisco_ios module output SSH session debug information including login credentials to a world readable file on every run. These issues have been resolved in the 0.4.0 release.",
"id": "GHSA-7m49-72q9-9f7c",
"modified": "2022-05-13T01:27:06Z",
"published": "2022-05-13T01:27:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11752"
},
{
"type": "WEB",
"url": "https://puppet.com/security/cve/CVE-2018-11752"
}
],
"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"
}
]
}
GHSA-7M6V-Q233-Q9J9
Vulnerability from github – Published: 2025-04-21 22:51 – Updated: 2026-01-23 17:16Prevent token leakage / privilege escalation
MinIO Operator STS: A Quick Overview
MinIO Operator STS is a native IAM Authentication for Kubernetes. MinIO Operator offers support for Secure Tokens (a.k.a. STS) which are a form of temporary access credentials for your MinIO Tenant. In essence, this allows you to control access to your MinIO tenant from your applications without having to explicitly create credentials for each application.
For an application to gain access into a MinIO Tenant, a PolicyBinding resource is required, granting explicit access to the applications by validating the kubernetes Service Account authorization token.
The service account token is validated as follows:
- The application calls
AssumeRoleWithWebIdentityAPI MinIO Operator provides. - MinIO Operator verifies the Service Account token agains the kubernetes API using the TokenReview API
- MinIO Operator reviews the TokenReviewResult confirms if the token is a valid token and the user is authenticated.
- MinIO Operator validates the service account has
PolicyBindingin the Tenant namespace. - MinIO Operator gets the PolicyBinding
- MinIO Operator calls the AssumeRole API in the MinIO Tenant
- MinIO Operator obtains temporary credentials (STS).
- MinIO Operator return temporary Credentials to the requester application.
- The applicaiton consumes Object Storage using the temporary credentials.
Understanding Audiences in Kubernetes TokenReview
In step 2 the TokenReview API call attempts to authenticate a token to a known user, TokenReviewStatus is the result of the TokenReview request.
Audiences are audience identifiers chosen by the authenticator that are compatible with both the TokenReview and token.
An identifier is any identifier in the intersection of the TokenReviewSpec audiences and the token's audiences.
A client of the TokenReview API that sets the spec.audiences field should validate that a compatible audience identifier is returned in the status.audiences field to ensure that the TokenReview server is audience aware.
If no audiences are provided, the audience will default to the audience of the Kubernetes apiserver.
Solution: Properly Issuing and Using Audience-Specific ServiceAccount Tokens
This PR ensures the Operator STS service request the Service Account JWT to belong to the audiencests.min.io in the TokenReviewRequest.
This PR ensures the examples and documentation provided guides in how to create Service accounts with "disabled auto mount services tokens", by doing this the pods where the service account is used no longer mounts the service account automatically in the path /var/run/secrets/kubernetes.io/serviceaccount.
For illustrative purposes, here is how you disable auto mount of service account tokens at the service account level.
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: namespace-name
name: service-account name
automountServiceAccountToken: false
Additionally documentation and examples show how to request an audience-specific token with audience sts.min.io, by asking for an ServiceAccount Token to be audience specific.
For illustrative purposes, here is how you request an audience specific service account token in a pod:
apiVersion: batch/v1
kind: Job
metadata:
name: job-name
namespace: job-namespace
spec:
template:
spec:
serviceAccountName: service-account-name
volumes:
- name: sa-token
projected:
sources:
- serviceAccountToken:
audience: "sts.min.io"
expirationSeconds: 86400
path: token
containers:
- name: mc
...
volumeMounts:
- name: sa-token
mountPath: /var/run/secrets/sts.min.io/serviceaccount
readOnly: true
How this prevent a token leakage or possible privilege escalation?.
This setup prevents privilege escalation and token leakage by combining multiple defense-in-depth mechanisms that ensure service account tokens are only usable by their intended audience, short-lived, and not exposed unnecessarily.
Audience restriction (aud: sts.min.io)
Problem: A ServiceAccount token is often valid for multiple audiences (e.g., the default Kubernetes API server). Without scoping, it can be replayed to other internal systems, which may unintentionally trust it.
Mitigation: Now we enforce that tokens are explicitly created for the sts.min.io audience using the Kubernetes TokenRequest API, and the MinIO Operator:
Sends audiences: ["sts.min.io"] in the TokenReview.
Verifies that the token was issued with this audience via status.audiences.
Effect: Even if a token is stolen or misused, it will fail validation if used outside the sts.min.io STS endpoint (e.g., reused at the API server or another service).
Token Leakage Mitigation
Disabling auto-mounted service account tokens
Problem: By default, Kubernetes mounts long-lived service account tokens into all pods at /var/run/secrets/kubernetes.io/serviceaccount, making them vulnerable to theft if the container is compromised.
Mitigation: No we guide users to set automountServiceAccountToken: false in their ServiceAccount definitions.
Effect: Prevents automatic token injection into all pods, reducing the attack surface.
Requesting short-lived, audience-specific tokens via serviceAccountToken projection
Problem: Long-lived tokens can be reused indefinitely if leaked. Mitigation: You use projected service account tokens with: - audience: "sts.min.io" - A short expirationSeconds (e.g., 86400 = 24 hours, or even shorter)
Effect: Even if the token is leaked, it is:
- Only usable for sts.min.io
- Short-lived and expires soon
- Revocable by disabling the SA or STS access
Affected Versions and Risk Assessment
The issue affects MinIO Operator versions v5.0.x and above, when the STS feature was first introduced.
- In v5.0.x, STS was introduced as v1alpha1 and disabled by default. It required explicit API calls to be used.
- In v6.0.x, STS graduated to v1beta1 and was enabled by default, but still requires explicit calls to the STS API for token usage.
The risk is minimal, as:
- The Operator does not persist the token (neither in memory nor on disk).
- The Operator only uses the token for a single validation and does not reuse it for any other purpose.
Release
Fix released in v7.1.0
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/minio/operator"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-32963"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-21T22:51:11Z",
"nvd_published_at": "2025-04-22T18:16:00Z",
"severity": "MODERATE"
},
"details": "# Prevent token leakage / privilege escalation\n\n## MinIO Operator STS: A Quick Overview\n\nMinIO Operator STS is a native IAM Authentication for Kubernetes. MinIO Operator offers support for [Secure Tokens](https://min.io/docs/minio/linux/developers/security-token-service.html?ref=op-gh) (a.k.a. STS) which are a form of temporary access credentials for your MinIO Tenant. In essence, this allows you to control access to your MinIO tenant from your applications without having to explicitly create credentials for each application.\n\nFor an application to gain access into a MinIO Tenant, a `PolicyBinding` resource is required, granting explicit access to the applications by validating the kubernetes [Service Account](https://kubernetes.io/docs/concepts/security/service-accounts/) authorization token. \n\nThe service account token is validated as follows:\n\n1. The application calls `AssumeRoleWithWebIdentity` API MinIO Operator provides.\n2. MinIO Operator verifies the Service Account token agains the kubernetes API using the [TokenReview API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1/)\n3. MinIO Operator reviews the TokenReviewResult confirms if the token is a valid token and the user is authenticated.\n4. MinIO Operator validates the service account has `PolicyBinding` in the Tenant namespace.\n5. MinIO Operator gets the PolicyBinding\n6. MinIO Operator calls the AssumeRole API in the MinIO Tenant\n7. MinIO Operator obtains temporary credentials (STS).\n8. MinIO Operator return temporary Credentials to the requester application.\n9. The applicaiton consumes Object Storage using the temporary credentials.\n\n\n\n## Understanding Audiences in Kubernetes TokenReview\n\nIn step 2 the `TokenReview` API call attempts to authenticate a token to a known user, TokenReviewStatus is the result of the `TokenReview` request.\n\nAudiences are audience identifiers chosen by the authenticator that are compatible with both the TokenReview and token. \n\nAn identifier is any identifier in the intersection of the TokenReviewSpec audiences and the token\u0027s audiences.\n\nA client of the TokenReview API that sets the `spec.audiences` field should validate that a compatible audience identifier is returned in the status.audiences field to ensure that the TokenReview server is audience aware. \n**If no audiences are provided, the audience will default to the audience of the Kubernetes apiserver.**\n\n## Solution: Properly Issuing and Using Audience-Specific ServiceAccount Tokens\n\nThis PR ensures the Operator STS service request the Service Account JWT to belong to the audience`sts.min.io` in the TokenReviewRequest.\n\nThis PR ensures the examples and documentation provided guides in how to create Service accounts with \"disabled auto mount services tokens\", by doing this the pods where the service account is used no longer mounts the service account automatically in the path `/var/run/secrets/kubernetes.io/serviceaccount`.\n\nFor illustrative purposes, here is how you disable auto mount of service account tokens at the service account level.\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n namespace: namespace-name\n name: service-account name\nautomountServiceAccountToken: false\n```\n\nAdditionally documentation and examples show how to request an audience-specific token with audience `sts.min.io`, by asking for an ServiceAccount Token to be audience specific.\n\nFor illustrative purposes, here is how you request an audience specific service account token in a pod:\n\n```yaml\napiVersion: batch/v1\nkind: Job\nmetadata:\n name: job-name\n namespace: job-namespace\nspec:\n template:\n spec:\n serviceAccountName: service-account-name\n volumes:\n - name: sa-token\n projected:\n sources:\n - serviceAccountToken:\n audience: \"sts.min.io\"\n expirationSeconds: 86400\n path: token\n containers:\n - name: mc\n...\n volumeMounts:\n - name: sa-token\n mountPath: /var/run/secrets/sts.min.io/serviceaccount\n readOnly: true\n```\n\n### How this prevent a token leakage or possible privilege escalation?.\n\nThis setup prevents privilege escalation and token leakage by combining multiple defense-in-depth mechanisms that ensure service account tokens are only usable by their intended audience, short-lived, and not exposed unnecessarily.\n\n#### Audience restriction (aud: sts.min.io)\n\n**Problem**: A ServiceAccount token is often valid for multiple audiences (e.g., the default Kubernetes API server). Without scoping, it can be replayed to other internal systems, which may unintentionally trust it.\n\n**Mitigation**: Now we enforce that tokens are explicitly created for the sts.min.io audience using the Kubernetes TokenRequest API, and the MinIO Operator:\n\nSends audiences: [\"sts.min.io\"] in the TokenReview.\n\nVerifies that the token was issued with this audience via status.audiences.\n\n**Effect**: Even if a token is stolen or misused, it will fail validation if used outside the sts.min.io STS endpoint (e.g., reused at the API server or another service).\n\n#### Token Leakage Mitigation\n\nDisabling auto-mounted service account tokens\n\n**Problem**: By default, Kubernetes mounts long-lived service account tokens into all pods at `/var/run/secrets/kubernetes.io/serviceaccount`, making them vulnerable to theft if the container is compromised.\n\n**Mitigation**: No we guide users to set `automountServiceAccountToken: false` in their ServiceAccount definitions.\n\n**Effect**: Prevents automatic token injection into all pods, reducing the attack surface.\n\n#### Requesting short-lived, audience-specific tokens via serviceAccountToken projection\n\n**Problem**: Long-lived tokens can be reused indefinitely if leaked.\n**Mitigation**: You use projected service account tokens with: \n- audience: \"sts.min.io\"\n- A short expirationSeconds (e.g., 86400 = 24 hours, or even shorter)\n\n**Effect**: Even if the token is leaked, it is:\n\n- Only usable for sts.min.io\n- Short-lived and expires soon\n- Revocable by disabling the SA or STS access\n\n## Affected Versions and Risk Assessment\nThe issue affects MinIO Operator versions v5.0.x and above, when the STS feature was first introduced.\n\n* In v5.0.x, STS was introduced as v1alpha1 and disabled by default. It required explicit API calls to be used.\n* In v6.0.x, STS graduated to v1beta1 and was enabled by default, but still requires explicit calls to the STS API for token usage.\n\nThe risk is minimal, as:\n\n* The Operator does not persist the token (neither in memory nor on disk).\n* The Operator only uses the token for a single validation and does not reuse it for any other purpose.\n\n# Release\nFix released in [v7.1.0](https://github.com/minio/operator/releases/tag/v7.1.0)",
"id": "GHSA-7m6v-q233-q9j9",
"modified": "2026-01-23T17:16:26Z",
"published": "2025-04-21T22:51:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/minio/operator/security/advisories/GHSA-7m6v-q233-q9j9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32963"
},
{
"type": "WEB",
"url": "https://github.com/minio/operator/commit/d586294d526bf0d8e6097225114655f68b0adcc5"
},
{
"type": "PACKAGE",
"url": "https://github.com/minio/operator"
},
{
"type": "WEB",
"url": "https://github.com/minio/operator/releases/tag/v7.1.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Minio Operator uses Kubernetes apiserver audience for AssumeRoleWithWebIdentity STS"
}
GHSA-7MC2-6PHR-23XC
Vulnerability from github – Published: 2025-06-30 17:43 – Updated: 2025-07-01 13:13Summary
Private key can be extracted on signing a malicious JSON-stringifiable object, when global Buffer is buffer package
Details
This affects only environments where require('buffer') is https://npmjs.com/buffer
E.g.: browser bundles, React Native apps, etc.
Buffer.isBuffer check can be bypassed, resulting in k reuse for different messages, leading to private key extraction over a single invalid message (and a second one for which any message/signature could be taken, e.g. previously known valid one)
v2.x is unaffected as it verifies input to be an actual Uint8Array instance
Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction
While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still should not leak the private key
Also, message validation could have the same bug (out of scope for this report, but could be possible in some situations), which makes this attack more likely when used in a chain
https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this
PoC
This code deliberately doesn't provide funnyBuffer and extractTiny for now, could be updated later
import secp256k1 from 'tiny-secp256k1'
import crypto from 'crypto'
const key = crypto.randomBytes(32)
const msg0 = crypto.randomBytes(32)
const sig0 = secp256k1.sign(msg0, key).toString('hex')
const msg1 = funnyBuffer(msg0)
const sig1 = secp256k1.sign(msg1, key).toString('hex')
const restored = extractTiny(msg0, sig0, sig1)
console.log('Guesses:', JSON.stringify(restored, undefined, 2))
const recheck = (k) => secp256k1.sign(msg0, Buffer.from(k, 'hex')).toString('hex') === sig0
console.log('Rechecked:', JSON.stringify(restored.filter(recheck)))
console.log('Actual key', key.toString('hex'))
Output:
Guesses: [
"8f351953047e6b149e0595547e7d10a8a1edc61bd519b5b2514202a495e434ed",
"ebc81e1632a1b3255589ba84364949a0a6fd0229444519765570706d394671dd"
]
Rechecked: ["ebc81e1632a1b3255589ba84364949a0a6fd0229444519765570706d394671dd"]
Actual key ebc81e1632a1b3255589ba84364949a0a6fd0229444519765570706d394671dd
Impact
Full private key extraction when signing a single malicious message (that passes JSON.stringify/JSON.parse and can come from network)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.6"
},
"package": {
"ecosystem": "npm",
"name": "tiny-secp256k1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-49364"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-30T17:43:39Z",
"nvd_published_at": "2025-07-01T03:15:21Z",
"severity": "HIGH"
},
"details": "### Summary\n\nPrivate key can be extracted on signing a malicious JSON-stringifiable object, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer)\n\n### Details\n\nThis affects only environments where `require(\u0027buffer\u0027)` is \u003chttps://npmjs.com/buffer\u003e\nE.g.: browser bundles, React Native apps, etc.\n\n`Buffer.isBuffer` check can be bypassed, resulting in `k` reuse for different messages, leading to private key extraction over a single invalid message (and a second one for which any message/signature could be taken, e.g. previously known valid one)\n\nv2.x is unaffected as it verifies input to be an actual `Uint8Array` instance\n\nSuch a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction\n\nWhile signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still should not leak the private key\n\nAlso, message validation could have the same bug (out of scope for this report, but could be possible in some situations), which makes this attack more likely when used in a chain\n\nhttps://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this\n\n### PoC\n\nThis code deliberately doesn\u0027t provide `funnyBuffer` and `extractTiny` for now, could be updated later\n\n```js\nimport secp256k1 from \u0027tiny-secp256k1\u0027\nimport crypto from \u0027crypto\u0027\n\nconst key = crypto.randomBytes(32)\n\nconst msg0 = crypto.randomBytes(32)\nconst sig0 = secp256k1.sign(msg0, key).toString(\u0027hex\u0027)\n\nconst msg1 = funnyBuffer(msg0)\nconst sig1 = secp256k1.sign(msg1, key).toString(\u0027hex\u0027)\n\nconst restored = extractTiny(msg0, sig0, sig1)\nconsole.log(\u0027Guesses:\u0027, JSON.stringify(restored, undefined, 2))\nconst recheck = (k) =\u003e secp256k1.sign(msg0, Buffer.from(k, \u0027hex\u0027)).toString(\u0027hex\u0027) === sig0\nconsole.log(\u0027Rechecked:\u0027, JSON.stringify(restored.filter(recheck)))\n\nconsole.log(\u0027Actual key\u0027, key.toString(\u0027hex\u0027))\n```\n\nOutput:\n```console\nGuesses: [\n \"8f351953047e6b149e0595547e7d10a8a1edc61bd519b5b2514202a495e434ed\",\n \"ebc81e1632a1b3255589ba84364949a0a6fd0229444519765570706d394671dd\"\n]\nRechecked: [\"ebc81e1632a1b3255589ba84364949a0a6fd0229444519765570706d394671dd\"]\nActual key ebc81e1632a1b3255589ba84364949a0a6fd0229444519765570706d394671dd\n```\n\n### Impact\n\nFull private key extraction when signing a single malicious message (that passes `JSON.stringify`/`JSON.parse` and can come from network)",
"id": "GHSA-7mc2-6phr-23xc",
"modified": "2025-07-01T13:13:29Z",
"published": "2025-06-30T17:43:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bitcoinjs/tiny-secp256k1/security/advisories/GHSA-7mc2-6phr-23xc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49364"
},
{
"type": "WEB",
"url": "https://github.com/bitcoinjs/tiny-secp256k1/pull/140"
},
{
"type": "PACKAGE",
"url": "https://github.com/bitcoinjs/tiny-secp256k1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "tiny-secp256k1 vulnerable to private key extraction when signing a malicious JSON-stringifyable message in bundled environment"
}
GHSA-7MPH-V368-WMV3
Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2023-03-08 00:30Insufficiently protected credentials in the Intel(R) ON Event Series Android application before version 2.0 may allow an authenticated user to potentially enable information disclosure via local access.
{
"affected": [],
"aliases": [
"CVE-2022-41614"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-16T21:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficiently protected credentials in the Intel(R) ON Event Series Android application before version 2.0 may allow an authenticated user to potentially enable information disclosure via local access.",
"id": "GHSA-7mph-v368-wmv3",
"modified": "2023-03-08T00:30:34Z",
"published": "2023-02-16T21:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41614"
},
{
"type": "WEB",
"url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00776.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"
}
]
}
GHSA-7P36-WH9X-8C9P
Vulnerability from github – Published: 2025-10-23 21:31 – Updated: 2025-10-23 21:31Oxford Nanopore Technologies' MinKNOW software at or prior to version 24.11 stores authentication tokens in a file located in the system's temporary directory (/tmp) on the host machine. This directory is typically world-readable, allowing any local user or application to access the token. If the token is leaked (e.g., via malware infection or other local exploit), and remote access is enabled, it can be used to establish unauthorized remote connections to the sequencer. Remote access must be enabled for remote exploitation to succeed. This may occur either because the user has enabled remote access for legitimate operational reasons or because malware with elevated privileges (e.g., sudo access) enables it without user consent. This vulnerability can be chained with remote access capabilities to generate a developer token from a remote device. Developer tokens can be created with arbitrary expiration dates, enabling persistent access to the sequencer and bypassing standard authentication mechanisms.
{
"affected": [],
"aliases": [
"CVE-2025-54808"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-23T19:15:50Z",
"severity": "HIGH"
},
"details": "Oxford Nanopore Technologies\u0027 MinKNOW software at or prior to version 24.11 stores authentication tokens in a file located in the system\u0027s temporary directory (/tmp) on the host machine. This directory is typically world-readable, allowing any local user or application to access the token. If the token is leaked (e.g., via malware infection or other local exploit), and remote access is enabled, it can be used to establish unauthorized remote connections to the sequencer. Remote access must be enabled for remote exploitation to succeed. This may occur either because the user has enabled remote access for legitimate operational reasons or because malware with elevated privileges (e.g., sudo access) enables it without user consent. This vulnerability can be chained with remote access capabilities to generate a developer token from a remote device. Developer tokens can be created with arbitrary expiration dates, enabling persistent access to the sequencer and bypassing standard authentication mechanisms.",
"id": "GHSA-7p36-wh9x-8c9p",
"modified": "2025-10-23T21:31:43Z",
"published": "2025-10-23T21:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54808"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2025/icsma-25-294-01.json"
},
{
"type": "WEB",
"url": "https://nanoporetech.com/about/contact"
},
{
"type": "WEB",
"url": "https://nanoporetech.com/software"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-medical-advisories/icsma-25-294-01"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/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-7P8M-22H4-9PJ7
Vulnerability from github – Published: 2023-01-20 22:38 – Updated: 2023-01-20 22:38Impact
When the scs-library-client is used to pull a container image, with authentication, the HTTP Authorization header sent by the client to the library service may be incorrectly leaked to an S3 backing storage provider. This occurs in a specific flow, where the library service redirects the client to a backing S3 storage server, to perform a multi-part concurrent download.
Depending on site configuration, the S3 service may be provided by a third party. An attacker with access to the S3 service may be able to extract user credentials, allowing them to impersonate the user.
The vulnerable multi-part concurrent download flow, with redirect to S3, is only used when communicating with a Singularity Enterprise 1.x installation, or third party server implementing this flow.
Interaction with Singularity Enterprise 2.x, and Singularity Container Services (cloud.sylabs.io), does not trigger the vulnerable flow.
We encourage all users to update. Users who interact with a Singularity Enterprise 1.x installation, using a 3rd party S3 storage service, are advised to revoke and recreate their authentication tokens within Singularity Enterprise.
Patches
The security issue was identified after the integration of a bug-fix commit 68ac4ca into the previously released scs-library-client 1.3.4. This commit fixes the security issue in the 1.3 series.
scs-library-client 1.4.2 contains a fix for the same vulnerability in the 1.4 series, as commit eebd7ca.
Workarounds
There is no workaround available at this time.
As above, access to Singularity Enterprise 2.x, or Singularity Container Services (cloud.sylabs.io), does not trigger the vulnerable flow.
References
https://cwe.mitre.org/data/definitions/522.html
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/sylabs/scs-library-client"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.4.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/sylabs/scs-library-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23538"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-20T22:38:04Z",
"nvd_published_at": "2023-01-17T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen the scs-library-client is used to pull a container image, with authentication, the HTTP Authorization header sent by the client to the library service may be incorrectly leaked to an S3 backing storage provider. This occurs in a specific flow, where the library service redirects the client to a backing S3 storage server, to perform a multi-part concurrent download.\n\nDepending on site configuration, the S3 service may be provided by a third party. An attacker with access to the S3 service may be able to extract user credentials, allowing them to impersonate the user.\n\nThe vulnerable multi-part concurrent download flow, with redirect to S3, is only used when communicating with a Singularity Enterprise 1.x installation, or third party server implementing this flow.\n\nInteraction with Singularity Enterprise 2.x, and Singularity Container Services (cloud.sylabs.io), does not trigger the vulnerable flow.\n\nWe encourage all users to update. Users who interact with a Singularity Enterprise 1.x installation, using a 3rd party S3 storage service, are advised to revoke and recreate their authentication tokens within Singularity Enterprise.\n\n### Patches\n\nThe security issue was identified after the integration of a bug-fix commit 68ac4ca into the previously released scs-library-client 1.3.4. This commit fixes the security issue in the 1.3 series.\n\nscs-library-client 1.4.2 contains a fix for the same vulnerability in the 1.4 series, as commit eebd7ca.\n\n### Workarounds\n\nThere is no workaround available at this time.\n\nAs above, access to Singularity Enterprise 2.x, or Singularity Container Services (cloud.sylabs.io), does not trigger the vulnerable flow.\n\n### References\n\nhttps://cwe.mitre.org/data/definitions/522.html\n",
"id": "GHSA-7p8m-22h4-9pj7",
"modified": "2023-01-20T22:38:04Z",
"published": "2023-01-20T22:38:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sylabs/scs-library-client/security/advisories/GHSA-7p8m-22h4-9pj7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23538"
},
{
"type": "WEB",
"url": "https://github.com/sylabs/scs-library-client/commit/68ac4cab5cda0afd8758ff5b5e2e57be6a22fcfa"
},
{
"type": "WEB",
"url": "https://github.com/sylabs/scs-library-client/commit/b5db2aacba6bf1231f42dd475cc32e6355ab47b2"
},
{
"type": "WEB",
"url": "https://github.com/sylabs/scs-library-client/commit/eebd7caaab310b1fa803e55b8fc1acd9dcd2d00c"
},
{
"type": "PACKAGE",
"url": "https://github.com/sylabs/scs-library-client"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2023-1497"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "scs-library-client may leak user credentials to third-party service via HTTP redirect"
}
GHSA-7PC3-HJ79-39QJ
Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2023-02-27 21:30An insufficiently protected credentials in Fortinet FortiNAC versions 9.4.0, 9.2.0 through 9.2.5, 9.1.0 through 9.1.7, 8.8.0 through 8.8.11, 8.7.0 through 8.7.6, 8.6.0 through 8.6.5, 8.5.0 through 8.5.4, 8.3.7 may allow a local attacker with database access to recover user passwords.
{
"affected": [],
"aliases": [
"CVE-2022-40678"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-16T19:15:00Z",
"severity": "HIGH"
},
"details": "An insufficiently protected credentials in Fortinet FortiNAC versions 9.4.0, 9.2.0 through 9.2.5, 9.1.0 through 9.1.7, 8.8.0 through 8.8.11, 8.7.0 through 8.7.6, 8.6.0 through 8.6.5, 8.5.0 through 8.5.4, 8.3.7 may allow a local attacker with database access to recover user passwords.",
"id": "GHSA-7pc3-hj79-39qj",
"modified": "2023-02-27T21:30:34Z",
"published": "2023-02-16T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40678"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-22-265"
}
],
"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-7PCQ-9P5G-VH97
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03The Tableau integration in RSA Archer 6.4 P1 (6.4.0.1) through 6.9 P2 (6.9.0.2) is affected by an insecure credential storage vulnerability. An malicious attacker with access to the Tableau workbook file may obtain access to credential information to use it in further attacks.
{
"affected": [],
"aliases": [
"CVE-2021-29253"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-26T04:15:00Z",
"severity": "MODERATE"
},
"details": "The Tableau integration in RSA Archer 6.4 P1 (6.4.0.1) through 6.9 P2 (6.9.0.2) is affected by an insecure credential storage vulnerability. An malicious attacker with access to the Tableau workbook file may obtain access to credential information to use it in further attacks.",
"id": "GHSA-7pcq-9p5g-vh97",
"modified": "2022-05-24T19:03:23Z",
"published": "2022-05-24T19:03:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29253"
},
{
"type": "WEB",
"url": "https://community.rsa.com/t5/archer-product-advisories/rsa-2021-04-archer-an-rsa-business-update-for-multiple/ta-p/603223"
},
{
"type": "WEB",
"url": "https://www.rsa.com/en-us/company/vulnerability-response-policy"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Use an appropriate security mechanism to protect the credentials.
Mitigation
Make appropriate use of cryptography to protect the credentials.
Mitigation
Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-474: Signature Spoofing by Key Theft
An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.
CAPEC-50: Password Recovery Exploitation
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-560: Use of Known Domain Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
CAPEC-600: Credential Stuffing
An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.
CAPEC-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-653: Use of Known Operating System Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.