lemmy_server
Activity
- Latest release
- 3y ago
- Total releases
- 45
- Cadence
- ~4 days
- Last 12 months
- 0
Details
- License
- AGPL-3.0
- First release
- Jul 24, 2021
| Version | Released | |
|---|---|---|
0.17.4
unknown
2 CVEs
GHSA-wr2m-38xh-rpc9
Apr 08, 2025
Lemmy user purging users or communities or banning users can delete images they didn't upload/exclusively use
Medium
Network
Low
None
None
SummaryAn improper uploaded media ownership check can result in inadvertent deletion of media when a user is banned with content removal or purged. This can lead to deletion of media that was not uploaded by the banned/purged user. This also applies to purged communities, in which case all media posted in that community will get deleted without proper ownership check.
This is limited to media with an DetailsLemmy did not associate users with media uploads until version 0.19.0 (#3927). Back when the first parts of content purging were implemented for 0.17.0 (#1809), it was therefore not possible to properly identify media belonging to a specific user for situations in which this data should get erased from pict-rs, Lemmy's media storage backend. Pict-rs deduplicates uploaded files transparently. As a result, it has two types of media deletion. A regular deletion will only remove the referenced alias, and if there are not other aliases pointing to the same file, the backing file will also be deleted. A purge on the other hand will delete all aliases pointing to the specified file, as well as the file itself. The logic implemented in 0.17.0 iterated over media URLs related to users and communities when purging them and purged them from pict-rs. This results in a full deletion of the backing media, even if either the same URL was the result of an upload by a different user, or the same media being uploaded by another user with a different alias. For user purges, Lemmy iterated over all posts they created and applied this to all media referenced in post URLs and post thumbnails. For community purges, this applied to all posts within this community. Additionally, the deletion of user avatars, banners, as well as the media from all their posts was implemented when users were banned with content removal. This includes local bans and also bans received via federation, when a user gets banned on their home instance. The function for purging images from pict-rs performs a check at the start to verify that the media ImpactInstances with open federationThe vast majority of Lemmy instances has open federation, which means that this can be exploited remotely without any authentication. Instances with limited or no federationExploitation requires user interaction by an admin of the targeted instance or a federation-linked instance if federation is enabled. It may also require authentication, as instances may not have open registrations. Fixed in
0.19.11
References Updated Apr 08, 2025 · Source: OSV.dev
CVE-2024-23649
GHSA-r64r-5h43-26qv
Jan 24, 2024
Any authenticated user may obtain private message details from other users on the same instance
7.5
/ 10
High
Network
Low
None
None
Unchanged
High
None
None
SummaryUsers 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. DetailsCreating a private message report by POSTing to In the report below, the creator with id 3 is different from the private message creator (id 2) and private message recipient (id 6). 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. PoCImpactAny 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. DetectionAny 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. Workaround when updating is not immediately possibleIf 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: Fixed in
0.19.1
References Updated Sep 10, 2026 · Source: OSV.dev |
0.17.4
unknown
Dependencies (37)
+ 29 more |
|
0.17.3
unknown
2 CVEs
GHSA-wr2m-38xh-rpc9
Apr 08, 2025
Lemmy user purging users or communities or banning users can delete images they didn't upload/exclusively use
Medium
Network
Low
None
None
SummaryAn improper uploaded media ownership check can result in inadvertent deletion of media when a user is banned with content removal or purged. This can lead to deletion of media that was not uploaded by the banned/purged user. This also applies to purged communities, in which case all media posted in that community will get deleted without proper ownership check.
This is limited to media with an DetailsLemmy did not associate users with media uploads until version 0.19.0 (#3927). Back when the first parts of content purging were implemented for 0.17.0 (#1809), it was therefore not possible to properly identify media belonging to a specific user for situations in which this data should get erased from pict-rs, Lemmy's media storage backend. Pict-rs deduplicates uploaded files transparently. As a result, it has two types of media deletion. A regular deletion will only remove the referenced alias, and if there are not other aliases pointing to the same file, the backing file will also be deleted. A purge on the other hand will delete all aliases pointing to the specified file, as well as the file itself. The logic implemented in 0.17.0 iterated over media URLs related to users and communities when purging them and purged them from pict-rs. This results in a full deletion of the backing media, even if either the same URL was the result of an upload by a different user, or the same media being uploaded by another user with a different alias. For user purges, Lemmy iterated over all posts they created and applied this to all media referenced in post URLs and post thumbnails. For community purges, this applied to all posts within this community. Additionally, the deletion of user avatars, banners, as well as the media from all their posts was implemented when users were banned with content removal. This includes local bans and also bans received via federation, when a user gets banned on their home instance. The function for purging images from pict-rs performs a check at the start to verify that the media ImpactInstances with open federationThe vast majority of Lemmy instances has open federation, which means that this can be exploited remotely without any authentication. Instances with limited or no federationExploitation requires user interaction by an admin of the targeted instance or a federation-linked instance if federation is enabled. It may also require authentication, as instances may not have open registrations. Fixed in
0.19.11
References Updated Apr 08, 2025 · Source: OSV.dev
CVE-2024-23649
GHSA-r64r-5h43-26qv
Jan 24, 2024
Any authenticated user may obtain private message details from other users on the same instance
7.5
/ 10
High
Network
Low
None
None
Unchanged
High
None
None
SummaryUsers 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. DetailsCreating a private message report by POSTing to In the report below, the creator with id 3 is different from the private message creator (id 2) and private message recipient (id 6). 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. PoCImpactAny 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. DetectionAny 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. Workaround when updating is not immediately possibleIf 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: Fixed in
0.19.1
References Updated Sep 10, 2026 · Source: OSV.dev |
0.17.3
unknown
Dependencies (37)
+ 29 more |
|
0.17.2
unknown
2 CVEs
GHSA-wr2m-38xh-rpc9
Apr 08, 2025
Lemmy user purging users or communities or banning users can delete images they didn't upload/exclusively use
Medium
Network
Low
None
None
SummaryAn improper uploaded media ownership check can result in inadvertent deletion of media when a user is banned with content removal or purged. This can lead to deletion of media that was not uploaded by the banned/purged user. This also applies to purged communities, in which case all media posted in that community will get deleted without proper ownership check.
This is limited to media with an DetailsLemmy did not associate users with media uploads until version 0.19.0 (#3927). Back when the first parts of content purging were implemented for 0.17.0 (#1809), it was therefore not possible to properly identify media belonging to a specific user for situations in which this data should get erased from pict-rs, Lemmy's media storage backend. Pict-rs deduplicates uploaded files transparently. As a result, it has two types of media deletion. A regular deletion will only remove the referenced alias, and if there are not other aliases pointing to the same file, the backing file will also be deleted. A purge on the other hand will delete all aliases pointing to the specified file, as well as the file itself. The logic implemented in 0.17.0 iterated over media URLs related to users and communities when purging them and purged them from pict-rs. This results in a full deletion of the backing media, even if either the same URL was the result of an upload by a different user, or the same media being uploaded by another user with a different alias. For user purges, Lemmy iterated over all posts they created and applied this to all media referenced in post URLs and post thumbnails. For community purges, this applied to all posts within this community. Additionally, the deletion of user avatars, banners, as well as the media from all their posts was implemented when users were banned with content removal. This includes local bans and also bans received via federation, when a user gets banned on their home instance. The function for purging images from pict-rs performs a check at the start to verify that the media ImpactInstances with open federationThe vast majority of Lemmy instances has open federation, which means that this can be exploited remotely without any authentication. Instances with limited or no federationExploitation requires user interaction by an admin of the targeted instance or a federation-linked instance if federation is enabled. It may also require authentication, as instances may not have open registrations. Fixed in
0.19.11
References Updated Apr 08, 2025 · Source: OSV.dev
CVE-2024-23649
GHSA-r64r-5h43-26qv
Jan 24, 2024
Any authenticated user may obtain private message details from other users on the same instance
7.5
/ 10
High
Network
Low
None
None
Unchanged
High
None
None
SummaryUsers 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. DetailsCreating a private message report by POSTing to In the report below, the creator with id 3 is different from the private message creator (id 2) and private message recipient (id 6). 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. PoCImpactAny 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. DetectionAny 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. Workaround when updating is not immediately possibleIf 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: Fixed in
0.19.1
References Updated Sep 10, 2026 · Source: OSV.dev |
0.17.2
unknown
Dependencies (38)
+ 30 more |
|
0.17.0
unknown
2 CVEs
GHSA-wr2m-38xh-rpc9
Apr 08, 2025
Lemmy user purging users or communities or banning users can delete images they didn't upload/exclusively use
Medium
Network
Low
None
None
SummaryAn improper uploaded media ownership check can result in inadvertent deletion of media when a user is banned with content removal or purged. This can lead to deletion of media that was not uploaded by the banned/purged user. This also applies to purged communities, in which case all media posted in that community will get deleted without proper ownership check.
This is limited to media with an DetailsLemmy did not associate users with media uploads until version 0.19.0 (#3927). Back when the first parts of content purging were implemented for 0.17.0 (#1809), it was therefore not possible to properly identify media belonging to a specific user for situations in which this data should get erased from pict-rs, Lemmy's media storage backend. Pict-rs deduplicates uploaded files transparently. As a result, it has two types of media deletion. A regular deletion will only remove the referenced alias, and if there are not other aliases pointing to the same file, the backing file will also be deleted. A purge on the other hand will delete all aliases pointing to the specified file, as well as the file itself. The logic implemented in 0.17.0 iterated over media URLs related to users and communities when purging them and purged them from pict-rs. This results in a full deletion of the backing media, even if either the same URL was the result of an upload by a different user, or the same media being uploaded by another user with a different alias. For user purges, Lemmy iterated over all posts they created and applied this to all media referenced in post URLs and post thumbnails. For community purges, this applied to all posts within this community. Additionally, the deletion of user avatars, banners, as well as the media from all their posts was implemented when users were banned with content removal. This includes local bans and also bans received via federation, when a user gets banned on their home instance. The function for purging images from pict-rs performs a check at the start to verify that the media ImpactInstances with open federationThe vast majority of Lemmy instances has open federation, which means that this can be exploited remotely without any authentication. Instances with limited or no federationExploitation requires user interaction by an admin of the targeted instance or a federation-linked instance if federation is enabled. It may also require authentication, as instances may not have open registrations. Fixed in
0.19.11
References Updated Apr 08, 2025 · Source: OSV.dev
CVE-2024-23649
GHSA-r64r-5h43-26qv
Jan 24, 2024
Any authenticated user may obtain private message details from other users on the same instance
7.5
/ 10
High
Network
Low
None
None
Unchanged
High
None
None
SummaryUsers 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. DetailsCreating a private message report by POSTing to In the report below, the creator with id 3 is different from the private message creator (id 2) and private message recipient (id 6). 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. PoCImpactAny 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. DetectionAny 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. Workaround when updating is not immediately possibleIf 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: Fixed in
0.19.1
References Updated Sep 10, 2026 · Source: OSV.dev |
0.17.0
unknown
Dependencies (38)
+ 30 more |
|
0.16.7
unknown
|
0.16.7
unknown
Dependencies (30)
+ 22 more |
|
0.16.3
unknown
|
0.16.3
unknown
Dependencies (41)
+ 33 more |
|
0.16.3-rc.1
unknown
|
0.16.3-rc.1
unknown
Dependencies (41)
+ 33 more |
|
0.16.2-rc.1
unknown
|
0.16.2-rc.1
unknown
Dependencies (40)
+ 32 more |
|
0.16.1-rc.1
unknown
|
0.16.1-rc.1
unknown
Dependencies (40)
+ 32 more |
|
0.16.0
unknown
|
0.16.0
unknown
Dependencies (40)
+ 32 more |
|
0.16.0-rc.4
unknown
|
0.16.0-rc.4
unknown
Dependencies (40)
+ 32 more |
|
0.16.0-rc.3
unknown
|
0.16.0-rc.3
unknown
Dependencies (40)
+ 32 more |
|
0.16.0-rc.2
unknown
|
0.16.0-rc.2
unknown
Dependencies (40)
+ 32 more |
|
0.15.4
unknown
|
0.15.4
unknown
Dependencies (41)
+ 33 more |
|
0.15.4-rc.1
unknown
|
0.15.4-rc.1
unknown
Dependencies (41)
+ 33 more |
|
0.15.2
unknown
|
0.15.2
unknown
Dependencies (41)
+ 33 more |
|
0.15.2-rc.1
unknown
|
0.15.2-rc.1
unknown
Dependencies (41)
+ 33 more |
|
0.15.0-rc.7
unknown
|
0.15.0-rc.7
unknown
Dependencies (42)
+ 34 more |
|
0.15.0-rc.3
unknown
|
0.15.0-rc.3
unknown
Dependencies (38)
+ 30 more |
|
0.14.5
unknown
|
0.14.5
unknown
Dependencies (36)
+ 28 more |
|
0.14.5-rc.2
unknown
|
0.14.5-rc.2
unknown
Dependencies (36)
+ 28 more |
|
0.14.5-rc.1
unknown
|
0.14.5-rc.1
unknown
Dependencies (36)
+ 28 more |
|
0.14.4-rc.4
unknown
|
0.14.4-rc.4
unknown
Dependencies (36)
+ 28 more |
|
0.14.3
unknown
|
0.14.3
unknown
Dependencies (36)
+ 28 more |
|
0.14.2
unknown
|
0.14.2
unknown
Dependencies (36)
+ 28 more |
|
0.14.2-rc.1
unknown
|
0.14.2-rc.1
unknown
Dependencies (36)
+ 28 more |
|
0.14.1
unknown
|
0.14.1
unknown
Dependencies (33)
+ 25 more |
|
0.14.0
unknown
|
0.14.0
unknown
Dependencies (33)
+ 25 more |
|
0.14.0-rc.2
unknown
|
0.14.0-rc.2
unknown
Dependencies (33)
+ 25 more |
|
0.14.0-rc.1
unknown
|
0.14.0-rc.1
unknown
Dependencies (33)
+ 25 more |
|
0.13.5
unknown
|
0.13.5
unknown
Dependencies (32)
+ 24 more |
|
0.13.5-rc.7
unknown
|
0.13.5-rc.7
unknown
Dependencies (33)
+ 25 more |
|
0.13.5-rc.6
unknown
|
0.13.5-rc.6
unknown
Dependencies (33)
+ 25 more |
|
0.13.1
unknown
|
0.13.1
unknown
Dependencies (32)
+ 24 more |
|
0.13.0
unknown
|
0.13.0
unknown
Dependencies (32)
+ 24 more |
|
0.12.2
unknown
|
0.12.2
unknown
Dependencies (32)
+ 24 more |
|
0.12.2-rc.1
unknown
|
0.12.2-rc.1
unknown
Dependencies (32)
+ 24 more |
|
0.12.1
unknown
|
0.12.1
unknown
Dependencies (32)
+ 24 more |
|
0.12.1-rc.1
unknown
|
0.12.1-rc.1
unknown
Dependencies (32)
+ 24 more |
|
0.12.0
unknown
|
0.12.0
unknown
Dependencies (32)
+ 24 more |
|
0.12.0-rc.2
unknown
|
0.12.0-rc.2
unknown
Dependencies (32)
+ 24 more |
|
0.12.0-rc.1
unknown
|
0.12.0-rc.1
unknown
Dependencies (32)
+ 24 more |
|
0.11.4-rc.28
unknown
|
0.11.4-rc.28
unknown
Dependencies (32)
+ 24 more |
|
0.11.4-alpha.0
unknown
|
0.11.4-alpha.0
unknown
Dependencies (32)
+ 24 more |
|
0.11.3-rc.5
unknown
|
0.11.3-rc.5
unknown
Dependencies (32)
+ 24 more |