Common Weakness Enumeration
CWE-129
AllowedImproper Validation of Array Index
Abstraction: Variant · Status: Draft
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.
842 vulnerabilities reference this CWE, most recent first.
GHSA-HWQM-QVJ9-4JR2
Vulnerability from github – Published: 2026-03-18 20:19 – Updated: 2026-03-18 20:19
VLAI
Summary
gosaml2 CBC Padding Panic — Unauthenticated Process Crash
Details
Summary
The AES-CBC decryption path in DecryptBytes() panics on crafted ciphertext whose plaintext is all zero bytes. After decryption, bytes.TrimRight(data, "\x00") empties the slice, then data[len(data)-1] panics with index out of range [-1]. There is no recover() in the library. The panic propagates through ValidateEncodedResponse and kills the goroutine (or the entire process in non-net/http servers). An attacker needs only the SP's public RSA key (published in SAML metadata) to construct the payload — no valid signature is required.
Affected Version
All versions of github.com/russellhaering/gosaml2 through latest (v0.9.0 and HEAD) that support AES-CBC encrypted assertions.
Vulnerable Code
types/encrypted_assertion.go:65-79 — DecryptBytes, AES-CBC branch:
case MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:
if len(data)%k.BlockSize() != 0 {
return nil, fmt.Errorf("encrypted data is not a multiple of the expected CBC block size %d: actual size %d", k.BlockSize(), len(data))
}
nonce, data := data[:k.BlockSize()], data[k.BlockSize():]
c := cipher.NewCBCDecrypter(k, nonce)
c.CryptBlocks(data, data)
// Remove zero bytes
data = bytes.TrimRight(data, "\x00") // <-- empties the slice if plaintext is all zeros
// Calculate index to remove based on padding
padLength := data[len(data)-1] // <-- PANIC: index out of range [-1]
lastGoodIndex := len(data) - int(padLength)
return data[:lastGoodIndex], nil
Attack Details
| Property | Value |
|---|---|
| Attack Vector | Network (unauthenticated HTTP POST to ACS endpoint) |
| Authentication Required | None |
| Attacker Knowledge | SP's public RSA certificate (published in SAML metadata) |
| Signature Required | No — decryption happens before assertion signature validation |
| Payload Size | Single HTTP POST (~2 KB) |
| Repeatability | Unlimited — attacker can send the payload repeatedly |
| Affected Configurations | Any SP with SPKeyStore configured (encrypted assertion support) |
| Trigger Condition | AES-CBC plaintext that is all 0x00 bytes after decryption |
Impact
- Process crash: In gRPC servers, custom frameworks, CLI tools, and background workers, the unrecovered panic kills the entire OS process immediately.
- Goroutine crash: In
net/httpservers, the built-in per-goroutine recovery catches the panic, returning HTTP 500 and logging the full stack trace. The server survives but the request-handling goroutine is terminated abnormally. - Denial of service: The attack is unauthenticated and repeatable. A single crafted HTTP request is sufficient. Automated retries can keep the service down indefinitely.
- No valid signature needed: The SAML Response does not need to be signed. On the unsigned-response code path (
decode_response.go:346),decryptAssertions()is called before any assertion signature validation.
Reproduction
Prerequisites
- Docker (for the vulnerable server)
- Python 3.8+ with
cryptographyandrequestspackages
Files
| File | Description |
|---|---|
server.go |
Minimal SAML SP using gosaml2 — the victim |
poc.py |
Attacker script — builds and sends the crafted payload |
Dockerfile |
Multi-stage build for the vulnerable server |
run.sh |
Build and orchestration script |
Steps
# 1. Build the vulnerable server
./run.sh build
# 2. Start the server
./run.sh start
# 3. Run the attacker script
pip install cryptography requests
./run.sh attack
# Or do everything in one command:
./run.sh all
Expected Output
Attacker terminal (poc.py):
========================================================
CVE: CBC Padding Panic — Unauthenticated Process Crash
Target: gosaml2 (github.com/russellhaering/gosaml2)
File: types/encrypted_assertion.go:77
Impact: Remote DoS — single HTTP request kills process
========================================================
[*] Target: http://localhost:9999
[*] Checking server health...
[+] Server is alive
========================================================
Phase 1: Obtain SP public certificate from metadata
========================================================
[*] GET http://localhost:9999/metadata
[+] Retrieved SP certificate (xxx bytes)
========================================================
Phase 2: Build crafted EncryptedAssertion payload
========================================================
[+] Extracted RSA public key (size=2048 bits)
[*] Generated AES-128 key: <hex>
[+] RSA-OAEP encrypted AES key (256 bytes)
[+] AES-128-CBC ciphertext: IV(<hex>) + 16 bytes
[*] Plaintext is all zeros — will trigger empty-slice panic after TrimRight
[+] Built SAML Response (xxx bytes XML, xxx bytes b64)
========================================================
Phase 3: Send payload to /acs
========================================================
[*] POST http://localhost:9999/acs
[*] The server will decrypt our ciphertext, hit the all-zero
plaintext edge case, and panic in DecryptBytes()...
[*] Got HTTP 500 — goroutine panicked but net/http recovered it
========================================================
Phase 4: Verify server status
========================================================
[*] Server is still responding (net/http recovered the goroutine panic)
[*] But the panic stack trace in server logs confirms the vulnerability.
[*] In non-HTTP servers, the process would be dead.
========================================================
VULNERABILITY CONFIRMED
types/encrypted_assertion.go:77 — index out of range [-1]
Stack trace:
types/encrypted_assertion.go:77 (padLength := data[len(data)-1])
decode_response.go:176 (decryptAssertions)
decode_response.go:346 (ValidateEncodedResponse)
========================================================
Server logs (panic stack trace):
http: panic serving 127.0.0.1:xxxxx: runtime error: index out of range [-1]
goroutine XX [running]:
net/http.(*conn).serve.func1()
/usr/local/go/src/net/http/server.go:1898 +0xbe
github.com/russellhaering/gosaml2/types.(*EncryptedAssertion).DecryptBytes(...)
types/encrypted_assertion.go:77 +0x...
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions.func1(...)
decode_response.go:176 +0x...
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions(...)
decode_response.go:196 +0x...
github.com/russellhaering/gosaml2.(*SAMLServiceProvider).ValidateEncodedResponse(...)
decode_response.go:346 +0x...
Suggested Fix
Replace the unsafe zero-byte trimming and unchecked index with proper PKCS#7 unpadding and bounds checks:
case MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:
if len(data)%k.BlockSize() != 0 {
return nil, fmt.Errorf("ciphertext not multiple of block size")
}
nonce, data := data[:k.BlockSize()], data[k.BlockSize():]
c := cipher.NewCBCDecrypter(k, nonce)
c.CryptBlocks(data, data)
// Validate decrypted data is non-empty
if len(data) == 0 {
return nil, fmt.Errorf("decrypted data is empty")
}
// Proper PKCS#7 unpadding with bounds checks
padLength := int(data[len(data)-1])
if padLength < 1 || padLength > k.BlockSize() || padLength > len(data) {
return nil, fmt.Errorf("invalid padding length: %d", padLength)
}
// Verify all padding bytes are consistent
for i := len(data) - padLength; i < len(data); i++ {
if data[i] != byte(padLength) {
return nil, fmt.Errorf("invalid PKCS#7 padding")
}
}
return data[:len(data)-padLength], nil
Key changes:
1. Remove bytes.TrimRight(data, "\x00") entirely — it corrupts valid PKCS#7-padded data and creates the empty-slice condition.
2. Bounds-check padLength before using it as a slice index.
3. Validate all padding bytes match (proper PKCS#7 verification).
4. Return errors instead of panicking on malformed input.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.10.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/russellhaering/gosaml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T20:19:11Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe AES-CBC decryption path in `DecryptBytes()` panics on crafted ciphertext whose plaintext is all zero bytes. After decryption, `bytes.TrimRight(data, \"\\x00\")` empties the slice, then `data[len(data)-1]` panics with `index out of range [-1]`. There is no `recover()` in the library. The panic propagates through `ValidateEncodedResponse` and kills the goroutine (or the entire process in non-`net/http` servers). An attacker needs only the SP\u0027s public RSA key (published in SAML metadata) to construct the payload \u2014 no valid signature is required.\n\n## Affected Version\n\nAll versions of `github.com/russellhaering/gosaml2` through latest (`v0.9.0` and HEAD) that support AES-CBC encrypted assertions.\n\n## Vulnerable Code\n\n**`types/encrypted_assertion.go:65-79`** \u2014 `DecryptBytes`, AES-CBC branch:\n\n```go\ncase MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:\n if len(data)%k.BlockSize() != 0 {\n return nil, fmt.Errorf(\"encrypted data is not a multiple of the expected CBC block size %d: actual size %d\", k.BlockSize(), len(data))\n }\n nonce, data := data[:k.BlockSize()], data[k.BlockSize():]\n c := cipher.NewCBCDecrypter(k, nonce)\n c.CryptBlocks(data, data)\n\n // Remove zero bytes\n data = bytes.TrimRight(data, \"\\x00\") // \u003c-- empties the slice if plaintext is all zeros\n\n // Calculate index to remove based on padding\n padLength := data[len(data)-1] // \u003c-- PANIC: index out of range [-1]\n lastGoodIndex := len(data) - int(padLength)\n return data[:lastGoodIndex], nil\n```\n\n## Attack Details\n\n| Property | Value |\n|---|---|\n| **Attack Vector** | Network (unauthenticated HTTP POST to ACS endpoint) |\n| **Authentication Required** | None |\n| **Attacker Knowledge** | SP\u0027s public RSA certificate (published in SAML metadata) |\n| **Signature Required** | No \u2014 decryption happens before assertion signature validation |\n| **Payload Size** | Single HTTP POST (~2 KB) |\n| **Repeatability** | Unlimited \u2014 attacker can send the payload repeatedly |\n| **Affected Configurations** | Any SP with `SPKeyStore` configured (encrypted assertion support) |\n| **Trigger Condition** | AES-CBC plaintext that is all `0x00` bytes after decryption |\n\n## Impact\n\n- **Process crash**: In gRPC servers, custom frameworks, CLI tools, and background workers, the unrecovered panic kills the entire OS process immediately.\n- **Goroutine crash**: In `net/http` servers, the built-in per-goroutine recovery catches the panic, returning HTTP 500 and logging the full stack trace. The server survives but the request-handling goroutine is terminated abnormally.\n- **Denial of service**: The attack is unauthenticated and repeatable. A single crafted HTTP request is sufficient. Automated retries can keep the service down indefinitely.\n- **No valid signature needed**: The SAML Response does not need to be signed. On the unsigned-response code path (`decode_response.go:346`), `decryptAssertions()` is called **before** any assertion signature validation.\n\n## Reproduction\n\n### Prerequisites\n\n- Docker (for the vulnerable server)\n- Python 3.8+ with `cryptography` and `requests` packages\n\n### Files\n\n| File | Description |\n|---|---|\n| `server.go` | Minimal SAML SP using gosaml2 \u2014 the victim |\n| `poc.py` | Attacker script \u2014 builds and sends the crafted payload |\n| `Dockerfile` | Multi-stage build for the vulnerable server |\n| `run.sh` | Build and orchestration script |\n\n### Steps\n\n```bash\n# 1. Build the vulnerable server\n./run.sh build\n\n# 2. Start the server\n./run.sh start\n\n# 3. Run the attacker script\npip install cryptography requests\n./run.sh attack\n\n# Or do everything in one command:\n./run.sh all\n```\n\n### Expected Output\n\n**Attacker terminal (`poc.py`):**\n\n```\n ========================================================\n CVE: CBC Padding Panic \u2014 Unauthenticated Process Crash\n Target: gosaml2 (github.com/russellhaering/gosaml2)\n File: types/encrypted_assertion.go:77\n Impact: Remote DoS \u2014 single HTTP request kills process\n ========================================================\n\n[*] Target: http://localhost:9999\n[*] Checking server health...\n[+] Server is alive\n\n========================================================\n Phase 1: Obtain SP public certificate from metadata\n========================================================\n[*] GET http://localhost:9999/metadata\n[+] Retrieved SP certificate (xxx bytes)\n\n========================================================\n Phase 2: Build crafted EncryptedAssertion payload\n========================================================\n[+] Extracted RSA public key (size=2048 bits)\n[*] Generated AES-128 key: \u003chex\u003e\n[+] RSA-OAEP encrypted AES key (256 bytes)\n[+] AES-128-CBC ciphertext: IV(\u003chex\u003e) + 16 bytes\n[*] Plaintext is all zeros \u2014 will trigger empty-slice panic after TrimRight\n[+] Built SAML Response (xxx bytes XML, xxx bytes b64)\n\n========================================================\n Phase 3: Send payload to /acs\n========================================================\n[*] POST http://localhost:9999/acs\n[*] The server will decrypt our ciphertext, hit the all-zero\n plaintext edge case, and panic in DecryptBytes()...\n\n[*] Got HTTP 500 \u2014 goroutine panicked but net/http recovered it\n\n========================================================\n Phase 4: Verify server status\n========================================================\n[*] Server is still responding (net/http recovered the goroutine panic)\n[*] But the panic stack trace in server logs confirms the vulnerability.\n[*] In non-HTTP servers, the process would be dead.\n\n========================================================\n VULNERABILITY CONFIRMED\n types/encrypted_assertion.go:77 \u2014 index out of range [-1]\n\n Stack trace:\n types/encrypted_assertion.go:77 (padLength := data[len(data)-1])\n decode_response.go:176 (decryptAssertions)\n decode_response.go:346 (ValidateEncodedResponse)\n========================================================\n```\n\n**Server logs (panic stack trace):**\n\n```\nhttp: panic serving 127.0.0.1:xxxxx: runtime error: index out of range [-1]\ngoroutine XX [running]:\nnet/http.(*conn).serve.func1()\n /usr/local/go/src/net/http/server.go:1898 +0xbe\ngithub.com/russellhaering/gosaml2/types.(*EncryptedAssertion).DecryptBytes(...)\n types/encrypted_assertion.go:77 +0x...\ngithub.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions.func1(...)\n decode_response.go:176 +0x...\ngithub.com/russellhaering/gosaml2.(*SAMLServiceProvider).decryptAssertions(...)\n decode_response.go:196 +0x...\ngithub.com/russellhaering/gosaml2.(*SAMLServiceProvider).ValidateEncodedResponse(...)\n decode_response.go:346 +0x...\n```\n\n## Suggested Fix\n\nReplace the unsafe zero-byte trimming and unchecked index with proper PKCS#7 unpadding and bounds checks:\n\n```go\ncase MethodAES128CBC, MethodAES256CBC, MethodTripleDESCBC:\n if len(data)%k.BlockSize() != 0 {\n return nil, fmt.Errorf(\"ciphertext not multiple of block size\")\n }\n nonce, data := data[:k.BlockSize()], data[k.BlockSize():]\n c := cipher.NewCBCDecrypter(k, nonce)\n c.CryptBlocks(data, data)\n\n // Validate decrypted data is non-empty\n if len(data) == 0 {\n return nil, fmt.Errorf(\"decrypted data is empty\")\n }\n\n // Proper PKCS#7 unpadding with bounds checks\n padLength := int(data[len(data)-1])\n if padLength \u003c 1 || padLength \u003e k.BlockSize() || padLength \u003e len(data) {\n return nil, fmt.Errorf(\"invalid padding length: %d\", padLength)\n }\n\n // Verify all padding bytes are consistent\n for i := len(data) - padLength; i \u003c len(data); i++ {\n if data[i] != byte(padLength) {\n return nil, fmt.Errorf(\"invalid PKCS#7 padding\")\n }\n }\n\n return data[:len(data)-padLength], nil\n```\n\nKey changes:\n1. **Remove `bytes.TrimRight(data, \"\\x00\")`** entirely \u2014 it corrupts valid PKCS#7-padded data and creates the empty-slice condition.\n2. **Bounds-check `padLength`** before using it as a slice index.\n3. **Validate all padding bytes** match (proper PKCS#7 verification).\n4. **Return errors** instead of panicking on malformed input.",
"id": "GHSA-hwqm-qvj9-4jr2",
"modified": "2026-03-18T20:19:11Z",
"published": "2026-03-18T20:19:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/russellhaering/gosaml2/security/advisories/GHSA-hwqm-qvj9-4jr2"
},
{
"type": "PACKAGE",
"url": "https://github.com/russellhaering/gosaml2"
}
],
"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:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gosaml2 CBC Padding Panic \u2014 Unauthenticated Process Crash"
}
GHSA-HX7R-XMR3-78GC
Vulnerability from github – Published: 2023-06-14 09:30 – Updated: 2024-04-04 04:49
VLAI
Details
A CWE-129: Improper Validation of Array Index vulnerability exists that could cause local denial-of-service, and potentially kernel execution when a malicious actor with local user access crafts a script/program using an unpredictable index to an IOCTL call in the Foxboro.sys driver.
Severity
7.0 (High)
{
"affected": [],
"aliases": [
"CVE-2023-2570"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-14T08:15:09Z",
"severity": "HIGH"
},
"details": "\n\n\nA CWE-129: Improper Validation of Array Index vulnerability exists that could cause local\ndenial-of-service, and potentially kernel execution when a malicious actor with local user access\ncrafts a script/program using an unpredictable index to an IOCTL call in the Foxboro.sys driver.\n\n\n\n",
"id": "GHSA-hx7r-xmr3-78gc",
"modified": "2024-04-04T04:49:36Z",
"published": "2023-06-14T09:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2570"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2023-164-04\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2023-164-04.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HXXW-VVRC-QRX3
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix index out of bounds in DCN30 color transformation
This commit addresses a potential index out of bounds issue in the
cm3_helper_translate_curve_to_hw_format function in the DCN30 color
management module. The issue could occur when the index 'i' exceeds the
number of transfer function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2024-49969"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:17Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix index out of bounds in DCN30 color transformation\n\nThis commit addresses a potential index out of bounds issue in the\n`cm3_helper_translate_curve_to_hw_format` function in the DCN30 color\nmanagement module. The issue could occur when the index \u0027i\u0027 exceeds the\nnumber of transfer function points (TRANSFER_FUNC_POINTS).\n\nThe fix adds a check to ensure \u0027i\u0027 is within bounds before accessing the\ntransfer function points. If \u0027i\u0027 is out of bounds, the function returns\nfalse to indicate an error.\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0027output_tf-\u003etf_pts.red\u0027 1025 \u003c= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0027output_tf-\u003etf_pts.green\u0027 1025 \u003c= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0027output_tf-\u003etf_pts.blue\u0027 1025 \u003c= s32max",
"id": "GHSA-hxxw-vvrc-qrx3",
"modified": "2025-11-04T00:31:43Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0f1e222a4b41d77c442901d166fbdca967af0d86"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/578422ddae3d13362b64e77ef9bab98780641631"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7ab69af56a23859b647dee69fa1052c689343621"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/929506d5671419cffd8d01e9a7f5eae53682a838"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9d8b94ec7e67f0cae228c054f77b73967c389a3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c13f9c62015c56a938304cef6d507227ea3e0039"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d81873f9e715b72d4f8d391c8eb243946f784dfc"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"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-J3G9-2F89-WH5P
Vulnerability from github – Published: 2023-03-10 21:30 – Updated: 2023-03-15 21:30
VLAI
Details
Memory corruption due to improper validation of array index in Multi-mode call processor.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2022-33256"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-10T21:15:00Z",
"severity": "CRITICAL"
},
"details": "Memory corruption due to improper validation of array index in Multi-mode call processor.",
"id": "GHSA-j3g9-2f89-wh5p",
"modified": "2023-03-15T21:30:26Z",
"published": "2023-03-10T21:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33256"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/march-2023-bulletin"
}
],
"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-J45W-P973-WJXH
Vulnerability from github – Published: 2022-05-14 01:57 – Updated: 2022-05-14 01:57
VLAI
Details
In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9635M, MDM9640, MDM9645, MDM9650, MDM9655, MSM8909W, MSM8996AU, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, SDX20, Snapdragon_High_Med_2016, a potential buffer overflow exists when parsing TFTP options.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2018-11269"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-20T13:29:00Z",
"severity": "HIGH"
},
"details": "In Snapdragon (Automobile, Mobile, Wear) in version MDM9206, MDM9607, MDM9635M, MDM9640, MDM9645, MDM9650, MDM9655, MSM8909W, MSM8996AU, SD 210/SD 212/SD 205, SD 425, SD 427, SD 430, SD 435, SD 450, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, SDA660, SDM429, SDM439, SDM630, SDM632, SDM636, SDM660, SDM710, SDX20, Snapdragon_High_Med_2016, a potential buffer overflow exists when parsing TFTP options.",
"id": "GHSA-j45w-p973-wjxh",
"modified": "2022-05-14T01:57:02Z",
"published": "2022-05-14T01:57:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11269"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105838"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J4QF-CXM7-87P2
Vulnerability from github – Published: 2022-03-17 00:00 – Updated: 2022-03-23 00:00
VLAI
Details
In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2022-27223"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-16T00:15:00Z",
"severity": "HIGH"
},
"details": "In drivers/usb/gadget/udc/udc-xilinx.c in the Linux kernel before 5.16.12, the endpoint index is not validated and might be manipulated by the host for out-of-array access.",
"id": "GHSA-j4qf-cxm7-87p2",
"modified": "2022-03-23T00:00:35Z",
"published": "2022-03-17T00:00:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27223"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/7f14c7227f342d9932f9b918893c8814f86d2a0d"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.12"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220419-0001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J4RG-H6CW-QR4Q
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32
VLAI
Details
u'Array index underflow issue in adsp driver due to improper check of channel id before used as array index.' in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in Agatti, APQ8009, APQ8017, APQ8053, APQ8096AU, APQ8098, Bitra, IPQ4019, IPQ5018, IPQ6018, IPQ8064, IPQ8074, Kamorta, MDM9607, MDM9640, MDM9650, MSM8905, MSM8909W, MSM8953, MSM8996AU, QCA6390, QCA9531, QCM2150, QCS404, QCS405, QCS605, SA415M, SA515M, SA6155P, SA8155P, Saipan, SC8180X, SDA660, SDA845, SDM429, SDM429W, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SDX20, SDX24, SDX55, SM6150, SM8150, SM8250, SXR1130, SXR2130
{
"affected": [],
"aliases": [
"CVE-2020-11174"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-02T07:15:00Z",
"severity": "HIGH"
},
"details": "u\u0027Array index underflow issue in adsp driver due to improper check of channel id before used as array index.\u0027 in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in Agatti, APQ8009, APQ8017, APQ8053, APQ8096AU, APQ8098, Bitra, IPQ4019, IPQ5018, IPQ6018, IPQ8064, IPQ8074, Kamorta, MDM9607, MDM9640, MDM9650, MSM8905, MSM8909W, MSM8953, MSM8996AU, QCA6390, QCA9531, QCM2150, QCS404, QCS405, QCS605, SA415M, SA515M, SA6155P, SA8155P, Saipan, SC8180X, SDA660, SDA845, SDM429, SDM429W, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SDX20, SDX24, SDX55, SM6150, SM8150, SM8250, SXR1130, SXR2130",
"id": "GHSA-j4rg-h6cw-qr4q",
"modified": "2022-05-24T17:32:50Z",
"published": "2022-05-24T17:32:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11174"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2020-bulletin"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/october-2020-security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J8JH-C95W-8M7G
Vulnerability from github – Published: 2026-09-30 18:33 – Updated: 2026-09-30 18:33
VLAI
Details
NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a user could cause an out-of-bounds array access. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2026-47507"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-30T16:17:15Z",
"severity": "HIGH"
},
"details": "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where a user could cause an out-of-bounds array access. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.",
"id": "GHSA-j8jh-c95w-8m7g",
"modified": "2026-09-30T18:33:36Z",
"published": "2026-09-30T18:33:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47507"
},
{
"type": "WEB",
"url": "https://github.com/NVIDIA/product-security/tree/main/2026/5861"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47507"
}
],
"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-JFXW-F7PW-76RC
Vulnerability from github – Published: 2026-09-30 09:31 – Updated: 2026-09-30 12:35
VLAI
Details
Improper Verification of Source of a Communication Channel in the ADS discovery of the Go implementation of Apache PLC4X (PLC4Go) allows an attacker able to send UDP datagrams to the discovering host to redirect subsequent connections to an arbitrary, attacker-chosen address. The discovery result's connection address was derived from the AmsNetId claimed in the response body rather than from the datagram's actual source address. One spoofed discovery response can therefore insert an inventory entry pointing at any host, including hosts outside the local network, and an application that connects to discovered devices will open its ADS session, including any configured route credentials, to that host.
Additionally, discovery listeners in both implementations can be disabled by a single malformed datagram: - In PLC4Go ADS discovery, a short version block causes a panic that ends the listener for the rest of the discovery call, so legitimate devices answering afterwards are not reported. - In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response. - The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response.
Exploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items.
This issue affects Apache PLC4X: PLC4Go from 0.11.0 before 1.0.0; PLC4J ADS and Modbus drivers from 0.10.0 before 1.0.0; PLC4J EtherNet/IP driver from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 derives the connection address from the datagram's source address and logs a warning when the claimed AmsNetId disagrees with it.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-102511"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-30T09:17:14Z",
"severity": "HIGH"
},
"details": "Improper Verification of Source of a Communication Channel in the ADS discovery of the Go implementation of Apache PLC4X (PLC4Go) allows an attacker able to send UDP datagrams to the discovering host to redirect subsequent connections to an arbitrary, attacker-chosen address. The discovery result\u0027s connection \naddress was derived from the AmsNetId claimed in the response body rather than from the datagram\u0027s actual source address. One spoofed discovery response can therefore insert an inventory entry pointing at any host, including hosts outside the local network, and an application that connects to discovered devices\nwill open its ADS session, including any configured route credentials, to that host.\n\nAdditionally, discovery listeners in both implementations can be disabled by a single malformed datagram:\n- In PLC4Go ADS discovery, a short version block causes a panic that ends the listener for the rest of the discovery call, so legitimate devices answering afterwards are not reported.\n- In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response.\n- The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response.\n\nExploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items.\n\nThis issue affects Apache PLC4X: PLC4Go from 0.11.0 before 1.0.0; PLC4J ADS and Modbus drivers from 0.10.0 before 1.0.0; PLC4J EtherNet/IP driver from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases.\n\nUsers are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 derives the connection address from the datagram\u0027s source address and logs a warning when the claimed AmsNetId disagrees with it.",
"id": "GHSA-jfxw-f7pw-76rc",
"modified": "2026-09-30T12:35:14Z",
"published": "2026-09-30T09:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102511"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/g692j4fklrbo80stjr5ll8xghrwszthf"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/30/7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/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-JG3V-6RVM-6P3V
Vulnerability from github – Published: 2024-11-04 12:32 – Updated: 2024-11-04 12:32
VLAI
Details
Memory corruption when the user application modifies the same shared memory asynchronously when kernel is accessing it.
Severity
6.7 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-33032"
],
"database_specific": {
"cwe_ids": [
"CWE-129"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-04T10:15:05Z",
"severity": "MODERATE"
},
"details": "Memory corruption when the user application modifies the same shared memory asynchronously when kernel is accessing it.",
"id": "GHSA-jg3v-6rvm-6p3v",
"modified": "2024-11-04T12:32:56Z",
"published": "2024-11-04T12:32:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33032"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/november-2024-bulletin.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"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.