VYPR
High severity8.2NVD Advisory· Published May 18, 2026· Updated May 18, 2026

TinyIce: Missing authentication on WebRTC ingest endpoint allows unauthorized stream injection

CVE-2026-45327

Description

Title

Missing authentication on WebRTC ingest endpoint allows unauthenticated stream injection in TinyIce

Ecosystem / Package

  • Ecosystem: Go (or "Other" — TinyIce is shipped as a Go binary, not a Go module published to a registry)
  • Package name: github.com/DatanoiseTV/tinyice

Affected versions

>= 0.8.95, <= 2.4.1

(Introduced 2026-02-21 in commit e2b60d6 — "debug: add Go Live connection tracing and backend data flow logging" — when handleWebRTCSourceOffer was registered at /webrtc/source-offer without an authentication check. Every tagged release from v0.8.95 through v2.4.1 ships the vulnerable handler.)

Patched versions

>= 2.5.0

Severity

Description

TinyIce's WebRTC source-ingest HTTP endpoint, POST /webrtc/source-offer?mount=, accepted any inbound WebRTC SDP offer with no authentication check. The handler routed the offer to WebRTCManager.HandleSourceOffer, which then accepted whatever audio/video tracks the peer published and broadcast them on the named mount as if they were the legitimate source.

The other ingest paths (POST / over HTTP/1 with the icecast SOURCE / PUT verb, RTMP, SRT) all require the per-mount source password, falling back to default_source_password from the config. The WebRTC ingest path didn't.

Impact

A network attacker who can reach the TinyIce HTTP port can:

  1. Identify a target mount (mount names are public — they appear in the directory listing, the player URL, and the YP listing).
  2. Negotiate a WebRTC peer connection with the server.
  3. Publish arbitrary Opus / H.264 to that mount.
  4. Have it broadcast to every listener on the mount.

This is a high-integrity-impact issue: an attacker can replace a radio's broadcast with their own audio (silence, noise, malicious content, branded competitor content, etc.). Listeners hear what the attacker sends, not what the legitimate publisher intended.

The legitimate publisher can re-establish their session — TinyIce's source-takeover handshake gives the new offer priority once it arrives, with a 3-second drain of the previous pump goroutine — but the attacker can in principle re-connect immediately after, producing a sustained broadcast hijack until the operator manually intervenes (block at firewall, rotate source passwords once the patch is applied, restart the service).

There is no direct confidentiality impact through this endpoint: the attacker doesn't gain access to listener data or other mounts' content.

Workarounds

If users cannot upgrade immediately:

  • Recommended: block POST /webrtc/source-offer at the reverse proxy in front of TinyIce. The endpoint has no production use case for clients outside the operator's own administration — disabling it loses no functionality unless the consuming application specifically use the browser-based "go-live" feature.
  • Restrict TinyIce's HTTP port to a trusted network (VPN, internal LAN). Listener access can still be served via a separately-firewalled CDN if the application needs public listening.

Detection

To check whether an application's deployment is exposed, run from outside the network:

curl -i -X POST 'https://your-tinyice-host/webrtc/source-offer?mount=/anymount' \
  -H 'Content-Type: application/json' \
  -d '{"type":"offer","sdp":"v=0\r\n"}'
  • If the response is 400 Bad Request with a JSON body containing an SDP-parsing error from pion/webrtc, a consuming application is vulnerable — the server tried to negotiate the (malformed) offer without asking for credentials.
  • If the response is 401 Unauthorized (Basic auth challenge), the consuming application has been patched.

Authenticated log lines on a patched server will look like:

WARN  Authentication failed for user 'webrtc-source' from 1.2.3.4: invalid source password

Fix

Upstream commit: `8067d6b` "fix(api): require source password on /webrtc/source-offer + CSRF/access on /go-live-chunk".

The handler now:

  1. Requires either HTTP Basic auth or a ?password= query parameter.
  2. Compares the supplied password against the per-mount source password (or the default_source_password fallback) using bcrypt.
  3. Hooks into the existing brute-force IP rate-limiter (5 failed attempts per IP within 15 minutes triggers a lockout).
  4. Rejects requests for mounts in disabled_mounts.

The same release also tightens an adjacent endpoint, POST /admin/golive/chunk, which previously required session authentication but did not verify the session user's per-mount access nor check the CSRF token.

Timeline

  • 2026-02-21 — Vulnerable handler introduced (e2b60d6).
  • 2026-05-09 — Vulnerability identified during a maintainer-led audit.
  • 2026-05-09 — Patched in commit 8067d6b, released as v2.5.0.
  • 2026-05-09 — GitHub Security Advisory published, CVE assigned.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Missing authentication on TinyIce's WebRTC ingest endpoint allows unauthenticated attackers to replace a mount's broadcast.

Vulnerability

The WebRTC source-ingest HTTP endpoint POST /webrtc/source-offer?mount= in TinyIce versions 0.8.95 through 2.4.1 accepts any inbound WebRTC SDP offer without authentication [1][2][3]. The handler handleWebRTCSourceOffer was introduced in commit e2b60d6 on 2026-02-21 and registered without an authentication check [2][3]. Unlike other ingest paths (POST / with HTTP SOURCE/PUT, RTMP, SRT), which require a per-mount source password or the default source password, the WebRTC endpoint completely omits credential validation [2][3].

Exploitation

An attacker who can reach the TinyIce HTTP port can: (1) identify a target mount name from public directory listings, player URLs, or YP listings; (2) negotiate a WebRTC peer connection with the server by sending a crafted SDP offer; and (3) publish arbitrary Opus or H.264 audio/video to that mount [2][3]. No authentication or user interaction is required; network access alone suffices [2].

Impact

Successful exploitation lets an attacker replace the legitimate source's broadcast on the targeted mount [2][3]. All listeners receive the attacker's content (silence, noise, malicious audio, branded competitor content, etc.) instead of the intended broadcast [2][3]. The legitimate publisher can re-establish their session, but the attacker can reconnect and repeat the hijack [2]. The result is a high integrity impact (CWE-306) with low availability impact (CVSS 7.4, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L) [2][3].

Mitigation

The vulnerability is fixed in TinyIce version 2.5.0 [2][3]. The commit 8067d6b added authentication gates using HTTP Basic auth or a password query parameter, matching the behavior of other ingest paths [4]. Users should upgrade to >= 2.5.0 immediately [2][3]. There is no known workaround for unpatched versions; disabling the WebRTC listener or restricting network access to the HTTP port are partial mitigations [1][4]. The CVE is not listed on CISA's KEV as of the publication date.

AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

1
8067d6b

fix(api): require source password on /webrtc/source-offer + CSRF/access on /go-live-chunk

https://github.com/DatanoiseTV/tinyiceDatanoiseTVMay 9, 2026via ghsa
1 file changed · +55 1
  • server/handlers_api.go+55 1 modified
    @@ -727,6 +727,44 @@ func (s *Server) handleWebRTCSourceOffer(w http.ResponseWriter, r *http.Request)
     		return
     	}
     
    +	// Auth gate. The icecast SOURCE / RTMP / SRT ingest paths all
    +	// require the per-mount source password (or DefaultSourcePassword)
    +	// before accepting a publish; this endpoint MUST do the same.
    +	// Without it, anyone on the internet who can POST here can hijack
    +	// any mount's broadcast — pion happily ingests whatever audio they
    +	// send, and tinyice broadcasts it to the radio's listeners.
    +	//
    +	// Accept the credentials via either Basic auth (matches handleSource)
    +	// or a `password` query parameter for browser callers that can't
    +	// always send Basic on a fetch().
    +	host, _, _ := net.SplitHostPort(r.RemoteAddr)
    +	if err := s.checkAuthLimit(host); err != nil {
    +		http.Error(w, "Unauthorized", http.StatusUnauthorized)
    +		return
    +	}
    +	requiredPass, found := s.getSourcePassword(mount)
    +	if !found {
    +		requiredPass = s.Config.DefaultSourcePassword
    +	}
    +	supplied := ""
    +	if _, p, ok := r.BasicAuth(); ok {
    +		supplied = p
    +	} else if q := r.URL.Query().Get("password"); q != "" {
    +		supplied = q
    +	}
    +	if requiredPass == "" || !config.CheckPasswordHash(supplied, requiredPass) {
    +		s.recordAuthFailure(host)
    +		s.logAuthFailed("webrtc-source", r.RemoteAddr, "invalid source password")
    +		http.Error(w, "Unauthorized", http.StatusUnauthorized)
    +		return
    +	}
    +	s.recordAuthSuccess(host)
    +
    +	if s.Config.DisabledMounts[mount] {
    +		http.Error(w, "Forbidden", http.StatusForbidden)
    +		return
    +	}
    +
     	var offer webrtc.SessionDescription
     	if err := json.NewDecoder(r.Body).Decode(&offer); err != nil {
     		http.Error(w, err.Error(), http.StatusBadRequest)
    @@ -774,17 +812,33 @@ func (s *Server) handleGoLiveChunk(w http.ResponseWriter, r *http.Request) {
     		http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
     		return
     	}
    +	// Block cross-origin form POSTs that could trick a logged-in admin's
    +	// browser into broadcasting attacker-supplied bytes. The handler
    +	// reads raw audio off r.Body, so the JSON Content-Type fast-path
    +	// in isCSRFSafe doesn't apply automatically — caller must include
    +	// the CSRF token.
    +	if !s.isCSRFSafe(r) {
    +		http.Error(w, "Forbidden", http.StatusForbidden)
    +		return
    +	}
     
     	mount := r.URL.Query().Get("mount")
     	if mount == "" {
     		http.Error(w, "mount query param required", http.StatusBadRequest)
     		return
     	}
     
    -	if _, ok := s.checkAuth(r); !ok {
    +	user, ok := s.checkAuth(r)
    +	if !ok {
     		http.Error(w, "Unauthorized", http.StatusUnauthorized)
     		return
     	}
    +	// Without this, any authenticated user could broadcast to any
    +	// mount — including mounts owned by other users.
    +	if !s.hasAccess(user, mount) {
    +		http.Error(w, "Forbidden", http.StatusForbidden)
    +		return
    +	}
     
     	body, err := io.ReadAll(r.Body)
     	if err != nil {
    

Vulnerability mechanics

Synthesis attempt was rejected by the grounding validator. Re-run pending.

References

4

News mentions

0

No linked articles in our index yet.