Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In 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: 1. Delete any playlist owned by any other user (including admin) by passing its id. 2. 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. Status This was originally disclosed to the maintainer by email and has been fixed in commit…
Recommended action: Upgrade to 0.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The maintainer's recent fix in 6dd71e6a3c966867ef8c900d359a7df75789f410 (fix(subsonic): enforce playlist ownership on getPlaylist/deletePlaylist) added an ownership check based on playlist.UserID. However, playlist.UserID is derived from the first path segment of the attacker-controlled playlist ID, with no path containment on the resolved file path. Any authenticated Subsonic user can therefore bypass the ownership check and: 1. Read any other user's playlist (name, comment, IsPublic flag, song list) by crafting a base64-encoded playlist ID whose first segment matches their own user ID, followed by .. traversal segments pointing into another user's playlist directory. 2. Delete any other user's playlist (including admin's curated playlists) by the same trick against deletePlaylist. 3. Probe arbitrary file paths on the host for existence/readability. This is a bypass of the boundary the 6dd71e6 fix is trying to enforce; it is closely related to the original GONIC-1 IDOR but…
Recommended action: Upgrade to 0.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A logic error in ServeCreateOrUpdatePlaylist allows any authenticated Subsonic user (including non-admin) to write playlist M3U content to an attacker-controlled absolute filesystem path on the gonic host, and to create intermediate directories with 0o777 permissions. The bug is independent of the playlist ownership IDOR fixed in 6dd71e6: it is an unreachable guard clause combined with no path containment in Store.Write. Root cause — unreachable guard clause server/ctrlsubsonic/handlersplaylist.go:74-90: playlist.Store.Read (playlist/playlist.go:88-144) returns either (Playlist, nil) on success or (nil, err) on any failure path. There is no return path of (non-nil, non-nil-err). So the inner branch err != nil && pl != nil is always false, the playlist = pl assignment never executes, and playlist stays at its zero value with UserID = 0. The subsequent guard playlist.UserID != 0 && playlist.UserID != user.ID simplifies to false && (anything) and always passes, regardless of who…
Recommended action: Upgrade to 0.21.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.