# CVE-2024-23649: Any authenticated user may obtain private message details from other users on the same instance

> Any authenticated user can read arbitrary private messages from other users by exploiting a missing authorization check in the report API.

- **Severity:** High 7.5 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 24 Jan 2024
- **Updated:** 30 May 2025
- **Also known as:** GHSA-r64r-5h43-26qv

## What is CVE-2024-23649?

CVE-2024-23649 is a high-severity missing authorization vulnerability in LemmyNet lemmy, published on 24 Jan 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

Lemmy is a link aggregator and forum for the fediverse. Starting in version 0.17.0 and prior to version 0.19.1, users can report private messages, even when they're neither sender nor recipient of the message. The API response to creating a private message report contains the private message itself, which means any user can just iterate over message ids to (loudly) obtain all private messages of an instance. A user with instance admin privileges can also abuse this if the private message is removed from the response, as they're able to see the resulting reports.

Creating a private message report by POSTing to `/api/v3/private_message/report` does not validate whether the reporter is the recipient of the message. lemmy-ui does not allow the sender to report the message; the API method should likely be restricted to accessible to recipients only. The API response when creating a report contains the `private_message_report_view` with all the details of the report, including the private message that has been reported:

Any authenticated user can obtain arbitrary (untargeted) private message contents. Privileges required depend on the instance configuration; when registrations 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.

Version 0.19.1 contains a patch for this issue. A workaround is available. 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.

Weakness: CWE-285 (Improper Authorization), CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor)

## Which versions are affected by CVE-2024-23649?

2 open source packages ship an affected version, including lemmy_server. It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `lemmy_server` | crates.io | From 0.17.0 | 0.19.1 |
| `lemmy_server` | crates.io | From 0.17.0 | 0.19.1 |

Products: Join-Lemmy Lemmy.

## How do I fix CVE-2024-23649?

Upgrade lemmy_server to 0.19.1 or later.

## Is CVE-2024-23649 being exploited?

There is no known exploitation of CVE-2024-23649 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2024-23649 and fix it if it is affected.

What it is: CVE-2024-23649 is a high-severity missing authorization vulnerability in LemmyNet lemmy, published on 24 Jan 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2024-23649 in the wild and no public exploit code.

Affected packages and fixed versions:
- lemmy_server (crates.io): affected from 0.17.0; fixed in 0.19.1
- lemmy_server (crates.io): affected from 0.17.0; fixed in 0.19.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2024-23649/ (Markdown: https://insights.sbomify.com/CVE-2024-23649/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2024-23649
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-23649
- OSV: https://osv.dev/vulnerability/CVE-2024-23649

---
From sbomify Insights: https://insights.sbomify.com/CVE-2024-23649/
Summaries are generated and may contain mistakes; the official description above is the record.