Mattermost contains an information disclosure vulnerability where, during the process of updating a user's username, the application fails to properly sanitize the user object. As a result, the password hash is inadvertently included in the response body, exposing sensitive credential information to the client.
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.
This repository is a deliberately vulnerable demo application rather than a weaponized exploit kit. The core vulnerable code is in app/store.py, a small Flask-based team-chat API. Its main security flaw is in rename_user(), which handles PATCH /users/<id>: after optionally updating display_name, it returns the full stored user object instead of a sanitized copy. Because the stored object includes the bcrypt password hash, the endpoint leaks password hashes in the response body. The GET user endpoints correctly call _sanitize(), making the PATCH path the only planted flaw. Exploit capability: an attacker who can reach the web API can issue a PATCH request to /users/<id> and obtain the target user's bcrypt password hash from the JSON response. The request does not require any special exploit primitives beyond standard HTTP/JSON interaction. The tests show this explicitly: tests/test_store.py asserts that PATCH leaks a field named password beginning with $2b$. The same test file also demonstrates that two fresh app instances leak different hashes for the same user because passwords are re-hashed with fresh salts inside create_app(). Repository structure: the security-relevant application code is concentrated in app/store.py and app/wsgi.py. Dockerfile and docker-compose.yml package and run two identical instances on localhost:8001 and localhost:8002. The tests/ directory contains unit tests validating both intended behavior and the intentional leak. The traffic/ directory contains a functional requests-based test suite used to generate normal application traffic; notably, it does not assert on the absence of password leakage, which is central to the demo narrative. The rest of the repository under video/ and docs/ supports documentation and video generation for demonstrating how ReGrade detects the leak by comparing traffic between two identical instances. Operationally, the demo shows a realistic discovery workflow: record traffic against instance-a, replay against instance-b, then observe that benign dynamic fields such as login tokens and channel timestamps differ, while the leaked $.password field remains as the meaningful finding. Although this repository is framed as a demo of ReGrade-based discovery, the underlying vulnerability is real and directly exploitable through the PATCH endpoint.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
No public activity tracked yet. Mallory keeps watching.
No public activity observed for this vulnerability.
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.