Most recent entries from all

EUVD-2026-325120

fkie_cve-2026-45327

TinyIce is a streaming server for audio and video. In versions 0.8.95 through 2.4.1, missing authentication on WebRTC ingest endpoint allows unauthenticated stream injection. Version 2.5.0 fixes the issue by requiring either HTTP Basic auth or a `?password=` query parameter, comparing the supplied password against the per-mount source password (or the `default_source_password` fallback) using bcrypt, hooking into the existing brute-force IP rate-limiter (5 failed attempts per IP within 15 minutes triggers a lockout), and rejecting 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.

GHSA-p7c4-8x34-8j8f — TinyIce: Missing authentication on WebRTC ingest endpoint allows unauthorized stream injection

Affected: Go: github.com/DatanoiseTV/tinyice

## 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

- **CVSS 3.1 base score:** 7.4 (High) - **CVSS vector:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L` - **CWE:** [CWE-306: Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html)

## Description

TinyIce's WebRTC source-ingest HTTP endpoint, `POST /webrtc/source-offer?mount=<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 /<mount>` over HTTP/1 with the icecast `SOURCE` / `PUT` verb, RTMP, SRT) all require the per-mount source password, falling back to `default_source_pass…