One Login, Full Filesystem Access
Gonic, a popular open-source Go implementation of the Subsonic music server API, contains an arbitrary file write vulnerability in its createPlaylist endpoint. Any authenticated user — not an admin, not a privileged account, just anyone with valid credentials — can write files to arbitrary paths on the host filesystem. The vulnerability exists because the endpoint accepts user-supplied file paths without sanitization or scope restriction.
The mechanics are straightforward. The createPlaylist API takes a file path parameter to define where playlist data is stored. Gonic validates that the request comes from an authenticated session but performs no authorization check on what that session is allowed to do. A path traversal payload in the playlist filename resolves against the server's filesystem root, not the application's data directory.
The Authentication-Not-Authorization Pattern
This vulnerability is not an isolated implementation mistake. It represents a structural pattern WebPulse has tracked across self-hosted applications: authentication as the sole security boundary. The application answers the question 'who are you?' but never asks 'what are you allowed to do?' When every authenticated user has equivalent privileges, a single compromised or malicious account inherits the permissions of the host operating system.
The pattern appears with disproportionate frequency in Go-based self-hosted tools. Many are written by solo developers or small teams who implement authentication correctly — bcrypt password hashing, session token management, HTTPS enforcement — then treat the authenticated context as uniformly trusted. The Subsonic API specification itself lacks granular permission scoping, which means implementations that faithfully follow the spec inherit its authorization blindspots.
Self-Hosted Means Self-Responsible
The appeal of self-hosted applications is control. Organizations deploy gonic, Nextcloud, Gitea, and dozens of similar tools precisely because they want to own the infrastructure. But ownership without authorization modeling means the attack surface is the entire server. An arbitrary file write in a music server becomes a mechanism for crontab injection, SSH key planting, or web shell deployment — none of which have anything to do with music.
WebPulse detection data across 466,000 scanned sites shows self-hosted application fingerprints increasing in enterprise environments. The same organizations migrating away from WordPress for its 18,005 CVEs are deploying self-hosted alternatives that lack the security review infrastructure WordPress has accumulated over two decades. The vulnerability count is lower because the audit count is lower.
What This Means for Infrastructure Decisions
For organizations evaluating self-hosted deployments, the gonic disclosure surfaces a concrete due-diligence question: does this application implement authorization, or just authentication? A login screen is not a security model. The presence of user accounts does not imply the presence of access controls. And the Subsonic API ecosystem — gonic, Navidrome, Airsonic — shares this architectural assumption across implementations.
The remediation path for gonic users is to run the application in a containerized environment with a read-only filesystem mount for music directories, restrict the writable path to a dedicated data volume, and monitor for file creation outside expected directories. But the broader lesson is structural: before deploying any self-hosted application to production infrastructure, audit whether its security model extends beyond the login page.
