Relax Pillow version constraint to allow ≥12.1.1 (security fix for CVE-2026-25990)

[KatyaTyurina]

Hi SuperAnnotate team 👋

We noticed that the current SDK dependency pins Pillow to:

pillow >= 9.5, ~=10.0

However, Pillow versions below 12.1.1 are affected by CVE-2026-25990.
Because of this, we are required to upgrade to Pillow ≥12.1.1 in our environment.

At the moment, the current version constraint prevents us from doing so.

Could you please clarify:

1. Are there any known compatibility issues with Pillow 12.x?
2. Are there plans to widen the dependency constraint to allow Pillow ≥12.1.1?
3. Would you consider relaxing the bound (e.g., pillow>=9.5,<13) if compatibility allows?

This is currently blocking us from addressing a security vulnerability, so an update would be greatly appreciated.

Thank you!

[drQedwards]

The CVE checks out — this is a real, current vulnerability. Confirmed details:

• A high-severity Out-of-Bounds Write vulnerability exists in Pillow's PSD handler, arising from a failure to validate negative image offsets in the C extension modules, which can lead to heap corruption or potentially RCE when processing malicious images.
• Versions 10.3.0 up to but not including 12.1.1 are affected, and Pillow 12.1.1 was released on 2026-02-11 with the fix.
• CVSS scores reported range from 7.5 to 8.9 depending on source, so this is a legitimate high-severity issue worth escalating.

1. Link the advisory directly rather than just the CVE number, since the CVE record itself was initially published with a wrong ID reference in some caches — pointing SuperAnnotate straight at GHSA-cfh3-3jmp-rvhc avoids any confusion on their end.
2. Mention the workaround you may already be using as a stopgap, since Pillow's advisory notes Image.open()'s formats parameter can restrict PSD processing entirely — this shows you've already mitigated locally and are asking about the real fix, not just flagging a blocker.
3. Your proposed bound pillow>=9.5,<13 is reasonable — you might also just ask whether they'd go further to pillow>=12.1.1 with no upper cap, since Pillow rarely breaks backward compat across their C API in ways that would justify a hard <13 ceiling.

Here's what's publicly relevant to those three questions, straight from Pillow's own release notes:

1. Known compatibility issues with Pillow 12.x
   Pillow 12.0.0 (2025-10-15) did carry real backwards-incompatible changes worth checking against SuperAnnotate's SDK:

Support for Python 3.9 was dropped in Pillow 12.0.0, since Python 3.9 reached end-of-life in October 2025 — a real blocker if their SDK still supports 3.9. Pillow Documentation
Several undocumented internal functions were removed outright: ImageFile.raise_oserror(), the IptcImageFile helper functions, some legacy ImageCms constants, and ImageMath.eval() (replaced by lambda_eval()/unsafe_eval()). Pillow Documentation
Support for LibTIFF versions earlier than 4, and FreeType versions before 2.9.1, was also removed. Pillow Documentation
None of this touches PSD handling, and none of it is likely to affect a typical annotation SDK unless it's doing something unusual with TIFF/ICC/EXIF internals or targeting EOL Python.

So there can be legitimate compatibility friction in a 10.x→12.x jump, but it's narrow and well-documented — a fair thing to ask about rather than assume away.
2/3. Whether they'd widen the constraint / drop the upper bound
I can't speak for SuperAnnotate's plans — that's genuinely their call. But one relevant data point for your own risk assessment: Pillow has already deprecated a couple of items (Image._show, ImageCms product_name attributes) with explicit removal slated for "Pillow 13 (2026-10-15)", meaning Pillow 13 is expected to make some further removals, on the same annual major-version cadence as 12.0.0 did. That's a reasonable basis for your suggestion that <13 is defensible as a real ceiling (not just arbitrary caution) — it isn't nothing, so I'd keep some upper bound in the ask rather than pushing for fully unbounded, unless you've already tested against 12.x yourselves. Pillow Documentation

[drQedwards]

Tl;dr: we’re working on this.