CVE-2026-45327
Unauthenticated WebRTC Stream Injection in TinyIce
Publication date: 2026-06-05
Last updated on: 2026-06-05
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| datanoisetv | tinyice | From 0.8.95 (inc) to 2.4.1 (inc) |
| datanoisetv | tinyice | 2.5.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-306 | The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in TinyIce allows unauthenticated stream injection, which can lead to unauthorized modification of streaming content (integrity) and disruption of service (availability). While there is no direct confidentiality impact, the ability for an attacker to hijack streams could potentially violate compliance requirements related to data integrity and availability under standards like GDPR and HIPAA.
Specifically, GDPR and HIPAA emphasize protecting data integrity and availability to ensure trustworthiness and reliability of data processing systems. This vulnerability undermines these principles by allowing unauthorized users to inject arbitrary audio/video streams, potentially causing misinformation or service disruption.
Operators using affected versions should upgrade to version 2.5.0 or later, which enforces authentication and rate limiting, to mitigate risks and better align with compliance requirements.
Can you explain this vulnerability to me?
CVE-2026-45327 is a vulnerability in TinyIce, a Go-based WebRTC streaming server, affecting versions 0.8.95 through 2.4.1. The issue is that the WebRTC ingest endpoint (/webrtc/source-offer) lacks authentication, allowing any unauthenticated user to inject arbitrary audio or video streams into any mount point.
This means an attacker can connect to the server and publish their own audio/video streams, effectively hijacking the broadcast for all listeners on that mount. Although the legitimate source can regain control, attackers may quickly re-establish the hijack.
The vulnerability was fixed in version 2.5.0 by adding authentication via HTTP Basic auth or a password query parameter, integrating brute-force IP rate limiting, and rejecting requests for disabled mounts.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing attackers to hijack your audio or video streams on the TinyIce server without authentication.
- Attackers can inject arbitrary streams, replacing legitimate broadcasts and disrupting service availability.
- The integrity of your broadcast content is compromised since unauthorized content can be streamed to your audience.
- Although confidentiality is not directly affected, the disruption and manipulation of streams can cause significant operational and reputational damage.
Mitigation involves upgrading to version 2.5.0 or later, which enforces authentication and rate limiting to prevent unauthorized stream injection.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing the WebRTC ingest endpoint with a crafted request. A vulnerable TinyIce server will accept a request to the /webrtc/source-offer endpoint without requiring authentication, while a patched server will respond with a 401 Unauthorized error.
For example, you can use a command like the following to test the endpoint:
- curl -X POST "http://<server-address>/webrtc/source-offer?mount=<mount>" -d '<SDP payload>' -v
If the server accepts the request without authentication, it is vulnerable. If it responds with 401 Unauthorized, it is patched.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading TinyIce to version 2.5.0 or later, which fixes the vulnerability by adding authentication requirements on the WebRTC ingest endpoint.
Additionally, you should rotate per-mount source passwords to prevent unauthorized access using previously compromised credentials.
As a temporary workaround before upgrading, you can block access to the vulnerable endpoint (/webrtc/source-offer) at a reverse proxy or firewall, or restrict access to trusted networks only.