Common Weakness Enumeration

CWE-696

Allowed-with-Review

Incorrect Behavior Order

Abstraction: Class · Status: Incomplete

The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways that may produce resultant weaknesses.

81 vulnerabilities reference this CWE, most recent first.

GHSA-7C2C-WP2Q-Q5VX

Vulnerability from github – Published: 2025-03-09 00:30 – Updated: 2025-03-09 00:30
VLAI
Details

MariaDB Server 10.4 before 10.4.33, 10.5 before 10.5.24, 10.6 before 10.6.17, 10.7 through 10.11 before 10.11.7, 11.0 before 11.0.5, and 11.1 before 11.1.4 calls fix_fields_if_needed under mysql_derived_prepare when derived is not yet prepared, leading to a find_field_in_table crash.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-08T23:15:13Z",
    "severity": "MODERATE"
  },
  "details": "MariaDB Server 10.4 before 10.4.33, 10.5 before 10.5.24, 10.6 before 10.6.17, 10.7 through 10.11 before 10.11.7, 11.0 before 11.0.5, and 11.1 before 11.1.4 calls fix_fields_if_needed under mysql_derived_prepare when derived is not yet prepared, leading to a find_field_in_table crash.",
  "id": "GHSA-7c2c-wp2q-q5vx",
  "modified": "2025-03-09T00:30:52Z",
  "published": "2025-03-09T00:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52968"
    },
    {
      "type": "WEB",
      "url": "https://jira.mariadb.org/browse/MDEV-32082"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7CV5-2CH3-G323

Vulnerability from github – Published: 2026-05-07 03:31 – Updated: 2026-05-07 03:31
VLAI
Details

Tor before 0.4.9.7 mishandles accounting of the conflux out-of-order queue during the clearing of a queue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-07T03:16:08Z",
    "severity": "LOW"
  },
  "details": "Tor before 0.4.9.7 mishandles accounting of the conflux out-of-order queue during the clearing of a queue.",
  "id": "GHSA-7cv5-2ch3-g323",
  "modified": "2026-05-07T03:31:21Z",
  "published": "2026-05-07T03:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44600"
    },
    {
      "type": "WEB",
      "url": "https://forum.torproject.org/c/news/tor-release-announcement/28"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/tor/-/commit/a198185ed863677d60eec120126730628dac35bb"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/tor/-/work_items/41251"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2026/05/06/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84JC-3HJ2-HWC7

Vulnerability from github – Published: 2026-05-06 23:39 – Updated: 2026-05-06 23:39
VLAI
Summary
kanidmd_lib: Image upload validators run before authorization; PNG validator panics on malformed input
Details

Summary

The POST /v1/domain/_image and POST /v1/oauth2/{rs_name}/_image handlers call validate_image() on the uploaded body before the ACL check that restricts image upload to admins. Any bug in an image validator is therefore reachable by an unauthenticated remote client rather than being admin-gated.

One such bug exists today: png_has_trailer() panics on inputs shorter than 8 bytes, or whose first chunk-length field is near u32::MAX.

On a default build this has no server-wide impact. The panic unwinds only the requester's own tokio task; the server process survives, no shared state is poisoned, and other connections are unaffected. This was reported privately rather than as a public issue because (a) the project previously treated an admin-triggered thread crash of identical impact as security-relevant (e51d0dee4), and this is reachable by a broader population; and (b) a downstream build with panic = "abort" would upgrade it to an unauthenticated process-crash DoS.

Details

Validate-before-authorize ordering

Both handlers parse and validate attacker-controlled bytes before checking whether the caller is permitted to upload at all:

  • server/core/src/https/v1_domain.rs:118image.validate_image() runs; handle_image_update(client_auth_info, …) (the ACL check) is at line 129.
  • server/core/src/https/v1_oauth2.rs:550 — same ordering.

The VerifiedClientInformation extractor (server/core/src/https/extractors/mod.rs:18-90) always returns Ok — it builds a ClientAuthInfo from whatever credentials are present (including none) and does not reject anonymous callers. Authorization is deferred to handle_image_update(), which is never reached if the validator panics or errors first.

PNG validator panic (demonstrator)

validate_image() (server/lib/src/valueset/image/mod.rs:98) checks only a 256 KiB maximum size, not a minimum, before dispatching to the format-specific validator.

Short inputserver/lib/src/valueset/image/png.rs:73-76:

pub fn png_has_trailer(contents: &Vec<u8>) -> Result<bool, ImageValidationError> {
    let buf = contents.as_slice();
    let (magic, buf) = buf.split_at(PNG_PRELUDE.len()); // 8; panics if len < 8

Chunk-length overflowserver/lib/src/valueset/image/png.rs:46,53:

if buf.len() < (length + 4) as usize {   // length: u32; wraps before the usize cast
    ...
}
let (_, buf) = buf.split_at(length as usize);   // panics for length ≈ u32::MAX

In a release build 0xFFFF_FFFC + 4 wraps to 0, the guard passes, and split_at panics.

PoC

printf '\x89PNG' > /tmp/short.png
curl -sk https://$KANIDM_HOST/v1/domain/_image \
     -F 'image=@/tmp/short.png;type=image/png;filename=x.png'
# → connection reset / empty reply; server process remains up

Unit-test confirmation (cargo test -p kanidmd_lib --lib):

#[test]
fn audit_png_short_input_panics() {
    let short = vec![0x89u8, 0x50, 0x4e, 0x47];
    assert!(std::panic::catch_unwind(|| png_has_trailer(&short)).is_err());
}

#[test]
fn audit_png_chunk_length_overflow_panics() {
    let mut data = vec![0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a];
    data.extend_from_slice(&[0xFF, 0xFF, 0xFF, 0xFD]);
    data.extend_from_slice(b"IHDR");
    data.extend_from_slice(&[0u8; 8]);
    assert!(std::panic::catch_unwind(|| png_has_trailer(&data)).is_err());
}

Both tests pass (i.e. both inputs panic).

Impact

The only party affected is the requester, whose own connection is dropped. Repeating the request has no cumulative effect beyond ordinary request load.

On the upstream build:

  • Each connection runs in its own tokio::task::spawn (server/core/src/https/mod.rs:481); the accept loop continues after a task panic.
  • No panic = "abort" in any workspace [profile.*].
  • No Mutex/RwLock held across the call site; nothing is poisoned.
  • The panic occurs before any write actor is messaged; no DB or replication state is touched.

Residual risk: a downstream packager that sets panic = "abort" (or links code that installs an abort handler) would see a full unauthenticated process crash. (No such packager is known)

Affected: v1.1.0-rc.15 (introduced in e7f594a1c, #2112) through master @ edf50b9da.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "kanidmd_lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-20",
      "CWE-696"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:39:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe `POST /v1/domain/_image` and `POST /v1/oauth2/{rs_name}/_image` handlers call `validate_image()` on the uploaded body **before** the ACL check that restricts image upload to admins. Any bug in an image validator is therefore reachable by an unauthenticated remote client rather than being admin-gated.\n\nOne such bug exists today: `png_has_trailer()` panics on inputs shorter than 8 bytes, or whose first chunk-length field is near `u32::MAX`.\n\n**On a default build this has no server-wide impact.** The panic unwinds only the requester\u0027s own tokio task; the server process survives, no shared state is poisoned, and other connections are unaffected. This was reported privately rather than as a public issue because (a) the project previously treated an admin-triggered thread crash of identical impact as security-relevant (e51d0dee4), and this is reachable by a broader population; and (b) a downstream build with `panic = \"abort\"` would upgrade it to an unauthenticated process-crash DoS.\n\n### Details\n\n#### Validate-before-authorize ordering\n\nBoth handlers parse and validate attacker-controlled bytes before checking whether the caller is permitted to upload at all:\n\n- `server/core/src/https/v1_domain.rs:118` \u2014 `image.validate_image()` runs; `handle_image_update(client_auth_info, \u2026)` (the ACL check) is at line 129.\n- `server/core/src/https/v1_oauth2.rs:550` \u2014 same ordering.\n\nThe `VerifiedClientInformation` extractor (`server/core/src/https/extractors/mod.rs:18-90`) always returns `Ok` \u2014 it builds a `ClientAuthInfo` from whatever credentials are present (including none) and does not reject anonymous callers. Authorization is deferred to `handle_image_update()`, which is never reached if the validator panics or errors first.\n\n#### PNG validator panic (demonstrator)\n\n`validate_image()` (`server/lib/src/valueset/image/mod.rs:98`) checks only a 256 KiB maximum size, not a minimum, before dispatching to the format-specific validator.\n\n**Short input** \u2014 `server/lib/src/valueset/image/png.rs:73-76`:\n\n```rust\npub fn png_has_trailer(contents: \u0026Vec\u003cu8\u003e) -\u003e Result\u003cbool, ImageValidationError\u003e {\n    let buf = contents.as_slice();\n    let (magic, buf) = buf.split_at(PNG_PRELUDE.len()); // 8; panics if len \u003c 8\n```\n\n**Chunk-length overflow** \u2014 `server/lib/src/valueset/image/png.rs:46,53`:\n\n```rust\nif buf.len() \u003c (length + 4) as usize {   // length: u32; wraps before the usize cast\n    ...\n}\nlet (_, buf) = buf.split_at(length as usize);   // panics for length \u2248 u32::MAX\n```\n\nIn a release build `0xFFFF_FFFC + 4` wraps to `0`, the guard passes, and `split_at` panics.\n\n### PoC\n\n```sh\nprintf \u0027\\x89PNG\u0027 \u003e /tmp/short.png\ncurl -sk https://$KANIDM_HOST/v1/domain/_image \\\n     -F \u0027image=@/tmp/short.png;type=image/png;filename=x.png\u0027\n# \u2192 connection reset / empty reply; server process remains up\n```\n\nUnit-test confirmation (`cargo test -p kanidmd_lib --lib`):\n\n```rust\n#[test]\nfn audit_png_short_input_panics() {\n    let short = vec![0x89u8, 0x50, 0x4e, 0x47];\n    assert!(std::panic::catch_unwind(|| png_has_trailer(\u0026short)).is_err());\n}\n\n#[test]\nfn audit_png_chunk_length_overflow_panics() {\n    let mut data = vec![0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a];\n    data.extend_from_slice(\u0026[0xFF, 0xFF, 0xFF, 0xFD]);\n    data.extend_from_slice(b\"IHDR\");\n    data.extend_from_slice(\u0026[0u8; 8]);\n    assert!(std::panic::catch_unwind(|| png_has_trailer(\u0026data)).is_err());\n}\n```\n\nBoth tests pass (i.e. both inputs panic).\n\n### Impact\n\nThe only party affected is the requester, whose own connection is dropped. Repeating the request has no cumulative effect beyond ordinary request load.\n\nOn the upstream build:\n\n- Each connection runs in its own `tokio::task::spawn` (`server/core/src/https/mod.rs:481`); the accept loop continues after a task panic.\n- No `panic = \"abort\"` in any workspace `[profile.*]`.\n- No `Mutex`/`RwLock` held across the call site; nothing is poisoned.\n- The panic occurs before any write actor is messaged; no DB or replication state is touched.\n\n**Residual risk:** a downstream packager that sets `panic = \"abort\"` (or links code that installs an abort handler) would see a full unauthenticated process crash. (No such packager is known)\n\n**Affected:** v1.1.0-rc.15 (introduced in e7f594a1c, #2112) through `master` @ edf50b9da.",
  "id": "GHSA-84jc-3hj2-hwc7",
  "modified": "2026-05-06T23:39:14Z",
  "published": "2026-05-06T23:39:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kanidm/kanidm/security/advisories/GHSA-84jc-3hj2-hwc7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kanidm/kanidm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "kanidmd_lib: Image upload validators run before authorization; PNG validator panics on malformed input"
}

GHSA-8883-9W57-VWV6

Vulnerability from github – Published: 2026-03-26 21:23 – Updated: 2026-04-10 19:41
VLAI
Summary
OpenClaw: Mattermost callback dispatch allowed non-allowlisted sender actions
Details

Summary

Mattermost interactive callback dispatch could run action handlers before normal sender authorization checks completed.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: < 2026.3.22
  • Fixed: >= 2026.3.22
  • Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87)
  • Latest published npm version checked: 2026.3.23-2

Fix Commit(s)

  • a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66

Release Status

The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.

Code-Level Confirmation

  • extensions/mattermost/src/mattermost/interactions.ts now requires callback authorization before dispatching actions.
  • extensions/mattermost/src/mattermost/monitor.ts routes callback authorization through the same sender and allowlist policy used for normal ingress.

OpenClaw thanks @zpbrent for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-696",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T21:23:04Z",
    "nvd_published_at": "2026-04-10T17:17:05Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nMattermost interactive callback dispatch could run action handlers before normal sender authorization checks completed.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: \u003c 2026.3.22\n- Fixed: \u003e= 2026.3.22\n- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)\n- Latest published npm version checked: `2026.3.23-2`\n\n## Fix Commit(s)\n- `a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66`\n\n## Release Status\nThe fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.\n\n## Code-Level Confirmation\n- extensions/mattermost/src/mattermost/interactions.ts now requires callback authorization before dispatching actions.\n- extensions/mattermost/src/mattermost/monitor.ts routes callback authorization through the same sender and allowlist policy used for normal ingress.\n\nOpenClaw thanks @zpbrent for reporting.",
  "id": "GHSA-8883-9w57-vwv6",
  "modified": "2026-04-10T19:41:54Z",
  "published": "2026-03-26T21:23:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8883-9w57-vwv6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35652"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-unauthorized-action-execution-via-callback-dispatch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Mattermost callback dispatch allowed non-allowlisted sender actions"
}

GHSA-8F9R-GR6R-X63Q

Vulnerability from github – Published: 2026-04-10 00:30 – Updated: 2026-04-10 20:21
VLAI
Summary
Duplicate Advisory: OpenClaw: Feishu webhook reads and parses unauthenticated request bodies before signature validation
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-3h52-cx59-c456. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.25 parses JSON request bodies before validating webhook signatures, allowing unauthenticated attackers to force resource-intensive parsing operations. Remote attackers can send malicious webhook requests to trigger denial of service by exhausting server resources through forced JSON parsing before signature rejection.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T20:21:21Z",
    "nvd_published_at": "2026-04-09T22:16:33Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-3h52-cx59-c456. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.25 parses JSON request bodies before validating webhook signatures, allowing unauthenticated attackers to force resource-intensive parsing operations. Remote attackers can send malicious webhook requests to trigger denial of service by exhausting server resources through forced JSON parsing before signature rejection.",
  "id": "GHSA-8f9r-gr6r-x63q",
  "modified": "2026-04-10T20:21:21Z",
  "published": "2026-04-10T00:30:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3h52-cx59-c456"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35640"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/5e8cb22176e9235e224be0bc530699261eb60e53"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-denial-of-service-via-unauthenticated-webhook-request-parsing"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Feishu webhook reads and parses unauthenticated request bodies before signature validation",
  "withdrawn": "2026-04-10T20:21:21Z"
}

GHSA-96R2-52XR-8X9X

Vulnerability from github – Published: 2024-04-12 15:37 – Updated: 2025-02-06 18:31
VLAI
Details

An Incorrect Behavior Order in the routing engine (RE) of Juniper Networks Junos OS on EX4300 Series allows traffic intended to the device to reach the RE instead of being discarded when the discard term is set in loopback (lo0) interface. The intended function is that the lo0 firewall filter takes precedence over the revenue interface firewall filter. 

This issue affects only IPv6 firewall filter.

This issue only affects the EX4300 switch. No other products or platforms are affected by this vulnerability. 

This issue affects Juniper Networks Junos OS:

  • All versions before 20.4R3-S10,
  • from 21.2 before 21.2R3-S7,
  • from 21.4 before 21.4R3-S6. 
Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-30410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-12T15:15:25Z",
    "severity": "MODERATE"
  },
  "details": "An Incorrect Behavior Order in the routing engine (RE) of Juniper Networks Junos OS on EX4300 Series allows traffic intended to the device to reach the RE\u00a0instead of being discarded when the\u00a0discard term is set in loopback (lo0) interface. The intended function is that the lo0 firewall filter takes precedence over the revenue interface firewall filter.\u00a0\n\nThis issue affects only IPv6 firewall filter.\n\nThis issue only affects the EX4300 switch.  No other products or platforms are affected by this vulnerability.\u00a0\n\nThis issue affects Juniper Networks Junos OS:\n\n  *  All versions before 20.4R3-S10,\n  *  from 21.2 before 21.2R3-S7,\n  *  from 21.4 before 21.4R3-S6.\u00a0",
  "id": "GHSA-96r2-52xr-8x9x",
  "modified": "2025-02-06T18:31:01Z",
  "published": "2024-04-12T15:37:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30410"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA79100"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/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-9CCR-R5HG-74GF

Vulnerability from github – Published: 2026-05-11 16:16 – Updated: 2026-06-09 10:56
VLAI
Summary
GitHub Copilot CLI: Nested Bare Repository Can Execute Arbitrary Commands via core.fsmonitor
Details

Summary

A security vulnerability has been identified in GitHub Copilot CLI where a malicious bare git repository nested inside a project directory can achieve arbitrary code execution when the agent performs git operations. By exploiting git's automatic bare repository discovery during directory traversal, an attacker can set core.fsmonitor or other executable config keys to run arbitrary commands without user awareness or approval.

Details

Git supports bare repositories — repositories without a working tree — which can be discovered automatically when git traverses the directory hierarchy looking for a .git directory. When git discovers a bare repository, it reads and applies its configuration, including keys that specify external commands to execute.

The vulnerability arises because git's core.fsmonitor config key (and 15+ similar keys such as core.hookspath, diff.external, merge.tool, etc.) can specify arbitrary shell commands that git will execute as part of normal operations like status, diff, or rev-parse.

Attack Scenario

An attacker can exploit this by:

  1. Creating a bare git repository nested inside a seemingly normal project directory (e.g., vendor/malicious.git/ or a deeply nested subdirectory)
  2. Configuring core.fsmonitor (or similar keys) in that bare repository to execute a malicious command
  3. When GitHub Copilot CLI performs any git operation that traverses into or through that directory, git auto-discovers the bare repository, reads its config, and executes the attacker's command

This can occur when: - The agent navigates into a subdirectory containing the buried bare repo - The agent runs git status, git diff, or other routine git commands - The agent uses tools like grep or glob that may trigger git operations in subdirectories

Prior to the fix, the CLI had no protection against git auto-discovering bare repositories during directory traversal.

Impact

An attacker who can place a malicious bare repository inside a project — for example, through: - A pull request adding a directory that contains a bare repository - A compromised or malicious dependency that includes a bare repository - A cloned repository that already contains nested bare repositories

— could achieve arbitrary code execution on the user's workstation whenever GitHub Copilot CLI performs git operations in or near the malicious directory.

Successful exploitation could lead to data exfiltration, credential theft, file modification, or further system compromise.

Affected Versions

  • GitHub Copilot CLI versions prior to 1.0.42

Remediation and Mitigation

Fix

The fix sets safe.bareRepository=explicit via git's GIT_CONFIG_COUNT / GIT_CONFIG_KEY_* / GIT_CONFIG_VALUE_* environment variable mechanism, which has the highest precedence over all config file sources. This prevents git from automatically discovering and using bare repositories during directory traversal — only explicitly allowlisted bare repositories will be used.

User Actions

  1. Upgrade GitHub Copilot CLI to 1.0.43 or later.
  2. Exercise caution when working in repositories that contain nested bare git repositories.
  3. Review project directories for unexpected bare repositories, especially in vendor/, third_party/, or deeply nested subdirectories.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.42"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@github/copilot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.43"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T16:16:06Z",
    "nvd_published_at": "2026-05-13T16:17:00Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA security vulnerability has been identified in GitHub Copilot CLI where a malicious bare git repository nested inside a project directory can achieve arbitrary code execution when the agent performs git operations. By exploiting git\u0027s automatic bare repository discovery during directory traversal, an attacker can set `core.fsmonitor` or other executable config keys to run arbitrary commands without user awareness or approval.\n\n## Details\n\nGit supports bare repositories \u2014 repositories without a working tree \u2014 which can be discovered automatically when git traverses the directory hierarchy looking for a `.git` directory. When git discovers a bare repository, it reads and applies its configuration, including keys that specify external commands to execute.\n\nThe vulnerability arises because git\u0027s `core.fsmonitor` config key (and 15+ similar keys such as `core.hookspath`, `diff.external`, `merge.tool`, etc.) can specify arbitrary shell commands that git will execute as part of normal operations like `status`, `diff`, or `rev-parse`.\n\n### Attack Scenario\n\nAn attacker can exploit this by:\n\n1. Creating a bare git repository nested inside a seemingly normal project directory (e.g., `vendor/malicious.git/` or a deeply nested subdirectory)\n2. Configuring `core.fsmonitor` (or similar keys) in that bare repository to execute a malicious command\n3. When GitHub Copilot CLI performs any git operation that traverses into or through that directory, git auto-discovers the bare repository, reads its config, and executes the attacker\u0027s command\n\nThis can occur when:\n- The agent navigates into a subdirectory containing the buried bare repo\n- The agent runs `git status`, `git diff`, or other routine git commands\n- The agent uses tools like `grep` or `glob` that may trigger git operations in subdirectories\n\nPrior to the fix, the CLI had no protection against git auto-discovering bare repositories during directory traversal.\n\n## Impact\n\nAn attacker who can place a malicious bare repository inside a project \u2014 for example, through:\n- A pull request adding a directory that contains a bare repository\n- A compromised or malicious dependency that includes a bare repository\n- A cloned repository that already contains nested bare repositories\n\n\u2014 could achieve arbitrary code execution on the user\u0027s workstation whenever GitHub Copilot CLI performs git operations in or near the malicious directory.\n\nSuccessful exploitation could lead to data exfiltration, credential theft, file modification, or further system compromise.\n\n## Affected Versions\n\n- GitHub Copilot CLI versions prior to 1.0.42\n\n## Remediation and Mitigation\n\n### Fix\n\nThe fix sets `safe.bareRepository=explicit` via git\u0027s `GIT_CONFIG_COUNT` / `GIT_CONFIG_KEY_*` / `GIT_CONFIG_VALUE_*` environment variable mechanism, which has the highest precedence over all config file sources. This prevents git from automatically discovering and using bare repositories during directory traversal \u2014 only explicitly allowlisted bare repositories will be used.\n\n### User Actions\n\n1. **Upgrade** GitHub Copilot CLI to **1.0.43** or later.\n2. **Exercise caution** when working in repositories that contain nested bare git repositories.\n3. **Review** project directories for unexpected bare repositories, especially in `vendor/`, `third_party/`, or deeply nested subdirectories.",
  "id": "GHSA-9ccr-r5hg-74gf",
  "modified": "2026-06-09T10:56:45Z",
  "published": "2026-05-11T16:16:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/github/copilot-cli/security/advisories/GHSA-9ccr-r5hg-74gf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45033"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/github/copilot-cli"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GitHub Copilot CLI: Nested Bare Repository Can Execute Arbitrary Commands via core.fsmonitor"
}

GHSA-9W5M-FV42-36CX

Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2025-09-16 15:32
VLAI
Details

The improper order of AUTHORIZED_CTM_IP validation in the Control-M/Agent, where the Control-M/Server IP address is validated only after the SSL/TLS handshake is completed, exposes the Control-M/Agent to vulnerabilities in the SSL/TLS implementation under certain non-default conditions (e.g. CVE-2025-55117 or CVE-2025-55118) or potentially to resource exhaustion.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-55114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T13:16:07Z",
    "severity": "MODERATE"
  },
  "details": "The improper order of AUTHORIZED_CTM_IP validation in the Control-M/Agent, where the Control-M/Server IP address is validated only after the SSL/TLS handshake is completed, exposes the Control-M/Agent to vulnerabilities in the SSL/TLS implementation under certain non-default conditions (e.g. CVE-2025-55117 or CVE-2025-55118) or potentially to resource exhaustion.",
  "id": "GHSA-9w5m-fv42-36cx",
  "modified": "2025-09-16T15:32:36Z",
  "published": "2025-09-16T15:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55114"
    },
    {
      "type": "WEB",
      "url": "https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000441968"
    },
    {
      "type": "WEB",
      "url": "https://bmcapps.my.site.com/casemgmt/sc_KnowledgeArticle?sfdcid=000442099"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/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-C6FQ-3MHW-8G4J

Vulnerability from github – Published: 2026-07-29 12:31 – Updated: 2026-07-29 12:31
VLAI
Details

Apache Traffic Server updates the HTTP/2 HPACK dynamic table before confirming the header block encoded successfully, so an encode failure leaves the encoder out of sync with the peer decoder and corrupts subsequent header blocks on the connection.

This issue affects Apache Traffic Server: from 8.0.0 through 8.1.9, from 9.0.0 through 9.2.14, from 10.0.0 through 10.1.3.

Users are recommended to upgrade to version 9.2.15 or 10.1.4, which fix the issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-65100"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-29T10:16:44Z",
    "severity": "MODERATE"
  },
  "details": "Apache Traffic Server updates the HTTP/2 HPACK dynamic table before confirming the header block encoded successfully, so an encode failure leaves the encoder out of sync with the peer decoder and corrupts subsequent header blocks on the connection.\n\nThis issue affects Apache Traffic Server: from 8.0.0 through 8.1.9, from 9.0.0 through 9.2.14, from 10.0.0 through 10.1.3.\n\nUsers are recommended to upgrade to version 9.2.15 or 10.1.4, which fix the issue.",
  "id": "GHSA-c6fq-3mhw-8g4j",
  "modified": "2026-07-29T12:31:23Z",
  "published": "2026-07-29T12:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65100"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/5prl9glcm9g2swnq9hqxvnokylm1gr6d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/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-CVP8-HM87-HR8X

Vulnerability from github – Published: 2024-09-05 21:31 – Updated: 2024-09-12 18:31
VLAI
Details

An issue was discovered in Mbed TLS before 2.28.9 and 3.x before 3.6.1, in which the user-selected algorithm is not used. Unlike previously documented, enabling MBEDTLS_PSA_HMAC_DRBG_MD_TYPE does not cause the PSA subsystem to use HMAC_DRBG: it uses HMAC_DRBG only when MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG and MBEDTLS_CTR_DRBG_C are disabled.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-45157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-696"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-05T19:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Mbed TLS before 2.28.9 and 3.x before 3.6.1, in which the user-selected algorithm is not used. Unlike previously documented, enabling MBEDTLS_PSA_HMAC_DRBG_MD_TYPE does not cause the PSA subsystem to use HMAC_DRBG: it uses HMAC_DRBG only when MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG and MBEDTLS_CTR_DRBG_C are disabled.",
  "id": "GHSA-cvp8-hm87-hr8x",
  "modified": "2024-09-12T18:31:41Z",
  "published": "2024-09-05T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45157"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Mbed-TLS/mbedtls/releases"
    },
    {
      "type": "WEB",
      "url": "https://mbed-tls.readthedocs.io/en/latest/security-advisories"
    },
    {
      "type": "WEB",
      "url": "https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-08-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.