- NIST's record for CVE-2026-104051 says PictShare before 3.7.1 returns a file's secret delete code to unauthenticated callers, who can then delete the file.
- The same response exposes uploader IP address, User Agent and remote port, so the flaw affects privacy as well as availability.
- Teams running PictShare should confirm they are on 3.7.1 or later and ask where else their software returns whole records.
A secret stored beside the label
Asking for a file's details should not hand over the key that destroys it. In PictShare before version 3.7.1, according to the NIST National Vulnerability Database (NVD), it did.
The lesson here is about defaults. Software that returns everything it knows about an object, and relies on the caller to ignore the sensitive parts, will eventually give away a secret. It is like asking a clerk for a folder's cover sheet and being handed the whole folder.
What the record says
NVD published CVE-2026-104051 on October 1, 2026 and last modified it on October 2. It describes an information disclosure flaw in PictShare before 3.7.1.
An unauthenticated attacker can call the API::info() endpoint. That endpoint returns the complete raw metadata object for a file, with no whitelist of permitted fields. The object includes the secret delete_code.
The record says the attacker needs only the file's hash, and that hash is publicly visible. With the delete code in hand, the attacker can call the delete API and permanently remove arbitrary files.
How the mechanism works
Think of two doors. One is the info API, meant to describe a file. The other is the delete API, meant to be used only by the person who uploaded it. The delete code is the key to the second door.
The flaw is that the first door shows the key. The info endpoint hands back the stored metadata as it is, without filtering. A whitelist would list the safe fields, such as a file's public details, and return only those. Without one, any field added to the record later is exposed automatically.
That is why the flaw sits in design, not in an exotic attack. No login, no special position on the network and no user interaction is needed, according to the scoring vector.
The privacy cost lands on uploaders
The same unfiltered response also exposes the uploader's IP address, User Agent, remote port and the file's SHA-1 hash. The record lists loss of uploader privacy alongside loss of content integrity and availability.
So two groups carry the risk. Owners of a PictShare instance can see content removed by strangers. People who uploaded files can have identifying details read by anyone who knows the file hash.
The NVD record does not say the flaw has been exploited in the wild. It also does not say how many installations exist.
Reading the score
The CVSS 3.1 vector rates confidentiality impact as low, integrity as none and availability as high. That matches the damage: deletion is rated as lost availability, and the exposed metadata as limited confidentiality loss.
The record's own description still names loss of content integrity. The scores are VulnCheck's, as listed by NVD.
What leaders should ask
First, ask whether anyone in the organisation runs PictShare. If so, confirm the version is 3.7.1 or later. NVD references a vendor commit and the v3.7.1 release on GitHub, and a VulnCheck advisory.
Second, ask developers where else your own APIs return whole records. Any endpoint that serialises a stored object directly deserves a review for tokens, codes and internal fields.
Third, ask whether secrets and public identifiers live in the same object. If they do, a single missing filter is enough to expose one through the other.
A system that lists what it may reveal fails quietly. A system that lists what it must hide fails the first time someone forgets an entry.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
