AzuraCast CVE-2026-121427

Requires an authenticated AzuraCast account that holds the 'Manage station profile' permission but lacks 'Manage station broadcasting', operating on a station configured with the shoutcast2 frontend type (plain 'shoutcast' 500s by design; Icecast/other frontends are not the sink). The injected frontend_config.custom_config only materializes into the live sc_serv.conf when the station/frontend is restarted - in the PoC this restart is triggered by an admin. Limiting factors: a valid low-privilege station account is mandatory, the target station must use the Shoutcast frontend, and a frontend restart must occur; observed impact is confined to sc_serv.conf key=value semantics (adminpassword/password/portbase override and arbitrary-directive injection), with actual Shoutcast daemon execution unverified because the binary is absent from stock images.

The CVSS 4.0 base score is 8.7 (High) with the supplied vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H. However, that vector is internally inconsistent with the authoritative evidence: the GHSA advisory and the description both state the flaw requires an authenticated user who holds the 'Manage station profile' permission, which means privileges are genuinely required (PR:L), not PR:N. This single discrepancy materially changes the real-world picture - this is not an anonymous internet-wide attack but an authenticated authorization-boundary break (CWE-862 missing authorization / CWE-15 external control of config). There is no CISA KEV listing and no EPSS score was provided, so there is no signal of active or probabilistically-likely mass exploitation. A complete, runnable proof-of-concept exploit script is published directly in the vendor GHSA advisory against the exact verified commit (ebf75a2), so exploit knowledge is fully public. The vuln.today decision label is 'this_week' (not act_now/emergency). Net assessment: a credible, well-documented privilege-escalation / station-isolation vulnerability with public exploit code, but gated behind holding a valid low-privilege station account - a real priority for multi-tenant AzuraCast operators rather than a wormable, unauthenticated internet threat. The vendor reports it is not yet patched, which raises urgency for exposed multi-user deployments.

An attacker holding a low-privilege AzuraCast account with only 'Manage station profile' (and not 'Manage station broadcasting') on a Shoutcast-fronted station sends a crafted PUT to /station/{id}/profile/edit embedding malicious JSON in frontend_config.custom_config. Because that field is never stripped for non-Broadcasting users, on the next frontend restart the JSON is written verbatim into sc_serv.conf, letting the attacker override adminpassword/password/portbase and inject arbitrary directives via newline-containing keys to hijack the station's Shoutcast frontend. A complete runnable PoC script is published in the vendor GHSA advisory.