https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 05:41:42 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-49836 <p>psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to version 1.17.1, `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.</p> <p>psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to version 1.17.1, `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.</p> https://db.gcve.eu/vuln/fkie_cve-2026-49836 https://db.gcve.eu/vuln/ghsa-2rmg-vrx8-9j2f <p><strong>Affected:</strong> PyPI: psd-tools</p> <p># psd-tools: arbitrary file write/read via smart-object path traversal</p> <p>## Summary</p> <p>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.</p> <p>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**.</p> <p>## Details</p> <p>### Write path — `SmartObject.save()` (primary)</p> <p>`src/psd_tools/api/smart_object.py:170-179` (tag `v1.17.0`):</p> <p>```python def save(self, filename: str | None = None) -&gt; None: if filename is None: filename = self.filename # untrusted, straight from the file with open(filename, &#34;wb&#34;) as f: f.write(self.data) # attacker-controlled bytes ```</p> <p>`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…</p> <p><strong>Affected:</strong> PyPI: psd-tools</p> <p># psd-tools: arbitrary file write/read via smart-object path traversal</p> <p>## Summary</p> <p>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.</p> <p>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**.</p> <p>## Details</p> <p>### Write path — `SmartObject.save()` (primary)</p> <p>`src/psd_tools/api/smart_object.py:170-179` (tag `v1.17.0`):</p> <p>```python def save(self, filename: str | None = None) -&gt; None: if filename is None: filename = self.filename # untrusted, straight from the file with open(filename, &#34;wb&#34;) as f: f.write(self.data) # attacker-controlled bytes ```</p> <p>`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…</p> https://db.gcve.eu/vuln/ghsa-2rmg-vrx8-9j2f https://db.gcve.eu/vuln/pysec-2026-2969 <p><strong>Affected:</strong> PyPI: psd-tools</p> <p># psd-tools: arbitrary file write/read via smart-object path traversal</p> <p>## Summary</p> <p>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.</p> <p>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**.</p> <p>## Details</p> <p>### Write path — `SmartObject.save()` (primary)</p> <p>`src/psd_tools/api/smart_object.py:170-179` (tag `v1.17.0`):</p> <p>```python def save(self, filename: str | None = None) -&gt; None: if filename is None: filename = self.filename # untrusted, straight from the file with open(filename, &#34;wb&#34;) as f: f.write(self.data) # attacker-controlled bytes ```</p> <p>`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…</p> <p><strong>Affected:</strong> PyPI: psd-tools</p> <p># psd-tools: arbitrary file write/read via smart-object path traversal</p> <p>## Summary</p> <p>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.</p> <p>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**.</p> <p>## Details</p> <p>### Write path — `SmartObject.save()` (primary)</p> <p>`src/psd_tools/api/smart_object.py:170-179` (tag `v1.17.0`):</p> <p>```python def save(self, filename: str | None = None) -&gt; None: if filename is None: filename = self.filename # untrusted, straight from the file with open(filename, &#34;wb&#34;) as f: f.write(self.data) # attacker-controlled bytes ```</p> <p>`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…</p> https://db.gcve.eu/vuln/pysec-2026-2969 https://db.gcve.eu/vuln/ubuntu-cve-2026-49836 <p><strong>Affected:</strong> Ubuntu:24.04:LTS: psd-tools, Ubuntu:26.04:LTS: psd-tools</p> <p>psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to version 1.17.1, `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.</p> <p><strong>Affected:</strong> Ubuntu:24.04:LTS: psd-tools, Ubuntu:26.04:LTS: psd-tools</p> <p>psd-tools is a Python package for working with Adobe Photoshop PSD files. Prior to version 1.17.1, `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.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-49836