Common Weakness Enumeration
CWE-787
Allowed-with-ReviewOut-of-bounds Write
Abstraction: Base · Status: Draft
The product writes data past the end, or before the beginning, of the intended buffer.
15631 vulnerabilities reference this CWE, most recent first.
GHSA-9HMH-GM6C-7VPR
Vulnerability from github – Published: 2023-02-27 21:30 – Updated: 2023-03-08 18:30
VLAI
Details
The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.2, iOS 16.3 and iPadOS 16.3. An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges.
Severity
9.9 (Critical)
{
"affected": [],
"aliases": [
"CVE-2023-23531"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-27T20:15:00Z",
"severity": "CRITICAL"
},
"details": "The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.2, iOS 16.3 and iPadOS 16.3. An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges.",
"id": "GHSA-9hmh-gm6c-7vpr",
"modified": "2023-03-08T18:30:26Z",
"published": "2023-02-27T21:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23531"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213605"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213606"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9HQ9-J4JV-PH2G
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-10-08 00:00
VLAI
Details
Adobe Character Animator version 4.2 (and earlier) is affected by a memory corruption vulnerability when parsing a specially crafted file. An unauthenticated attacker could leverage this vulnerability to achieve arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2021-36000"
],
"database_specific": {
"cwe_ids": [
"CWE-787",
"CWE-788"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-20T19:15:00Z",
"severity": "HIGH"
},
"details": "Adobe Character Animator version 4.2 (and earlier) is affected by a memory corruption vulnerability when parsing a specially crafted file. An unauthenticated attacker could leverage this vulnerability to achieve arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-9hq9-j4jv-ph2g",
"modified": "2022-10-08T00:00:19Z",
"published": "2022-05-24T19:11:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36000"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/in/security/products/character_animator/apsb21-59.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9HQH-9J5R-25HR
Vulnerability from github – Published: 2022-05-01 18:21 – Updated: 2022-05-01 18:21
VLAI
Details
Stack-based buffer overflow in the giomgr process in ESRI ArcSDE service 9.2, as used with ArcGIS, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a large number that requires more than 8 bytes to represent in ASCII, which triggers the overflow in an sprintf function call.
{
"affected": [],
"aliases": [
"CVE-2007-4278"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-08-15T22:17:00Z",
"severity": "HIGH"
},
"details": "Stack-based buffer overflow in the giomgr process in ESRI ArcSDE service 9.2, as used with ArcGIS, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a large number that requires more than 8 bytes to represent in ASCII, which triggers the overflow in an sprintf function call.",
"id": "GHSA-9hqh-9j5r-25hr",
"modified": "2022-05-01T18:21:56Z",
"published": "2022-05-01T18:21:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-4278"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/36042"
},
{
"type": "WEB",
"url": "http://downloads.esri.com/support/downloads/other_/ArcSDE-92sp3-issues.htm"
},
{
"type": "WEB",
"url": "http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=577"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/26452"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1018574"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/25334"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/2911"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9HQR-FQ7X-7P43
Vulnerability from github – Published: 2026-03-24 03:31 – Updated: 2026-03-24 03:31
VLAI
Details
Heap buffer overflow in WebAudio in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2026-4673"
],
"database_specific": {
"cwe_ids": [
"CWE-122",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-24T01:17:02Z",
"severity": "HIGH"
},
"details": "Heap buffer overflow in WebAudio in Google Chrome prior to 146.0.7680.165 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: High)",
"id": "GHSA-9hqr-fq7x-7p43",
"modified": "2026-03-24T03:31:19Z",
"published": "2026-03-24T03:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4673"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_23.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/485397284"
}
],
"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-9HR8-4F6W-73F6
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2023-05-03 12:30
VLAI
Details
A stack overflow vulnerability occurs in Atomicparsley 20210124.204813.840499f through APar_read64() in src/util.cpp due to the lack of buffer size of uint32_buffer while reading more bytes in APar_read64.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2021-37232"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-04T10:15:00Z",
"severity": "CRITICAL"
},
"details": "A stack overflow vulnerability occurs in Atomicparsley 20210124.204813.840499f through APar_read64() in src/util.cpp due to the lack of buffer size of uint32_buffer while reading more bytes in APar_read64.",
"id": "GHSA-9hr8-4f6w-73f6",
"modified": "2023-05-03T12:30:22Z",
"published": "2022-05-24T19:10:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37232"
},
{
"type": "WEB",
"url": "https://github.com/wez/atomicparsley/issues/32"
},
{
"type": "WEB",
"url": "https://github.com/wez/atomicparsley/commit/d72ccf06c98259d7261e0f3ac4fd8717778782c1"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-01"
}
],
"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-9HVQ-RW3F-PQ55
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-01 18:30
VLAI
Details
TOTOLINK X2000R Gh v1.0.0-B20230221.0948.web was discovered to contain a stack overflow via the function formMultiAP.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2023-46552"
],
"database_specific": {
"cwe_ids": [
"CWE-121",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-25T18:17:39Z",
"severity": "CRITICAL"
},
"details": "TOTOLINK X2000R Gh v1.0.0-B20230221.0948.web was discovered to contain a stack overflow via the function formMultiAP.",
"id": "GHSA-9hvq-rw3f-pq55",
"modified": "2023-11-01T18:30:32Z",
"published": "2023-10-25T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46552"
},
{
"type": "WEB",
"url": "https://github.com/XYIYM/Digging/blob/main/TOTOLINK/X2000R/19/1.md"
},
{
"type": "WEB",
"url": "https://totolink.cn/home/menu/detail.html?menu_listtpl=download\u0026id=85\u0026ids=36"
}
],
"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-9HW6-9FRH-HXRG
Vulnerability from github – Published: 2024-09-13 06:30 – Updated: 2025-11-04 00:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: cmd-db: Map shared memory as WC, not WB
Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.
The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.
Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.
I tested this on SA8155P with Xen.
Severity
5.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2024-46689"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-13T06:15:13Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\n\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \"write\" into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\n\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\n\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\n\nI tested this on SA8155P with Xen.",
"id": "GHSA-9hw6-9frh-hxrg",
"modified": "2025-11-04T00:31:24Z",
"published": "2024-09-13T06:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567999839d"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9HW9-CH79-4VH6
Vulnerability from github – Published: 2026-07-20 23:19 – Updated: 2026-07-20 23:19
VLAI
Summary
Pillow: Controlled heap out-of-bounds write in Pillow `ImageCmsTransform.apply()` via output mode mismatch
Details
Summary
Pillow's public ImageCms.ImageCmsTransform.apply(im, imOut) API can trigger
controlled native heap corruption when the caller supplies an output image whose
mode does not match the transform's declared output mode.
For example, a transform built as RGBA -> RGBA can be applied to an L output
image. Pillow checks dimensions only, then calls LittleCMS with the output row
pointer. LittleCMS writes RGBA-sized rows into a 1-byte-per-pixel L image row.
Details
src/PIL/ImageCms.py:ImageCmsTransform.apply() accepts an optional caller
supplied imOut:
def apply(self, im, imOut=None):
if imOut is None:
imOut = Image.new(self.output_mode, im.size, None)
self.transform.apply(im.getim(), imOut.getim())
imOut.info["icc_profile"] = self.output_profile.tobytes()
return imOut
If imOut is provided, Pillow does not check:
im.mode == self.input_mode
imOut.mode == self.output_mode
The C wrapper in src/_imagingcms.c unwraps both image cores and only checks
that the output dimensions are at least as large as the input dimensions:
static int
pyCMSdoTransform(Imaging im, Imaging imOut, cmsHTRANSFORM hTransform) {
if (im->xsize > imOut->xsize || im->ysize > imOut->ysize) {
return -1;
}
for (i = 0; i < im->ysize; i++) {
cmsDoTransform(hTransform, im->image[i], imOut->image[i], im->xsize);
}
pyCMScopyAux(hTransform, imOut, im);
return 0;
}
findLCMStype() maps RGB, RGBA, and RGBX transform modes to LittleCMS
TYPE_RGBA_8, which writes 4 bytes per pixel:
case IMAGING_MODE_RGB:
case IMAGING_MODE_RGBA:
case IMAGING_MODE_RGBX:
return TYPE_RGBA_8;
So with a transform declared as RGBA -> RGBA, LittleCMS writes 4 * width
bytes to each output row. If the supplied output image is mode L, Pillow only
allocated 1 * width bytes for that row.
For width 4096:
destination row allocation: 4096 bytes
LittleCMS write size: 16384 bytes
overflow: ~12288 bytes past the row
The bug does not require a large image. Width 8 was enough to corrupt heap
metadata. At width 8, apply() returned to Python and printed after; glibc
detected the corrupted heap later during cleanup.
PoC
Tiny heap corruption trigger:
from PIL import Image, ImageCms
srgb = ImageCms.createProfile("sRGB")
transform = ImageCms.buildTransform(srgb, srgb, "RGBA", "RGBA")
im = Image.new("RGBA", (8, 1), (0x41, 0x42, 0x43, 0x44))
out = Image.new("L", (8, 1), 0)
print("before", flush=True)
transform.apply(im, out)
print("after")
Observed locally on Pillow 12.3.0.dev0:
before
after
free(): invalid next size (normal)
Aborted (core dumped)
Controlled overwrite evidence PoC:
from PIL import Image, ImageCms
srgb = ImageCms.createProfile("sRGB")
transform = ImageCms.buildTransform(srgb, srgb, "RGBA", "RGBA")
im = Image.new("RGBA", (4096, 1), (0x41, 0x42, 0x43, 0x44))
out = Image.new("L", (4096, 1), 0)
transform.apply(im, out)
Run under gdb:
gdb -q --batch -ex run -ex bt --args \
python3 b022_controlled.py
Observed on Pillow 12.3.0.dev0:
Program received signal SIGSEGV, Segmentation fault.
___pthread_mutex_lock (mutex=mutex@entry=0x4443424144434241)
#1 _cmsLockPrimitive (m=0x4443424144434241)
#2 defMtxLock (id=0x4443424144434241, mtx=0x4443424144434241)
#3 _cmsLockMutex (ContextID=0x4443424144434241, mtx=0x4443424144434241)
#4 cmsSaveProfileToIOhandler(...)
#5 cmsSaveProfileToMem(...)
#6 cms_profile_tobytes (...) at src/_imagingcms.c:152
0x4443424144434241 is the attacker-controlled source pixel pattern
b"ABCDABCD" interpreted as a little-endian pointer-sized value.
Using source pixels (1, 2, 3, 4) similarly produced a faulting pointer of
0x403020104030201, matching the repeated pixel bytes.
Impact
This is a heap out-of-bounds write in Pillow's native ImageCms extension, reachable through public API.
Applications are impacted if untrusted users can control ImageCms transform
parameters and/or provide the output image object passed to
ImageCmsTransform.apply(). The source image pixels influence the bytes written
out of bounds.
Suggested fix
Validate modes before calling into the native transform:
def apply(self, im, imOut=None):
if im.mode != self.input_mode:
raise ValueError("input mode mismatch")
if imOut is None:
imOut = Image.new(self.output_mode, im.size, None)
elif imOut.mode != self.output_mode:
raise ValueError("output mode mismatch")
self.transform.apply(im.getim(), imOut.getim())
imOut.info["icc_profile"] = self.output_profile.tobytes()
return imOut
The C extension should also defensively reject mismatched image modes before
calling cmsDoTransform().
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pillow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59205"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T23:19:00Z",
"nvd_published_at": "2026-07-14T16:17:02Z",
"severity": "HIGH"
},
"details": "### Summary\n\nPillow\u0027s public `ImageCms.ImageCmsTransform.apply(im, imOut)` API can trigger\ncontrolled native heap corruption when the caller supplies an output image whose\nmode does not match the transform\u0027s declared output mode.\n\nFor example, a transform built as `RGBA -\u003e RGBA` can be applied to an `L` output\nimage. Pillow checks dimensions only, then calls LittleCMS with the output row\npointer. LittleCMS writes RGBA-sized rows into a 1-byte-per-pixel `L` image row.\n\n### Details\n\n`src/PIL/ImageCms.py:ImageCmsTransform.apply()` accepts an optional caller\nsupplied `imOut`:\n\n```python\ndef apply(self, im, imOut=None):\n if imOut is None:\n imOut = Image.new(self.output_mode, im.size, None)\n self.transform.apply(im.getim(), imOut.getim())\n imOut.info[\"icc_profile\"] = self.output_profile.tobytes()\n return imOut\n```\n\nIf `imOut` is provided, Pillow does not check:\n\n```text\nim.mode == self.input_mode\nimOut.mode == self.output_mode\n```\n\nThe C wrapper in `src/_imagingcms.c` unwraps both image cores and only checks\nthat the output dimensions are at least as large as the input dimensions:\n\n```c\nstatic int\npyCMSdoTransform(Imaging im, Imaging imOut, cmsHTRANSFORM hTransform) {\n if (im-\u003exsize \u003e imOut-\u003exsize || im-\u003eysize \u003e imOut-\u003eysize) {\n return -1;\n }\n\n for (i = 0; i \u003c im-\u003eysize; i++) {\n cmsDoTransform(hTransform, im-\u003eimage[i], imOut-\u003eimage[i], im-\u003exsize);\n }\n\n pyCMScopyAux(hTransform, imOut, im);\n return 0;\n}\n```\n\n`findLCMStype()` maps `RGB`, `RGBA`, and `RGBX` transform modes to LittleCMS\n`TYPE_RGBA_8`, which writes 4 bytes per pixel:\n\n```c\ncase IMAGING_MODE_RGB:\ncase IMAGING_MODE_RGBA:\ncase IMAGING_MODE_RGBX:\n return TYPE_RGBA_8;\n```\n\nSo with a transform declared as `RGBA -\u003e RGBA`, LittleCMS writes `4 * width`\nbytes to each output row. If the supplied output image is mode `L`, Pillow only\nallocated `1 * width` bytes for that row.\n\nFor width 4096:\n\n```text\ndestination row allocation: 4096 bytes\nLittleCMS write size: 16384 bytes\noverflow: ~12288 bytes past the row\n```\n\nThe bug does not require a large image. Width 8 was enough to corrupt heap\nmetadata. At width 8, `apply()` returned to Python and printed `after`; glibc\ndetected the corrupted heap later during cleanup.\n\n### PoC\n\nTiny heap corruption trigger:\n\n```python\nfrom PIL import Image, ImageCms\n\nsrgb = ImageCms.createProfile(\"sRGB\")\ntransform = ImageCms.buildTransform(srgb, srgb, \"RGBA\", \"RGBA\")\n\nim = Image.new(\"RGBA\", (8, 1), (0x41, 0x42, 0x43, 0x44))\nout = Image.new(\"L\", (8, 1), 0)\n\nprint(\"before\", flush=True)\ntransform.apply(im, out)\nprint(\"after\")\n```\n\nObserved locally on Pillow `12.3.0.dev0`:\n\n```text\nbefore\nafter\nfree(): invalid next size (normal)\nAborted (core dumped)\n```\n\nControlled overwrite evidence PoC:\n\n```python\nfrom PIL import Image, ImageCms\n\nsrgb = ImageCms.createProfile(\"sRGB\")\ntransform = ImageCms.buildTransform(srgb, srgb, \"RGBA\", \"RGBA\")\n\nim = Image.new(\"RGBA\", (4096, 1), (0x41, 0x42, 0x43, 0x44))\nout = Image.new(\"L\", (4096, 1), 0)\n\ntransform.apply(im, out)\n```\n\nRun under gdb:\n\n```bash\ngdb -q --batch -ex run -ex bt --args \\\n python3 b022_controlled.py\n```\n\nObserved on Pillow `12.3.0.dev0`:\n\n```text\nProgram received signal SIGSEGV, Segmentation fault.\n___pthread_mutex_lock (mutex=mutex@entry=0x4443424144434241)\n#1 _cmsLockPrimitive (m=0x4443424144434241)\n#2 defMtxLock (id=0x4443424144434241, mtx=0x4443424144434241)\n#3 _cmsLockMutex (ContextID=0x4443424144434241, mtx=0x4443424144434241)\n#4 cmsSaveProfileToIOhandler(...)\n#5 cmsSaveProfileToMem(...)\n#6 cms_profile_tobytes (...) at src/_imagingcms.c:152\n```\n\n`0x4443424144434241` is the attacker-controlled source pixel pattern\n`b\"ABCDABCD\"` interpreted as a little-endian pointer-sized value.\n\nUsing source pixels `(1, 2, 3, 4)` similarly produced a faulting pointer of\n`0x403020104030201`, matching the repeated pixel bytes.\n\n### Impact\n\nThis is a heap out-of-bounds write in Pillow\u0027s native ImageCms extension,\nreachable through public API.\n\nApplications are impacted if untrusted users can control ImageCms transform\nparameters and/or provide the output image object passed to\n`ImageCmsTransform.apply()`. The source image pixels influence the bytes written\nout of bounds.\n\n## Suggested fix\n\nValidate modes before calling into the native transform:\n\n```python\ndef apply(self, im, imOut=None):\n if im.mode != self.input_mode:\n raise ValueError(\"input mode mismatch\")\n if imOut is None:\n imOut = Image.new(self.output_mode, im.size, None)\n elif imOut.mode != self.output_mode:\n raise ValueError(\"output mode mismatch\")\n self.transform.apply(im.getim(), imOut.getim())\n imOut.info[\"icc_profile\"] = self.output_profile.tobytes()\n return imOut\n```\n\nThe C extension should also defensively reject mismatched image modes before\ncalling `cmsDoTransform()`.",
"id": "GHSA-9hw9-ch79-4vh6",
"modified": "2026-07-20T23:19:00Z",
"published": "2026-07-20T23:19:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-9hw9-ch79-4vh6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59205"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/pull/9715"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/a9ffc42bedf4fc0a7ef8d6486e7f9e81e3397721"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2026-3453.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-pillow/Pillow"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/releases/tag/12.3.0"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Pillow: Controlled heap out-of-bounds write in Pillow `ImageCmsTransform.apply()` via output mode mismatch"
}
GHSA-9HWG-WQ94-95PR
Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2026-08-11 15:30
VLAI
Details
SMM memory corruption vulnerability allowing a possible attacker to write fixed or predictable data to SMRAM. Exploiting this issue could lead to escalating privileges to SMM.
Severity
8.2 (High)
{
"affected": [],
"aliases": [
"CVE-2021-42554"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-03T02:15:00Z",
"severity": "CRITICAL"
},
"details": "SMM memory corruption vulnerability allowing a possible attacker to write fixed or predictable data to SMRAM. Exploiting this issue could lead to escalating privileges to SMM.",
"id": "GHSA-9hwg-wq94-95pr",
"modified": "2026-08-11T15:30:35Z",
"published": "2022-02-10T00:00:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42554"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-306654.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-306654.pdf"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220216-0007"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge/SA-2022012"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/796611"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9HWW-4QMV-3747
Vulnerability from github – Published: 2026-05-04 18:30 – Updated: 2026-05-04 18:30
VLAI
Details
Memory corruption when dynamically changing the size of a previously allocated buffer while its contents are being modified.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-47404"
],
"database_specific": {
"cwe_ids": [
"CWE-120",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-04T17:16:20Z",
"severity": "MODERATE"
},
"details": "Memory corruption when dynamically changing the size of a previously allocated buffer while its contents are being modified.",
"id": "GHSA-9hww-4qmv-3747",
"modified": "2026-05-04T18:30:30Z",
"published": "2026-05-04T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47404"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/may-2026-bulletin.html"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
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, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.
- Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
Mitigation MIT-4.1
Architecture and Design
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.
Mitigation MIT-10
Operation
Build and Compilation
Strategy: Environment Hardening
- Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.
- D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
Mitigation MIT-9
Implementation
- Consider adhering to the following rules when allocating and managing an application's memory:
- Double check that the buffer is as large as specified.
- When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
- Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
- If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
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-13
Implementation
Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.
No CAPEC attack patterns related to this CWE.