File-transfer type confusion permits unauthorized repository writes in Psono Server
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 7.2.4
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Psono Server (both the Community and Enterprise editions) is affected. An authenticated user with only read-only access to a file can abuse a flaw in file-transfer handling to write data into the owner's file repository, including overwriting stored objects and consuming storage.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Psono Server (CE & EE) versions 1.0.0 through 7.2.3 did not enforce the direction of file-transfer credentials on file-repository operations. An authenticated remote attacker with read-only access to a file could present a download transfer to the upload endpoint, obtain a signed upload URL for an attacker-selected object key, and append a chunk to the owner's file. Exploitation could upload or overwrite repository objects and consume storage, subject to transfer size, chunk-count, and lifetime limits.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- esaqa GmbH Psono
From 1.0.0 · fixed in 7.2.4
References 5
gitlab.com
- esaqa/esaqa/security-advisories/-/blob/master/advisories/CVE-2026-117469.md
- esaqa/psono/psono-server/-/blob/v7.2.3/psono/restapi/serializers/file_repository_upload.py
- esaqa/psono/psono-server/-/commit/64753b19bd8d03cfbed20db575f4dccb220d9ca4
- esaqa/psono/psono-server/-/releases/v7.2.4
- esaqa/psono/psono-server