GHSA-hmgp-w9jm-vp95 Subsonic API: any authenticated user can delete or read any other user's playlist (IDOR)
SummaryIn gonic, the Subsonic API endpoints `/rest/deletePlaylist.view` and `/rest/getPlaylist.view` perform no per-resource authorization. Once authenticated as *any* user (admin or not), an attacker can:**Delete any playlist owned by any other user** (including admin) by passing its `id`.**Read the full contents** (name, comment, song list) of any other user's **private** (non-public) playlist by passing its `id`.The Subsonic playlist `id` is `base64url("<userID>/<filename>.m3u")`. Because filenames are user-supplied or time-derived and the `userID` is a small integer, IDs are guessable and frequently exposed (e.g. a previously-public playlist that was later made private still has the same ID).This breaks the multi-user trust boundary of gonic: a low-privileged user can wipe an administrator's curated playlists, and a user can exfiltrate any private playlist they obtain an ID for.StatusThis was originally disclosed to the maintainer by email and has been **fixed in commit `6dd71e6a3c966867ef8c900d359a7df75789f410`** (`fix(subsonic): enforce playlist ownership on getPlaylist/deletePlaylist`, 2026-05-18). The fix has not yet been included in a tagged release; the latest tagged version `v0.20.1` is still vulnerable. Filing this advisory now that private vulnerability reporting is enabled on the repo, so the issue has a public record once the next release ships.Vulnerable code (pre-fix, at `v0.20.1` / commit `37090aa7`)**Delete IDOR** — `server/ctrlsubsonic/handlers_playlist.go` lines 177-187:The handler never loads the playlist to check `playlist.UserID == user.ID`. Compare to `ServeUpdatePlaylist` (same file, line 138) which *does* perform this check.**Read IDOR** — `server/ctrlsubsonic/handlers_playlist.go` lines 51-68:The listing endpoint `ServeGetPlaylists` (line 38) correctly filters by `playlist.UserID != user.ID && !playlist.IsPublic`, but the singular `getPlaylist` did not.Live PoC (passing Go test)A reproducer against the existing test fixture (`server/ctrlsubsonic`):Test output:Equivalent HTTP requestResponse: `{"subsonic-response":{"status":"ok","version":"..."}}` — playlist is gone.Impact**Integrity / Availability**: low-privileged users can delete any other user's playlists, including admin's curated lists. There is no undo.**Confidentiality**: private playlists (including their comment fields) are readable by any authenticated user with an ID. IDs are predictable (`base64("<smallUserID>/<name>.m3u")`) and previously-public IDs persist after being marked private.**Trust boundary**: gonic supports multiple users (`createUser`, non-admin role). This bug collapsed the user-to-user authorization model.Affected versionsLatest tagged release `v0.20.1` and all prior versions back to when the playlist M3U store was introduced. Master HEAD is fixed at commit `6dd71e6a3c966867ef8c900d359a7df75789f410`.Suggested patch (applied by maintainer in `6dd71e6`)Load the playlist first and enforce ownership in both handlers:This mirrors the existing ownership check already present in `ServeCreateOrUpdatePlaylist` (line 84) and `ServeUpdatePlaylist` (line 138).CreditsReported by Vishal Shukla ([@shukla304](https://github.com/shukla304) / [@therawdev](https://github.com/therawdev)).
CVSS v3.1 score: 7.1