Loading vulnerability…
CVE-2026-104051 is an unauthenticated information-disclosure vulnerability in HaschekSolutions PictShare before version 3.7.1. The API::info() endpoint returns a complete raw file-metadata object without a field whitelist. An attacker who knows a publicly visible file hash can retrieve the file's secret delete_code and uploader metadata, including IP address, User-Agent, remote port, and SHA-1 hash. The exposed delete_code can then be submitted to the delete API to permanently remove uploaded files.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
The supplied repository contains four files: poc.py is a standalone Python CLI exploit, requirements.txt declares requests>=2.25, README.md documents the claimed vulnerability and remediation with illustrative PHP snippets, and .gitignore excludes Python cache artifacts. The script accepts a target base URL and public file hash, retrieves /api/info/<hash>, and prints returned fields including delete_code, ip, useragent, remote_port, sha1, and original_filename. Default behavior is read-only but actively obtains disclosed information; --delete enables a credential-reuse request that can delete the selected file. There is no hash enumeration, bulk targeting, code execution, or framework integration. The claimed root cause is direct serialization of internal metadata containing the same secret accepted by the deletion API. Documentation identifies version 3.7.1 as the fix and mentions CVE-2026-104356 as a related predictable-code issue, but the script does not implement that separate attack. Detection has an important limitation: sha1 is included in its sensitive-field list even though the documented patched API still returns sha1, so a patched target can produce misleading disclosure output. The script also does not validate deletion success beyond printing the response, does not check HTTP status codes, and assumes JSON is an object. No fixed victim address or external collection endpoint is embedded; the example domain and uploader IP in the README are illustrative. Findings are based on static inspection, not execution or independent verification of the CVE and version claims. Repository URL, git reference, archive path, and archive size were not supplied; the listed individual file sizes sum to 7,680 bytes.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
An unauthenticated information-disclosure flaw in PictShare versions before 3.7.1. The API::info() endpoint exposes raw metadata, including a secret delete_code. An attacker can use a publicly visible file hash to retrieve that code and call the delete API to permanently delete arbitrary files; exposed metadata also includes uploader IP address, user agent, remote port, and SHA-1 hash.
An unauthenticated remote information-disclosure flaw in PictShare versions before 3.7.1. The API::info() endpoint exposes raw metadata, including a secret deletion code, enabling attackers who know a public file hash to delete arbitrary uploaded files. It also leaks uploader IP address, user agent, remote port, and SHA-1 hash, affecting privacy, integrity, and availability.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.