Skip to content

Bundled libtiff 4.7.1 is vulnerable to CVE-2026-4775 (integer overflow in putcontig8bitYCbCr44tile) #9579

Description

@smallbrian

Summary

Pillow 12.1.1 and 12.2.0 bundle libtiff 4.7.1 in pillow.libs/, which contains the vulnerable code from CVE-2026-4775 — a signed integer overflow in putcontig8bitYCbCr44tile (and related functions) in tif_getimage.c that can cause an out-of-bounds heap write via a specially crafted TIFF file, potentially resulting in denial of service or arbitrary code execution.

Proof

1. Pillow bundles its own libtiff and ignores the system library

$ python -c "from PIL import features; print(features.version('libtiff'))"
4.7.1

$ ldd /usr/local/lib/python3.11/site-packages/PIL/*.so | grep tiff
libtiff-76d51d59.so.6.2.0 => .../site-packages/pillow.libs/libtiff-76d51d59.so.6.2.0

2. The official libtiff 4.7.1 tarball contains the vulnerable code

Downloaded directly from https://download.osgeo.org/libtiff/tiff-4.7.1.tar.gz and checked libtiff/tif_getimage.c:

2219:    int32_t incr = 3 * w + 4 * toskew;   ← vulnerable
2359:    int32_t incr = 2 * toskew + w;        ← vulnerable
2515:    int32_t incr = 2 * toskew + w;        ← vulnerable

3. The fix postdates the 4.7.1 release

The upstream fix is commit 782a11d6, authored February 22, 2026 — after 4.7.1 shipped. The Debian security team also describes their fix as a "backport", confirming it was not present in upstream 4.7.1.

The fix changes int32_t to const tmsize_t with explicit casts to prevent overflow:

- int32_t incr = 3 * w + 4 * toskew;
+ const tmsize_t incr = 3 * (tmsize_t)w + 4 * (tmsize_t)toskew;

Impact

Any application using Pillow to open untrusted TIFF files is exposed. Image.open() on a crafted TIFF file triggers the vulnerable code path in the bundled libtiff. Upgrading the system libtiff package does not help — Pillow loads its own copy from pillow.libs/ regardless.

Suggested Fix

Update the vendored libtiff to a commit that includes 782a11d6 (i.e., post-4.7.1 main branch), or apply the three-line patch to the vendored copy before the next wheel build.

References

Activity

  1. radarhere commented on Apr 21, 2026

    @radarhere
    Member

    If this is a high severity problem, then do you know why libtiff hasn't released a new version to address it?

  2. smallbrian commented on Apr 21, 2026

    @smallbrian
    Author

    Good question, and I looked into this more carefully. Pillow doesn't vendor libtiff source — the wheel build downloads a release tarball from download.osgeo.org using the version pinned in .github/dependencies.json, which is currently "tiff": "4.7.1". So the fix does depend on libtiff tagging a new release. Without that, options would be to apply the patch on top of the downloaded tarball during the build, or switch to building from a git snapshot. Apologies for the imprecision in my earlier description.

  3. smallbrian commented on Apr 21, 2026

    @smallbrian
    Author

    I submitted an issue on their side: https://gitlab.com/libtiff/libtiff/-/work_items/825

  4. radarhere commented on Jun 1, 2026

    @radarhere
    Member

    After their response that we should patch it ourselves, I've created #9646

  5. radarhere commented on Jul 7, 2026

    @radarhere
    Member

    libtiff 4.7.2 has now been released.

  6. radarhere commented on Aug 7, 2026

    @radarhere
    Member

    #9839 has upgraded our version of libtiff to 4.7.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions