CWE-693
DiscouragedProtection Mechanism Failure
Abstraction: Pillar · Status: Draft
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
1336 vulnerabilities reference this CWE, most recent first.
GHSA-MQ42-J95V-P3GQ
Vulnerability from github – Published: 2026-06-11 18:31 – Updated: 2026-06-11 18:31KanaDojo before 0.1.18 contains a sandbox escape vulnerability that allows an attacker to execute arbitrary code by exploiting the explicit passing of the global require function into a Node.js vm.runInNewContext() sandbox context in the issue-auto-respond.yml workflow. Attackers can submit a pull request modifying messages.cjs to import arbitrary Node.js modules, bypassing sandbox restrictions and achieving remote code execution with full GitHub Actions runner privileges including access to AUTOMATION_PR_TOKEN.
{
"affected": [],
"aliases": [
"CVE-2026-48546"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-11T18:16:26Z",
"severity": "HIGH"
},
"details": "KanaDojo before 0.1.18 contains a sandbox escape vulnerability that allows an attacker to execute arbitrary code by exploiting the explicit passing of the global require function into a Node.js vm.runInNewContext() sandbox context in the issue-auto-respond.yml workflow. Attackers can submit a pull request modifying messages.cjs to import arbitrary Node.js modules, bypassing sandbox restrictions and achieving remote code execution with full GitHub Actions runner privileges including access to AUTOMATION_PR_TOKEN.",
"id": "GHSA-mq42-j95v-p3gq",
"modified": "2026-06-11T18:31:35Z",
"published": "2026-06-11T18:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48546"
},
{
"type": "WEB",
"url": "https://github.com/lingdojo/kana-dojo/commit/31b85a5d7c4b323ddeba3b2dc5e7807558710544"
},
{
"type": "WEB",
"url": "https://github.com/lingdojo/kana-dojo/releases/tag/v0.1.18"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/kanadojo-sandbox-escape-rce-via-messages-cjs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-MQC2-W9R8-MMXM
Vulnerability from github – Published: 2022-10-19 19:00 – Updated: 2022-10-22 01:13A sandbox bypass vulnerability involving various casts performed implicitly by the Groovy language runtime in Jenkins Pipeline: Groovy Plugin 2802.v5ea_628154b_c2 and earlier allows attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM. Pipeline: Groovy Plugin 2803.v1a_f77ffcc773 intercepts Groovy casts performed implicitly by the Groovy language runtime
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2803.v1a"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins.workflow:workflow-cps"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2803.v1a_f77ffcc773"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-43402"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-19T22:04:22Z",
"nvd_published_at": "2022-10-19T16:15:00Z",
"severity": "CRITICAL"
},
"details": "A sandbox bypass vulnerability involving various casts performed implicitly by the Groovy language runtime in Jenkins Pipeline: Groovy Plugin 2802.v5ea_628154b_c2 and earlier allows attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM. Pipeline: Groovy Plugin 2803.v1a_f77ffcc773 intercepts Groovy casts performed implicitly by the Groovy language runtime",
"id": "GHSA-mqc2-w9r8-mmxm",
"modified": "2022-10-22T01:13:25Z",
"published": "2022-10-19T19:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43402"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2824%20(1)"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/10/19/3"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Pipeline: Groovy Plugin allows sandbox protection bypass and arbitrary code execution"
}
GHSA-MR9P-7CC9-FH7R
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 15:35Insufficient policy enforcement in DevTools in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-13909"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:04Z",
"severity": "CRITICAL"
},
"details": "Insufficient policy enforcement in DevTools in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-mr9p-7cc9-fh7r",
"modified": "2026-07-01T15:35:02Z",
"published": "2026-07-01T00:34:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13909"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/505933538"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MV7W-74C6-4W37
Vulnerability from github – Published: 2022-12-15 21:30 – Updated: 2022-12-20 15:30A logic issue was addressed with improved checks. This issue is fixed in iOS 16.2 and iPadOS 16.2, iOS 15.7.2 and iPadOS 15.7.2, tvOS 16.2. An app may be able to execute arbitrary code with kernel privileges.
{
"affected": [],
"aliases": [
"CVE-2022-42848"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-15T19:15:00Z",
"severity": "HIGH"
},
"details": "A logic issue was addressed with improved checks. This issue is fixed in iOS 16.2 and iPadOS 16.2, iOS 15.7.2 and iPadOS 15.7.2, tvOS 16.2. An app may be able to execute arbitrary code with kernel privileges.",
"id": "GHSA-mv7w-74c6-4w37",
"modified": "2022-12-20T15:30:37Z",
"published": "2022-12-15T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42848"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213530"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213531"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213535"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Dec/20"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Dec/21"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Dec/26"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MW76-22G7-FW96
Vulnerability from github – Published: 2026-09-29 15:31 – Updated: 2026-10-01 18:32Sandbox escape in the Graphics component. This vulnerability was fixed in Firefox ESR 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.
{
"affected": [],
"aliases": [
"CVE-2026-100775"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-29T13:17:42Z",
"severity": "CRITICAL"
},
"details": "Sandbox escape in the Graphics component. This vulnerability was fixed in Firefox ESR 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17.",
"id": "GHSA-mw76-22g7-fw96",
"modified": "2026-10-01T18:32:38Z",
"published": "2026-09-29T15:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100775"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2068367"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-100"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-101"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-102"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-103"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-97"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-98"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-99"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MWJ6-RFH8-7QF4
Vulnerability from github – Published: 2026-10-07 20:23 – Updated: 2026-10-07 20:23Summary
Hydra's legacy instantiate() target blocklists and related execution-policy
collections are stored in mutable module-level state. Because _locate() can
resolve attributes on imported objects, a configuration can resolve a mutation
method such as .discard(), modify the active policy, and then instantiate a
target that would otherwise be blocked.
Impact
A configuration controlling multiple sibling _target_ entries can first
remove an entry from a target blocklist and then invoke the removed target.
Sibling nodes are processed in insertion order and consult the same mutable
module-level policy.
This affects the legacy/default path without an execution whitelist. The 1.3 blocklist is a defense-in-depth measure rather than a complete security boundary, and applications must not treat arbitrary untrusted configuration as safe to instantiate or use for Python logging configuration.
Released hydra-core versions 1.3.4 through 1.3.6 and 1.4.0.dev4 through
1.4.0.dev9 are affected. Fixed releases are 1.3.7 and 1.4.0.dev10.
The reported direct mutation path does not bypass an execution whitelist
restricted to intended application targets and supplied by trusted Python
code. During remediation, Hydra additionally hardened generic discovery,
dispatch, introspection, alias, callable-result, and deferred-callable paths
that could otherwise undermine name-only authorization.
Technical details
In hydra-core 1.3.4 and 1.3.5, the mutable blocklist is reachable as:
hydra._internal.instantiate._instantiate2.DEFAULT_BLOCKLISTED_MODULES
In hydra-core 1.3.6, the expanded policy includes mutable collections in:
hydra._internal.target_policy
For example:
hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard
resolves to the bound set.discard method. The mutation target itself is not
blocked on the legacy path. Once an entry is removed, subsequent authorization
checks observe the modified set.
Other runtime policy collections can be attacked similarly by removing denied entries or adding entries to exception sets. Because the collections are module-level state, a successful mutation persists for the lifetime of the Python process unless explicitly reversed.
Safe reproduction
The behavior in hydra-core 1.3.6 can be demonstrated without invoking a shell
command. The finally block restores the modified process-global state:
from omegaconf import OmegaConf
from hydra._internal.target_policy import UNCONTROLLED_EXECUTION_TARGETS
from hydra.utils import instantiate
target = "builtins.eval"
assert target in UNCONTROLLED_EXECUTION_TARGETS
try:
result = instantiate(
OmegaConf.create(
{
"disarm": {
"_target_": (
"hydra._internal.target_policy."
"UNCONTROLLED_EXECUTION_TARGETS.discard"
),
"_args_": [target],
},
"proof": {
"_target_": target,
"_args_": ["40 + 2"],
},
}
)
)
assert result["proof"] == 42
assert target not in UNCONTROLLED_EXECUTION_TARGETS
finally:
UNCONTROLLED_EXECUTION_TARGETS.add(target)
Remediation
The fix makes runtime policy state immutable and integrity checked, and prevents declarative configuration from accessing or mutating Hydra internals and protected Python implementation state. Target authorization now covers canonical resolved identities, aliases, discovery results, callable results, deferred callables, and runtime arguments.
The patch also rejects configuration-driven code, policy, and process- environment mutation, along with unsafe introspection and formatting traversal that can expose protected runtime capabilities.
Hydra 1.3.7 receives these protections as defense in depth; it does not make untrusted configuration sandboxed. Hydra 1.4 additionally uses a trusted, narrowly scoped execution whitelist as the supported security boundary for declarative instantiation and Hydra-controlled Python logging configuration.
Users should upgrade to hydra-core 1.3.7 on the stable line or
1.4.0.dev10 on the development line.
Workarounds
Do not pass configuration from untrusted sources to instantiate() or to
Hydra-controlled Python logging configuration. The 1.3 release line has no
execution-whitelist facility, so users who cannot upgrade immediately must
restrict configuration input to trusted sources.
On affected 1.4 development releases, applications can also supply a trusted, narrowly scoped execution whitelist from Python code. The whitelist itself must not be derived from untrusted configuration.
Restart any long-running process that may already have instantiated untrusted configuration, because a policy mutation persists in process-global state.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "hydra-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.4"
},
{
"fixed": "1.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "hydra-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0.dev4"
},
{
"fixed": "1.4.0.dev10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106439"
],
"database_specific": {
"cwe_ids": [
"CWE-470",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:23:57Z",
"nvd_published_at": "2026-10-06T19:18:12Z",
"severity": "HIGH"
},
"details": "## Summary\n\nHydra\u0027s legacy `instantiate()` target blocklists and related execution-policy\ncollections are stored in mutable module-level state. Because `_locate()` can\nresolve attributes on imported objects, a configuration can resolve a mutation\nmethod such as `.discard()`, modify the active policy, and then instantiate a\ntarget that would otherwise be blocked.\n\n## Impact\n\nA configuration controlling multiple sibling `_target_` entries can first\nremove an entry from a target blocklist and then invoke the removed target.\nSibling nodes are processed in insertion order and consult the same mutable\nmodule-level policy.\n\nThis affects the legacy/default path without an execution whitelist. The 1.3\nblocklist is a defense-in-depth measure rather than a complete security\nboundary, and applications must not treat arbitrary untrusted configuration as\nsafe to instantiate or use for Python logging configuration.\n\nReleased `hydra-core` versions 1.3.4 through 1.3.6 and 1.4.0.dev4 through\n1.4.0.dev9 are affected. Fixed releases are 1.3.7 and 1.4.0.dev10.\nThe reported direct mutation path does not bypass an execution whitelist\nrestricted to intended application targets and supplied by trusted Python\ncode. During remediation, Hydra additionally hardened generic discovery,\ndispatch, introspection, alias, callable-result, and deferred-callable paths\nthat could otherwise undermine name-only authorization.\n\n## Technical details\n\nIn `hydra-core` 1.3.4 and 1.3.5, the mutable blocklist is reachable as:\n\n`hydra._internal.instantiate._instantiate2.DEFAULT_BLOCKLISTED_MODULES`\n\nIn `hydra-core` 1.3.6, the expanded policy includes mutable collections in:\n\n`hydra._internal.target_policy`\n\nFor example:\n\n`hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard`\n\nresolves to the bound `set.discard` method. The mutation target itself is not\nblocked on the legacy path. Once an entry is removed, subsequent authorization\nchecks observe the modified set.\n\nOther runtime policy collections can be attacked similarly by removing denied\nentries or adding entries to exception sets. Because the collections are\nmodule-level state, a successful mutation persists for the lifetime of the\nPython process unless explicitly reversed.\n\n## Safe reproduction\n\nThe behavior in `hydra-core` 1.3.6 can be demonstrated without invoking a shell\ncommand. The `finally` block restores the modified process-global state:\n\n```python\nfrom omegaconf import OmegaConf\n\nfrom hydra._internal.target_policy import UNCONTROLLED_EXECUTION_TARGETS\nfrom hydra.utils import instantiate\n\ntarget = \"builtins.eval\"\nassert target in UNCONTROLLED_EXECUTION_TARGETS\n\ntry:\n result = instantiate(\n OmegaConf.create(\n {\n \"disarm\": {\n \"_target_\": (\n \"hydra._internal.target_policy.\"\n \"UNCONTROLLED_EXECUTION_TARGETS.discard\"\n ),\n \"_args_\": [target],\n },\n \"proof\": {\n \"_target_\": target,\n \"_args_\": [\"40 + 2\"],\n },\n }\n )\n )\n\n assert result[\"proof\"] == 42\n assert target not in UNCONTROLLED_EXECUTION_TARGETS\nfinally:\n UNCONTROLLED_EXECUTION_TARGETS.add(target)\n```\n\n## Remediation\n\nThe fix makes runtime policy state immutable and integrity checked, and\nprevents declarative configuration from accessing or mutating Hydra internals\nand protected Python implementation state. Target authorization now covers\ncanonical resolved identities, aliases, discovery results, callable results,\ndeferred callables, and runtime arguments.\n\nThe patch also rejects configuration-driven code, policy, and process-\nenvironment mutation, along with unsafe introspection and formatting traversal\nthat can expose protected runtime capabilities.\n\nHydra 1.3.7 receives these protections as defense in depth; it does not make\nuntrusted configuration sandboxed. Hydra 1.4 additionally uses a trusted,\nnarrowly scoped execution whitelist as the supported security boundary for\ndeclarative instantiation and Hydra-controlled Python logging configuration.\n\nUsers should upgrade to `hydra-core` 1.3.7 on the stable line or\n1.4.0.dev10 on the development line.\n\n## Workarounds\n\nDo not pass configuration from untrusted sources to `instantiate()` or to\nHydra-controlled Python logging configuration. The 1.3 release line has no\nexecution-whitelist facility, so users who cannot upgrade immediately must\nrestrict configuration input to trusted sources.\n\nOn affected 1.4 development releases, applications can also supply a trusted,\nnarrowly scoped execution whitelist from Python code. The whitelist itself must\nnot be derived from untrusted configuration.\n\nRestart any long-running process that may already have instantiated untrusted\nconfiguration, because a policy mutation persists in process-global state.",
"id": "GHSA-mwj6-rfh8-7qf4",
"modified": "2026-10-07T20:23:58Z",
"published": "2026-10-07T20:23:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/security/advisories/GHSA-mwj6-rfh8-7qf4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106439"
},
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/commit/0dd18084589a3d3e577d1f1a8a48fb485c94a5e6"
},
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/commit/4720dfca2bde27fa140ec287a05709668fbdf168"
},
{
"type": "PACKAGE",
"url": "https://github.com/hydra-ecosystem/hydra"
},
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/releases/tag/v1.3.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hydra: Mutable instantiate policy sets allow target blocklist bypass"
}
GHSA-MXGQ-5VG7-JCFP
Vulnerability from github – Published: 2026-09-14 21:31 – Updated: 2026-09-17 18:31A logic issue was addressed with improved checks. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to bypass Gatekeeper checks.
{
"affected": [],
"aliases": [
"CVE-2026-84570"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T21:17:33Z",
"severity": "MODERATE"
},
"details": "A logic issue was addressed with improved checks. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. An app may be able to bypass Gatekeeper checks.",
"id": "GHSA-mxgq-5vg7-jcfp",
"modified": "2026-09-17T18:31:34Z",
"published": "2026-09-14T21:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84570"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149035"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149042"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/149043"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P2G6-JJWG-33V4
Vulnerability from github – Published: 2026-08-17 12:32 – Updated: 2026-08-17 12:32openssl_encrypt versions before 1.4.0 contain a sandbox bypass vulnerability where the plugin sandbox fails to restrict alternative file access methods like pathlib.Path and io.open. Attackers can import pathlib or io modules to read and write arbitrary files, completely bypassing the restricted_open file access controls.
{
"affected": [],
"aliases": [
"CVE-2026-74883"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-17T11:16:42Z",
"severity": "HIGH"
},
"details": "openssl_encrypt versions before 1.4.0 contain a sandbox bypass vulnerability where the plugin sandbox fails to restrict alternative file access methods like pathlib.Path and io.open. Attackers can import pathlib or io modules to read and write arbitrary files, completely bypassing the restricted_open file access controls.",
"id": "GHSA-p2g6-jjwg-33v4",
"modified": "2026-08-17T12:32:24Z",
"published": "2026-08-17T12:32:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-mcjj-qw7m-j3cp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74883"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-sandbox-bypass-via-pathlib-and-io"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-P2JM-6HJ6-9RJG
Vulnerability from github – Published: 2026-10-08 16:49 – Updated: 2026-10-08 16:49Impact
The cookie store ignores the scheme a Set-Cookie arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the Secure attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only Secure handling is on retrieval, where a Secure cookie is not sent over plaintext.
So anyone who can answer a plaintext request to a site can set, replace or delete the site's Secure cookies, and the next HTTPS request carries the attacker's value back inside TLS:
http://example.com -> Set-Cookie: SID=attacker-value; Secure; Path=/
https://example.com -> Cookie: SID=attacker-value
This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie:
http://insecure.example.com -> Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/
https://bank.example.com -> Cookie: SID=attacker-value
A plaintext Set-Cookie of the same name, domain and path overwrites a Secure cookie, and one with Max-Age=0 deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed.
Affected versions
- 3.x: up to and including 3.0.13
- 2.x: from 2.1.0, when the cookie store was introduced, up to and including 2.16.1
Patches
Fixed in 3.0.14 on the 3.x line. A cookie with the Secure attribute is ignored unless the request was secure, and a non-Secure cookie from a request that did not use TLS is ignored when it would overlay a Secure cookie of the same name whose path its own path falls under. A plaintext response can therefore no longer plant, overwrite or delete a Secure cookie.
When several cookies of one name match a request, the client sends only the first, so the order in which the store returns them decides which one is used. That order is now: on a secure request, cookies received in a secure context (HTTPS, WSS or plaintext loopback) first; then the request host's own cookies before cookies set for a parent domain; then, within one host, longer paths first. A plaintext attacker cannot outrank a cookie the site set over HTTPS by ordering or padding its own cookies, or by setting one before the site sets its own.
Plaintext requests to localhost, or to an address literal that is a loopback address, count as secure, so a development server that sets Secure cookies over http://localhost gets them back. This is limited to the cookies such a server set itself: a Secure cookie that arrived over HTTPS is never sent over plaintext, loopback included, and a plaintext loopback port cannot overlay it. Numeric spellings that are not address literals, such as 127.0.0.256, and names under localhost are not treated as loopback, because the client resolves them as names.
The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.
Workarounds
Do not share one CookieStore between plaintext and HTTPS origins that are not mutually trusted, including hosts under the same site. Disabling the cookie store also avoids it.
Details
ThreadSafeCookieStore.add(Uri, Cookie) reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie. get(Uri) does read it, but only to leave Secure cookies out of plaintext requests.
A narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext SID for Path=/ is legitimately stored beside a Secure SID for Path=/account, and both match a request under /account. The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request (RequestBuilderBase.addCookieIfUnset), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it.
The fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a __Host- cookie name prefix prevents that, and the client does not enforce cookie name prefixes.
Attribution
AI-assisted tools were used to support discovery and analysis.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.13"
},
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.asynchttpclient:async-http-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"last_affected": "2.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107226"
],
"database_specific": {
"cwe_ids": [
"CWE-384",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T16:49:59Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\nThe cookie store ignores the scheme a `Set-Cookie` arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the `Secure` attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only `Secure` handling is on retrieval, where a Secure cookie is not sent over plaintext.\n\nSo anyone who can answer a plaintext request to a site can set, replace or delete the site\u0027s `Secure` cookies, and the next HTTPS request carries the attacker\u0027s value back inside TLS:\n\n```\nhttp://example.com -\u003e Set-Cookie: SID=attacker-value; Secure; Path=/\nhttps://example.com -\u003e Cookie: SID=attacker-value\n```\n\nThis does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie:\n\n```\nhttp://insecure.example.com -\u003e Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/\nhttps://bank.example.com -\u003e Cookie: SID=attacker-value\n```\n\nA plaintext `Set-Cookie` of the same name, domain and path overwrites a Secure cookie, and one with `Max-Age=0` deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed.\n\n### Affected versions\n* 3.x: up to and including 3.0.13\n* 2.x: from 2.1.0, when the cookie store was introduced, up to and including 2.16.1\n\n### Patches\nFixed in 3.0.14 on the 3.x line. A cookie with the `Secure` attribute is ignored unless the request was secure, and a non-Secure cookie from a request that did not use TLS is ignored when it would overlay a Secure cookie of the same name whose path its own path falls under. A plaintext response can therefore no longer plant, overwrite or delete a `Secure` cookie.\n\nWhen several cookies of one name match a request, the client sends only the first, so the order in which the store returns them decides which one is used. That order is now: on a secure request, cookies received in a secure context (HTTPS, WSS or plaintext loopback) first; then the request host\u0027s own cookies before cookies set for a parent domain; then, within one host, longer paths first. A plaintext attacker cannot outrank a cookie the site set over HTTPS by ordering or padding its own cookies, or by setting one before the site sets its own.\n\nPlaintext requests to `localhost`, or to an address literal that is a loopback address, count as secure, so a development server that sets `Secure` cookies over `http://localhost` gets them back. This is limited to the cookies such a server set itself: a `Secure` cookie that arrived over HTTPS is never sent over plaintext, loopback included, and a plaintext loopback port cannot overlay it. Numeric spellings that are not address literals, such as `127.0.0.256`, and names under `localhost` are not treated as loopback, because the client resolves them as names.\n\nThe 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.\n\n### Workarounds\nDo not share one `CookieStore` between plaintext and HTTPS origins that are not mutually trusted, including hosts under the same site. Disabling the cookie store also avoids it.\n\n### Details\n`ThreadSafeCookieStore.add(Uri, Cookie)` reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie. `get(Uri)` does read it, but only to leave `Secure` cookies out of plaintext requests.\n\nA narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext `SID` for `Path=/` is legitimately stored beside a Secure `SID` for `Path=/account`, and both match a request under `/account`. The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request (`RequestBuilderBase.addCookieIfUnset`), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it.\n\nThe fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a `__Host-` cookie name prefix prevents that, and the client does not enforce cookie name prefixes.\n\n### Attribution\n\nAI-assisted tools were used to support discovery and analysis.",
"id": "GHSA-p2jm-6hj6-9rjg",
"modified": "2026-10-08T16:49:59Z",
"published": "2026-10-08T16:49:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-p2jm-6hj6-9rjg"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/commit/6ec7ee45034d154f502852a962d2891746fb82c1"
},
{
"type": "PACKAGE",
"url": "https://github.com/AsyncHttpClient/async-http-client"
},
{
"type": "WEB",
"url": "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "AsyncHttpClient: Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS"
}
GHSA-P2RM-QHFF-72QF
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31A vulnerability in the data acquisition (DAQ) component of Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to bypass configured access control policies or cause a denial of service (DoS) condition. The vulnerability exists because the affected software improperly manages system memory resources when inspecting traffic. An attacker could exploit this vulnerability by generating specific traffic patterns for the software to inspect. A successful exploit could allow the attacker to exhaust system memory resources used for traffic inspection. Depending on the configuration, the FTD Software could fail open and cease to inspect traffic or fail closed and result in a DoS condition. This vulnerability may require manual intervention to restore the software.
{
"affected": [],
"aliases": [
"CVE-2019-1669"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-24T16:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the data acquisition (DAQ) component of Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to bypass configured access control policies or cause a denial of service (DoS) condition. The vulnerability exists because the affected software improperly manages system memory resources when inspecting traffic. An attacker could exploit this vulnerability by generating specific traffic patterns for the software to inspect. A successful exploit could allow the attacker to exhaust system memory resources used for traffic inspection. Depending on the configuration, the FTD Software could fail open and cease to inspect traffic or fail closed and result in a DoS condition. This vulnerability may require manual intervention to restore the software.",
"id": "GHSA-p2rm-qhff-72qf",
"modified": "2022-05-13T01:31:27Z",
"published": "2022-05-13T01:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1669"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190123-firepowertds-bypass"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106721"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-107: Cross Site Tracing
Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-20: Encryption Brute Forcing
An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-237: Escaping a Sandbox by Calling Code in Another Language
The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content
An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.
CAPEC-480: Escaping Virtualization
An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-65: Sniff Application Code
An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-74: Manipulating State
The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.
State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.
If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.