| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| lemmy_server | rust | >= 0.17.0, < 0.19.1 | 0.19.1 |
The vulnerability stems from missing authorization checks in the private message report creation endpoint. The commit diff shows a critical addition of a recipient validation check in crates/api/src/private_message_report/create.rs, where previously any user could submit reports for any private message ID. The vulnerable function handled the report creation without verifying the reporter's relationship to the message, enabling unauthorized access to private message contents through the API response. The high confidence comes from the explicit security check added in the patch and the CVE description directly linking this endpoint to the vulnerability.
If these details were not available in the response, but reports could still be created by any user, or at least by any admin, this would allow an instance admin to create reports and obtain the message contents from the report system.
This was originally discovered from incorrect reports on a 0.18.5 instance and has been replicated in a 0.19.0 test environment.
curl -v 'https://myinstance.tld/api/v3/private_message/report' -X POST -H 'Content-Type: application/json' -H 'authorization: Bearer ...' --data-raw '{"private_message_id":1,"reason":"i like reports"}'
Any authenticated user can obtain arbitrary (untargeted) private message contents. Privileges required depend on the instance configuration; when registratons are enabled without application system, the privileges required are practically none. When registration applications are required, privileges required could be considered low, but this assessment heavily varies by instance.
Any private message reports where the report creator is not equal to the private message recipient may be an attempt to exploit this. As this was originally discovered from an incorrect report, likely related to a bug in a client app, it should be noted that not all mismatching reports should be considered malicious; though a frequent occurrence of them likely indicates an exploitation attempt.
If an update to a fixed Lemmy version is not immediately possible, the API route can be blocked in the reverse proxy. This will prevent anyone from reporting private messages, but it will also prevent exploitation before the update has been applied.
nginx example:
location = /api/v3/private_message/report {
default_type application/json;
return 403 '{"error":"couldnt_create_report"}';
}
Ongoing coverage of React2Shell