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.
16557 vulnerabilities reference this CWE, most recent first.
GHSA-788W-269G-J92Q
Vulnerability from github – Published: 2022-05-13 01:20 – Updated: 2023-10-06 01:40A remote code execution vulnerability exists in the way that the ChakraCore scripting engine handles objects in memory, aka "Scripting Engine Memory Corruption Vulnerability." This affects ChakraCore. This CVE ID is unique from CVE-2018-8354, CVE-2018-8456, CVE-2018-8457, CVE-2018-8459.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.ChakraCore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-8391"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-21T20:33:53Z",
"nvd_published_at": "2018-09-13T00:29:00Z",
"severity": "HIGH"
},
"details": "A remote code execution vulnerability exists in the way that the ChakraCore scripting engine handles objects in memory, aka \"Scripting Engine Memory Corruption Vulnerability.\" This affects ChakraCore. This CVE ID is unique from CVE-2018-8354, CVE-2018-8456, CVE-2018-8457, CVE-2018-8459.",
"id": "GHSA-788w-269g-j92q",
"modified": "2023-10-06T01:40:40Z",
"published": "2022-05-13T01:20:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8391"
},
{
"type": "PACKAGE",
"url": "https://github.com/chakra-core/ChakraCore"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8391"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20210419154033/http://www.securityfocus.com/bid/105231"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "ChakraCore RCE Vulnerability"
}
GHSA-789G-HJF7-FQ63
Vulnerability from github – Published: 2022-10-20 12:00 – Updated: 2022-10-20 19:00Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the list parameter at /goform/SetVirtualServerCfg.
{
"affected": [],
"aliases": [
"CVE-2022-43024"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-19T19:15:00Z",
"severity": "CRITICAL"
},
"details": "Tenda TX3 US_TX3V1.0br_V16.03.13.11_multi_TDE01 was discovered to contain a stack overflow via the list parameter at /goform/SetVirtualServerCfg.",
"id": "GHSA-789g-hjf7-fq63",
"modified": "2022-10-20T19:00:30Z",
"published": "2022-10-20T12:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43024"
},
{
"type": "WEB",
"url": "https://github.com/tianhui999/myCVE/blob/main/TX3/TX3-6.md"
}
],
"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-78C2-XVVR-VQ4G
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2025-04-20 03:33An exploitable uninitialized variable vulnerability which leads to a stack-based buffer overflow exists in Iceni Argus. When it attempts to convert a malformed PDF to XML a stack variable will be left uninitialized which will later be used to fetch a length that is used in a copy operation. In most cases this will allow an aggressor to write outside the bounds of a stack buffer which is used to contain colors. This can lead to code execution under the context of the account running the tool.
{
"affected": [],
"aliases": [
"CVE-2016-8385"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-27T21:59:00Z",
"severity": "HIGH"
},
"details": "An exploitable uninitialized variable vulnerability which leads to a stack-based buffer overflow exists in Iceni Argus. When it attempts to convert a malformed PDF to XML a stack variable will be left uninitialized which will later be used to fetch a length that is used in a copy operation. In most cases this will allow an aggressor to write outside the bounds of a stack buffer which is used to contain colors. This can lead to code execution under the context of the account running the tool.",
"id": "GHSA-78c2-xvvr-vq4g",
"modified": "2025-04-20T03:33:25Z",
"published": "2022-05-13T01:01:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8385"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96472"
},
{
"type": "WEB",
"url": "http://www.talosintelligence.com/reports/TALOS-2016-0210"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-78CQ-MC55-X9RG
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42Heap buffer overflow in Tab Strip in Google Chrome on Windows prior to 88.0.4324.182 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-21155"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-22T22:15:00Z",
"severity": "CRITICAL"
},
"details": "Heap buffer overflow in Tab Strip in Google Chrome on Windows prior to 88.0.4324.182 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page.",
"id": "GHSA-78cq-mc55-x9rg",
"modified": "2022-05-24T17:42:51Z",
"published": "2022-05-24T17:42:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21155"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_16.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1175500"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BI6ZIJQYP5DFMYVX4J5OGOU2NQLEZ3SB"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FE5SIKEVYTMDCC5OSXGOM2KRPYLHYMQX"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202104-08"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-78FC-CGPQ-9VQ9
Vulnerability from github – Published: 2025-02-03 06:30 – Updated: 2025-02-03 18:30In secmem, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS09403554; Issue ID: MSV-2431.
{
"affected": [],
"aliases": [
"CVE-2025-20636"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-03T04:15:08Z",
"severity": "HIGH"
},
"details": "In secmem, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS09403554; Issue ID: MSV-2431.",
"id": "GHSA-78fc-cgpq-9vq9",
"modified": "2025-02-03T18:30:41Z",
"published": "2025-02-03T06:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20636"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/February-2025"
}
],
"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-78FM-RCJQ-JR27
Vulnerability from github – Published: 2024-10-30 18:30 – Updated: 2024-10-30 18:30Client / Server PCs with the HP Smart Universal Printing Driver installed are potentially vulnerable to Remote Code Execution and/or Elevation of Privilege. A client using the HP Smart Universal Printing Driver that sends a print job comprised of a malicious XPS file could potentially lead to Remote Code Execution and/or Elevation of Privilege on the PC.
{
"affected": [],
"aliases": [
"CVE-2024-9419"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-30T18:15:08Z",
"severity": "HIGH"
},
"details": "Client / Server PCs with the HP Smart Universal Printing Driver installed are potentially vulnerable to Remote Code Execution and/or Elevation of Privilege. A client using the HP Smart Universal Printing Driver that sends a print job comprised of a malicious XPS file could potentially lead to Remote Code Execution and/or Elevation of Privilege on the PC.",
"id": "GHSA-78fm-rcjq-jr27",
"modified": "2024-10-30T18:30:49Z",
"published": "2024-10-30T18:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9419"
},
{
"type": "WEB",
"url": "https://support.hp.com/us-en/document/ish_11505949-11505972-16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-78FP-CF4H-G36P
Vulnerability from github – Published: 2026-06-20 21:31 – Updated: 2026-09-11 19:18Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-mcmc-2m55-j8jj. This link is maintained to preserve external references.
Original Description
vLLM versions >= 0.10.2 and < 0.13.0 are missing sparse tensor validation in multimodal embeddings processing. Because PyTorch disables sparse tensor invariant checks by default, an attacker can submit crafted embedding requests with malformed (negative or out-of-bounds) tensor indices, when the prompt-embeds feature is enabled, to trigger crashes or resource exhaustion (denial of service), with potential for out-of-bounds/write-what-where memory corruption. This continues CVE-2025-62164, whose prior fix only disabled the feature by default rather than addressing the root cause.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0.10.2"
},
{
"fixed": "0.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-11T19:18:42Z",
"nvd_published_at": "2026-06-20T19:16:23Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-mcmc-2m55-j8jj. This link is maintained to preserve external references.\n\n### Original Description\n\nvLLM versions \u003e= 0.10.2 and \u003c 0.13.0 are missing sparse tensor validation in multimodal embeddings processing. Because PyTorch disables sparse tensor invariant checks by default, an attacker can submit crafted embedding requests with malformed (negative or out-of-bounds) tensor indices, when the prompt-embeds feature is enabled, to trigger crashes or resource exhaustion (denial of service), with potential for out-of-bounds/write-what-where memory corruption. This continues CVE-2025-62164, whose prior fix only disabled the feature by default rather than addressing the root cause.",
"id": "GHSA-78fp-cf4h-g36p",
"modified": "2026-09-11T19:18:42Z",
"published": "2026-06-20T21:31:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-mcmc-2m55-j8jj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56340"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-56340"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2491060"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-56340.json"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vllm-denial-of-service-via-unvalidated-multimodal-embeddings"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: vLLM introduced enhanced protection for CVE-2025-62164",
"withdrawn": "2026-09-11T19:18:42Z"
}
GHSA-78G4-XQWV-Q3G8
Vulnerability from github – Published: 2026-10-22 17:01 – Updated: 2026-10-22 17:01Summary
Every Pillow wheel from 11.1.0 onward bundles a libopenjp2 containing a heap-buffer-overflow write that is fixed upstream on master but has never appeared in an OpenJPEG release. See https://osv.dev/vulnerability/OSV-2025-219
Because the wheel bundles its own copy, a patched host OS does not help. It is reachable from Image.open(fp); im.load() with default settings.
I am reporting it here rather than only upstream because Pillow is where the vulnerable binary actually reaches users.
Note the inversion that makes this easy to miss: OpenJPEG 2.5.2 and earlier are safe. The bug was introduced in 954c6e3c (2024-06-25), so keeping the dependency current is what creates the exposure.
Details
Affected wheels
From .github/dependencies.json (openjpeg) at each tag:
| Pillow | bundled OpenJPEG | status |
|---|---|---|
| 10.4.0 | 2.5.2 | safe |
| 11.0.0 | 2.5.2 | safe |
| 11.1.0, 11.2.1, 11.3.0 | 2.5.3 | affected |
| 12.0.0 … 12.3.0 | 2.5.4 | affected |
Confirmed on an installed wheel: PIL.features.version_codec('jpg_2000') → 2.5.4, bundled file pillow.libs/libopenjp2-*.so.2.5.4. main still pins 2.5.4 as of 2026-10-06.
The defect
src/lib/openjp2/j2k.c, in opj_j2k_read_sod:
OPJ_UINT32 l_current_tile_part =
l_cstr_index->tile_index[p_j2k->m_current_tile_number].current_tpsno;
l_cstr_index->tile_index[...].tp_index[l_current_tile_part].end_header = l_current_pos;
l_cstr_index->tile_index[...].tp_index[l_current_tile_part].end_pos =
l_current_pos + p_j2k->m_specific_param.m_decoder.m_sot_length + 2;
tp_index is neither null-checked nor bounds-checked, and l_current_tile_part comes directly from the one-byte TPsot field of the SOT marker.
The correct guard already exists a few lines later in opj_j2k_add_tlmarker (j2k.c:8459), writing the same array at the same index behind if (tp_index && l_current_tile_part < nb_tps). One writer checked, its sibling not.
Reached by giving the codestream a valid TLM marker — so tp_index is allocated once by opj_j2k_build_tp_index_from_tlm, sized to the TLM entry count, and opj_j2k_read_sot then skips all resizing — while setting TNsot = 0 in every SOT, which keeps the TLM "valid" and lets TPsot walk past the allocation.
Patch status
Fixed upstream in 91d08b11 ("Fix heap buffer overlfow in opj_j2k_read_sod", 2026-02-10).
The newest OpenJPEG tag is v2.5.4 (2025-09-20), and compare/v2.5.4...91d08b11 reports ahead 6, behind 0 — the fix is in no release, 8 months on.
Suggested remediation
- Carry
91d08b11as a patch in the wheel build until an OpenJPEG release includes it — three lines, identical to a guard already present in the same file. - Consider asking OpenJPEG to cut a release; they have had an unreleased memory-corruption fix on master since February 2026, and every distro is shipping the vulnerable code.
- Your security handbook already tells applications to block EPS at the application layer. A similarly explicit note that
Image.open()ignores filename/Content-Type and will reach any compiled-in codec unlessformats=is passed would help downstream apps a lot.
Not a Pillow bug, but relevant: the extension allowlist most apps rely on does not apply
Image.open() sniffs magic bytes, so a JPEG 2000 codestream in a file named avatar.png declared Content-Type: image/png reaches the JP2 decoder anyway.
I verified this against a production service documenting PNG/JPEG-only uploads: it accepted and fully decoded a JP2 through exactly that path, with 16 formats reachable from one upload endpoint against 43 registered openers. That service has since fixed it by passing formats= and validating on the detected format rather than the client's Content-Type.
That is the reason a decoder-level issue like this one has much wider reach than downstream maintainers tend to assume.
Proof of concept
ASan build of OpenJPEG 2.5.4 interposed under a stock Pillow 12.3.0, running Image.open(p); im.load():
==766332==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 8
#0 opj_j2k_read_sod j2k.c:5086
#1 opj_j2k_read_tile_header j2k.c:9912
#2 opj_read_tile_header openjpeg.c:575
#3 j2k_decode_entry src/libImaging/Jpeg2KDecode.c:793
#4 ImagingJpeg2KDecode src/libImaging/Jpeg2KDecode.c:949
#5 _decode src/decode.c:132
located 8 bytes to the right of a 24-byte region allocated by
opj_j2k_build_tp_index_from_tlm j2k.c:8939
Frames 3–5 are Pillow's own decoder, not a synthetic harness. No non-default decoder options are involved; strict mode is on, which is Pillow's behaviour since Pillow never calls opj_decoder_set_strict_mode. A benign twin image runs the same path cleanly and returns a valid image, so this is the payload and not a parse failure.
I have deliberately not attached the PoC file to this initial report. I'm happy to attach the PoC, the builder script and the RIP-control harness here on request, or hold everything until a fix is ready.
No disclosure deadline from me; I will not publish anything while this is being worked on.
Impact
Any application that calls Image.open() / im.load() on an image it did not produce — the overwhelmingly common case for upload handlers, thumbnailers and preview pipelines — can be made to perform an out-of-bounds heap write by supplying one crafted file.
Floor, already certain. On a stock non-sanitised wheel the overflow performs 245 writes walking to +5856 bytes past a 24-byte allocation, and glibc's own heap-metadata checker aborts the process (corrupted size vs. prev_size, corrupted double-linked list, SIGABRT). One file reliably kills a long-lived worker.
Ceiling, demonstrated as a primitive but not as a finished exploit. With same-size-class objects alive on both sides — an ordinary busy heap — the walk crosses opj_event_mgr_t, which holds three opj_msg_callback function pointers, and opj_event_msg then calls one (event.c:136):
rip 0x4000 <- value chosen by the attacker's file layout
rsi 0x3ff2 <- m_error_data, written by the same walk
Shifting the codestream with a COM marker moves rip with it (0x16ce → 0x4000), so the instruction pointer is attacker-chosen rather than incidentally invalid. A benign control image leaves the same groomed heap untouched.
To be explicit about what I did not do: I have not built a working exploit. That additionally needs remote heap grooming and an ASLR defeat, and I attempted neither. I am reporting a controlled control-flow primitive, not a finished chain. The CVSS AC:H reflects that.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pillow"
},
"ranges": [
{
"events": [
{
"introduced": "11.1.0"
},
{
"fixed": "13.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-22T17:01:08Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nEvery Pillow wheel from 11.1.0 onward bundles a libopenjp2 containing a heap-buffer-overflow **write** that is fixed upstream on master but has never appeared in an OpenJPEG release. See https://osv.dev/vulnerability/OSV-2025-219\n\nBecause the wheel bundles its own copy, a patched host OS does not help. It is reachable from `Image.open(fp); im.load()` with default settings.\n\nI am reporting it here rather than only upstream because Pillow is where the vulnerable binary actually reaches users.\n\nNote the inversion that makes this easy to miss: **OpenJPEG 2.5.2 and earlier are safe.** The bug was introduced in `954c6e3c` (2024-06-25), so keeping the dependency current is what creates the exposure.\n\n### Details\n\n## Affected wheels\n\nFrom `.github/dependencies.json` (`openjpeg`) at each tag:\n\n| Pillow | bundled OpenJPEG | status |\n|---|---|---|\n| 10.4.0 | 2.5.2 | safe |\n| 11.0.0 | 2.5.2 | safe |\n| **11.1.0, 11.2.1, 11.3.0** | **2.5.3** | **affected** |\n| **12.0.0 \u2026 12.3.0** | **2.5.4** | **affected** |\n\nConfirmed on an installed wheel: `PIL.features.version_codec(\u0027jpg_2000\u0027)` \u2192 `2.5.4`, bundled file `pillow.libs/libopenjp2-*.so.2.5.4`. `main` still pins `2.5.4` as of 2026-10-06.\n\n## The defect\n\n`src/lib/openjp2/j2k.c`, in `opj_j2k_read_sod`:\n\n```c\nOPJ_UINT32 l_current_tile_part =\n l_cstr_index-\u003etile_index[p_j2k-\u003em_current_tile_number].current_tpsno;\nl_cstr_index-\u003etile_index[...].tp_index[l_current_tile_part].end_header = l_current_pos;\nl_cstr_index-\u003etile_index[...].tp_index[l_current_tile_part].end_pos =\n l_current_pos + p_j2k-\u003em_specific_param.m_decoder.m_sot_length + 2;\n```\n\n`tp_index` is neither null-checked nor bounds-checked, and `l_current_tile_part` comes directly from the one-byte `TPsot` field of the SOT marker.\n\nThe correct guard already exists a few lines later in `opj_j2k_add_tlmarker` (j2k.c:8459), writing the **same array at the same index** behind `if (tp_index \u0026\u0026 l_current_tile_part \u003c nb_tps)`. One writer checked, its sibling not.\n\nReached by giving the codestream a *valid* TLM marker \u2014 so `tp_index` is allocated once by `opj_j2k_build_tp_index_from_tlm`, sized to the TLM entry count, and `opj_j2k_read_sot` then skips all resizing \u2014 while setting `TNsot = 0` in every SOT, which keeps the TLM \"valid\" and lets `TPsot` walk past the allocation.\n\n## Patch status\n\nFixed upstream in `91d08b11` (\"Fix heap buffer overlfow in opj_j2k_read_sod\", 2026-02-10).\n\nThe newest OpenJPEG tag is **v2.5.4 (2025-09-20)**, and `compare/v2.5.4...91d08b11` reports *ahead 6, behind 0* \u2014 the fix is **in no release, 8 months on**.\n\n## Suggested remediation\n\n1. Carry `91d08b11` as a patch in the wheel build until an OpenJPEG release includes it \u2014 three lines, identical to a guard already present in the same file.\n2. Consider asking OpenJPEG to cut a release; they have had an unreleased memory-corruption fix on master since February 2026, and every distro is shipping the vulnerable code.\n3. Your security handbook already tells applications to block EPS at the application layer. A similarly explicit note that `Image.open()` ignores filename/Content-Type and will reach any compiled-in codec unless `formats=` is passed would help downstream apps a lot.\n\n## Not a Pillow bug, but relevant: the extension allowlist most apps rely on does not apply\n\n`Image.open()` sniffs magic bytes, so a JPEG 2000 codestream in a file named `avatar.png` declared `Content-Type: image/png` reaches the JP2 decoder anyway.\n\nI verified this against a production service documenting PNG/JPEG-only uploads: it accepted and fully decoded a JP2 through exactly that path, with 16 formats reachable from one upload endpoint against 43 registered openers. That service has since fixed it by passing `formats=` and validating on the detected format rather than the client\u0027s `Content-Type`.\n\nThat is the reason a decoder-level issue like this one has much wider reach than downstream maintainers tend to assume.\n\n### Proof of concept\n\nASan build of OpenJPEG 2.5.4 interposed under a **stock Pillow 12.3.0**, running `Image.open(p); im.load()`:\n\n```\n==766332==ERROR: AddressSanitizer: heap-buffer-overflow\nWRITE of size 8\n #0 opj_j2k_read_sod j2k.c:5086\n #1 opj_j2k_read_tile_header j2k.c:9912\n #2 opj_read_tile_header openjpeg.c:575\n #3 j2k_decode_entry src/libImaging/Jpeg2KDecode.c:793\n #4 ImagingJpeg2KDecode src/libImaging/Jpeg2KDecode.c:949\n #5 _decode src/decode.c:132\nlocated 8 bytes to the right of a 24-byte region allocated by\n opj_j2k_build_tp_index_from_tlm j2k.c:8939\n```\n\nFrames 3\u20135 are Pillow\u0027s own decoder, not a synthetic harness. No non-default decoder options are involved; strict mode is on, which is Pillow\u0027s behaviour since Pillow never calls `opj_decoder_set_strict_mode`. A benign twin image runs the same path cleanly and returns a valid image, so this is the payload and not a parse failure.\n\nI have deliberately **not** attached the PoC file to this initial report. I\u0027m happy to attach the PoC, the builder script and the RIP-control harness here on request, or hold everything until a fix is ready.\n\nNo disclosure deadline from me; I will not publish anything while this is being worked on.\n\n### Impact\n\nAny application that calls `Image.open()` / `im.load()` on an image it did not produce \u2014 the overwhelmingly common case for upload handlers, thumbnailers and preview pipelines \u2014 can be made to perform an out-of-bounds heap write by supplying one crafted file.\n\n**Floor, already certain.** On a stock non-sanitised wheel the overflow performs 245 writes walking to +5856 bytes past a 24-byte allocation, and glibc\u0027s own heap-metadata checker aborts the process (`corrupted size vs. prev_size`, `corrupted double-linked list`, SIGABRT). One file reliably kills a long-lived worker.\n\n**Ceiling, demonstrated as a primitive but not as a finished exploit.** With same-size-class objects alive on both sides \u2014 an ordinary busy heap \u2014 the walk crosses `opj_event_mgr_t`, which holds three `opj_msg_callback` function pointers, and `opj_event_msg` then calls one (event.c:136):\n\n```\nrip 0x4000 \u003c- value chosen by the attacker\u0027s file layout\nrsi 0x3ff2 \u003c- m_error_data, written by the same walk\n```\n\nShifting the codestream with a COM marker moves `rip` with it (`0x16ce` \u2192 `0x4000`), so the instruction pointer is attacker-**chosen** rather than incidentally invalid. A benign control image leaves the same groomed heap untouched.\n\nTo be explicit about what I did not do: I have **not** built a working exploit. That additionally needs remote heap grooming and an ASLR defeat, and I attempted neither. I am reporting a controlled control-flow primitive, not a finished chain. The CVSS AC:H reflects that.",
"id": "GHSA-78g4-xqwv-q3g8",
"modified": "2026-10-22T17:01:08Z",
"published": "2026-10-22T17:01:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-78g4-xqwv-q3g8"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/5f8114c8096b181fae493543cd3837d9f9a971cc"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/d3470c327840f4c216a1610f30e7091dfd0b97c0"
},
{
"type": "WEB",
"url": "https://github.com/uclouvain/openjpeg/commit/91d08b11a72764f6d199f32fa0c1b1abd4edc2ad"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-pillow/Pillow"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/releases/tag/13.0.0"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/OSV-2025-219"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Pillow: Bundled libopenjp2 2.5.4 in all wheels since 11.1.0 carries OSV-2025-219 heap-buffer-overflow write reachable from Image.open().load()"
}
GHSA-78GW-VJGG-GVX5
Vulnerability from github – Published: 2023-07-06 15:30 – Updated: 2025-11-04 21:30Multiple buffer overflow vulnerabilities exist in the vtysh_ubus binary of Milesight UR32L v32.3.0.5 due to the use of an unsafe sprintf pattern. A specially crafted HTTP request can lead to a buffer overflow. An attacker can send HTTP requests to trigger these vulnerabilities.This buffer overflow occurs in the set_openvpn_client function with the remote_subnet and the remote_mask variables when action is 2.
{
"affected": [],
"aliases": [
"CVE-2023-25123"
],
"database_specific": {
"cwe_ids": [
"CWE-121",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-06T15:15:15Z",
"severity": "HIGH"
},
"details": "Multiple buffer overflow vulnerabilities exist in the vtysh_ubus binary of Milesight UR32L v32.3.0.5 due to the use of an unsafe sprintf pattern. A specially crafted HTTP request can lead to a buffer overflow. An attacker can send HTTP requests to trigger these vulnerabilities.This buffer overflow occurs in the set_openvpn_client function with the remote_subnet and the remote_mask variables when action is 2.",
"id": "GHSA-78gw-vjgg-gvx5",
"modified": "2025-11-04T21:30:36Z",
"published": "2023-07-06T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25123"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1716"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1716"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-78H3-5X6W-7V3G
Vulnerability from github – Published: 2022-09-20 00:00 – Updated: 2022-09-20 00:00Adobe Bridge version 12.0.2 (and earlier) and 11.1.3 (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.
{
"affected": [],
"aliases": [
"CVE-2022-35700"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-19T16:15:00Z",
"severity": "HIGH"
},
"details": "Adobe Bridge version 12.0.2 (and earlier) and 11.1.3 (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-78h3-5x6w-7v3g",
"modified": "2022-09-20T00:00:29Z",
"published": "2022-09-20T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35700"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/bridge/apsb22-49.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"
}
]
}
Mitigation MIT-3
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
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
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
- 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
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
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
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.