Skip to content

← Public intelligence

PyPI package

psd-tools

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.5PyPIAmendedPublished

    psd-tools composite/numpy has uncontrolled memory allocation via crafted PSD geometry

    CVE-2026-59991 · GHSA-8q6g-vjhf-jp8m

    Affected
    • PyPI psd-tools < 1.17.4
    Fixed in
    1.17.4· Vendor fix available
    Issue
    PSDImage.composite() (and .numpy()) allocate the output image buffer from the PSD's header geometry (width × height × channels × depth, and per-layer rectangles) before validating those values against the actual file contents. A tiny crafted PSD declaring huge dimensions causes a multi-gigabyte allocation. Critically, composite() then returns a (black) image with only a warning, no exception is raised, so a caller cannot detect or guard against it. Impact On psd-tools 1.17.2 (latest), default usage, a 49-byte PSD makes composite() commit ~3 GB and return successfully (warning only); .numpy() reaches ~7.5 GB, and the per-layer rectangle is a second lever (up to ~32 GB), all from an input under 100 bytes (input-to-commit amplification over 1000×). Because the buffer is committed before validation and no exception is thrown, any service that composites untrusted PSDs is exposed to denial of service: on a host with less RAM than the attacker-declared geometry the allocation is an…

    Recommended action: Upgrade to 1.17.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Medium, CVSS 4.6PyPIAmendedPublished

    psd-tools vulnerable to arbitrary file write via smart-object filename

    CVE-2026-49836 · GHSA-2rmg-vrx8-9j2f

    Affected
    • PyPI psd-tools <= 1.17.0
    Fixed in
    1.17.1· Vendor fix available
    Issue
    psd-tools: arbitrary file write/read via smart-object path traversal Summary In psd-tools (all releases exposing the SmartObject API through v1.17.0), SmartObject.save() writes an embedded smart object to a path taken verbatim from the PSD file. Because that name is attacker-controlled and unsanitised, a tool that extracts embedded objects from an untrusted .psd can be made to write attacker-chosen bytes to an attacker-chosen path (absolute or ../-traversing), outside its intended output directory. A secondary issue in SmartObject.open() for external-kind smart objects allows the attacker-controlled fullPath descriptor to be used as an arbitrary file read path, enabling exfiltration of the read content to the controlled write destination. Both issues are fixed in v1.17.1. Details Write path — SmartObject.save() (primary) src/psdtools/api/smartobject.py:170-179 (tag v1.17.0): self.filename comes from the file with no validation — the filename property (:62-67) returns…

    Recommended action: Upgrade to 1.17.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  3. Medium, CVSS 6.8PyPIAmendedPublished

    psd-tools: Compression module has unguarded zlib decompression, missing dimension validation, and hardening gaps

    CVE-2026-27809 · GHSA-24p2-j2jr-386w

    Affected
    • PyPI psd-tools < 1.12.2
    Fixed in
    1.12.2· Vendor fix available
    Issue
    A security review of the psdtools.compression module (conducted against the fix/invalid-rle-compression branch, commits 7490ffa–2a006f5) identified the following pre-existing issues. The two findings introduced and fixed by those commits (Cython buffer overflow, IndexError on lone repeat header) are excluded from this report. --- Findings 1. Unguarded zlib.decompress — ZIP bomb / memory exhaustion (Medium) Location: src/psdtools/compression/init.py, lines 159 and 162 zlib.decompress is called without a maxlength cap. A crafted PSD file containing a ZIP-compressed channel whose compressed payload expands to gigabytes would exhaust process memory before any limit is enforced. The RLE path is not vulnerable to this because the decoder pre-allocates exactly rowsize × height bytes; the ZIP path has no equivalent ceiling. Impact: Denial-of-service / OOM crash when processing untrusted PSD files. Suggested mitigation: Pass a reasonable maxlength to zlib.decompress, derived from the…

    Recommended action: Upgrade to 1.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  4. Critical, CVSS 9.3PyPIAmendedPublished

    Potential buffer overflow in psd-tools

    CVE-2020-10571 · GHSA-22jr-vc7j-g762

    Affected
    • PyPI psd-tools >= 1.8.37, <= 1.9.3
    Fixed in
    1.9.4· Vendor fix available
    Issue
    Impact An issue was discovered in psd-tools before 1.9.4. The Cython implementation of RLE decoding did not check for malformed PSD input data during decoding to the PIL.Image or NumPy format, leading to a Buffer Overflow. Patches Users of psd-tools version v1.8.37 to v1.9.3 should upgrade to v1.9.4. Workarounds Without Cython present on installation, buffer overflow does not occur but IndexError will be thrown. However, already installed psd-tools with Cython extention should be upgraded. References https://github.com/psd-tools/psd-tools/pull/198 For more information If you have any questions or comments about this advisory: Open an issue in psd-tools

    Recommended action: Upgrade to 1.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →