security: pin Pillow to patched versions in requirements

[mobasi-team]

What this change does

This PR hardens ALEAPP against supply-chain and parser-level image risk by pinning Pillow in requirements.txt from:

• pillow

to:

• pillow>=10.3.0,<12.0.0

Why this is important

ALEAPP processes attacker-controlled evidence files and uses Pillow decoding in multiple artifacts:

• scripts/artifacts/chatgpt.py
• scripts/artifacts/SamsungHoneyboard.py
• scripts/artifacts/torThumbs.py

Leaving Pillow unpinned can result in vulnerable versions being installed depending on environment state.

Maintainer acknowledgement and decision requested

As of March 3, 2026, current advisories indicate CVE-2026-25990 affects pillow >=10.3.0, <12.1.1 (fixed in 12.1.1).

So this PR's current range (>=10.3.0,<12.0.0) improves posture against older issues, but does not fully clear the newest disclosed Pillow vulnerability.

Could maintainers confirm preferred direction?

1. Security-first: move to pillow>=12.1.1,<13.0.0 (fully patched for CVE-2026-25990; implies Python 3.10+ runtime baseline for Pillow 12).
2. Compatibility-first: keep Python 3.9-compatible dependency range and use compensating controls until baseline can be raised.

Once you choose, we can push the exact follow-up change immediately.

Security references

• CVE-2026-25990
• GHSA-cfh3-3jmp-rvhc
• Pillow 12.1.1 release notes
• Pillow Python support matrix

Older relevant CVEs:

• CVE-2023-50447
• CVE-2022-22817
• CVE-2024-28219
• CVE-2023-5129

Additional references:

• Snyk Pillow package advisories
• Pillow release history

Validation performed

• Created a clean Python 3.11 virtual environment.
• Ran python -m pip install -r requirements.txt.
• Dependency resolution completed successfully for the pinned range in this branch.

Scope

• One-file dependency hardening in:
  • requirements.txt

[mobasi-team]

@stark4n6 there was a new CVE in pillow since we wrote the original report, so for the pillow supply chain to be truly CVE free, it would need to be pillow>=12.1.1,<13.0.0. However, this removes support for python 3.9.

How do you want to proceed?

[abrignoni]

@stark4n6 I think that we should move away from 3.9 support as long as it doesn't break anything else.
@bconstanzo any thoughts on any problems it would cause on any of your custom libraries? i don't think there would be issues but want to confirm with you.

[Johann-PLW]

Binaries versions are built with Python 3.12.
So on my side I don’t see any problems with that.

[bconstanzo]

I'll give it a look tomorrow, but off the top of my head 3.10, 3.11 and 3.12 were fine. Problem is that 3.13 introduced some changes in the internals of the interpreter, Cython adjusted the C code it generates but not the C++ part. I was hopping they'd port the C fix to C++ eventually, and we need that because astc_decomp (both the original and my fork) use Cython with C++.

[mobasi-team]

hi all - we took some time and wrote some tests to make sure the upgrade will be relatively seamless. see #672 for this proposal. let us know if we missed anything

[bconstanzo]

Confirm that we're safe up to 3.12: https://pypi.org/project/astc-decomp-faster/#files (those wheels were built in GitHub Actions)

Still have to dig a bit deeper into for 3.13 and 3.14, hopefully Cython or Python or Microsoft has solved the issue.