Skip to main content

Janus Gateway CVE-2026-108830

| EUVDEUVD-2026-97353 LOW
Race Condition (CWE-362)
2026-10-12 VulDB GHSA-r9x7-54rc-vq7h
1.3
CVSS 4.0 · Vendor: VulDB
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Join VideoRoom as authenticated participant
  2. Exploit
    Flood concurrent publish requests
  3. Execution
    Win race before started flag set
  4. Impact
    Exceed configured max_publishers limit

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires an authenticated VideoRoom participant (PR:L) able to send 'publish' requests, and the targeted room must have a max_publishers cap whose enforcement is the thing being subverted. The attacker must win a narrow timing window (CWE-362 race between the session 'starting' and 'started' states) to register as an active publisher before the count check applies - the patch introduces a 'starting' atomic flag so the limit counts in-progress publishers too. Limiting factors: high attack complexity (AC:H, vendor-stated 'difficult'), required low-privilege authenticated access to the room, relevance only to rooms that enforce a publisher limit, and minor impact (integrity/availability Low, no confidentiality). No network-unauthenticated path exists despite AV:N.

Impact

This is a genuinely LOW-priority issue, and the signals are internally consistent on that point. The CVSS 4.0 base score is only 2.3 with vector AV:N/AC:H/AT:N/PR:L/UI:N and impact limited to VI:L/VA:L (no confidentiality). AC:H plus the description's explicit 'exploitability is difficult' / 'complexity high' language reflects a timing-dependent race condition (CWE-362) that an attacker must win a narrow window to trigger. PR:L means some authenticated foothold (a valid VideoRoom participant able to send 'publish') is required - this is NOT remote-unauthenticated despite AV:N. A public reference is tagged 'exploit' (E:P / POC=YES), but that reference actually points at the upstream source file janus_videoroom.c rather than demonstrable weaponized exploit code, so the practical value of the 'POC' is questionable. The CVE is NOT in CISA KEV and no EPSS probability was supplied, so there is no evidence of real-world or automatable exploitation. CONFLICT TO NOTE: the input Tags list 'Information Disclosure', but the CVSS vector sets VC:N (no confidentiality impact) and the patch diff concerns enforcement of the max_publishers limit, not data exposure - the Information Disclosure label appears incorrect and should not drive triage. Net: a high-CVSS narrative is absent here; this is correctly a low-real-risk, difficult-to-exploit integrity/availability nuisance.

Exploit ScenarioDerived

An authenticated WebRTC participant who can send 'publish' requests to a janus-gateway VideoRoom rapidly issues concurrent publish attempts, racing the window between a session being 'starting' and fully 'started'. Because the pre-patch code only counted sessions already flagged 'started' when enforcing max_publishers, a winning race lets more publishers become active than the room's configured limit, degrading room integrity/availability. A public reference exists but is a link to upstream source rather than a turnkey exploit, and AC:H makes reliable triggering difficult.

Monitor Track and reassess. Why: LOW severity (CVSS 0.1-3.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 12, 2026

Authenticated participants of the Meetecho Janus Gateway VideoRoom plugin can bypass a room's max_publishers cap by winning a narrow timing race between a session's 'starting' and 'started' states, allowing more concurrent publishers in a room than the operator configured (CWE-362). The issue is a low-severity one: it requires an authenticated, low-privileged VideoRoom participant able to send 'publish' requests, only matters for rooms that actually enforce a publisher limit, and yields only Low integrity and Low availability impact with no confidentiality loss (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L; CVSS 4.0 base 2.3 with AC:H and E:P). Publicly available exploit code exists, but there is no confirmed active exploitation (not in CISA KEV), and the vendor responded quickly with an upstream fix in PR #3678 (commit 27c0d1af888153e818675b56a4e6267f62d57097).

RemediationAI

Apply the upstream fix by upgrading Janus Gateway past the affected 1.4.2 codebase once a release containing commit 27c0d1af888153e818675b56a4e6267f62d57097 (pull request https://github.com/meetecho/janus-gateway/pull/3678) is available; the vendor confirmed a fixed version was released, but the available data does not include an exact version tag, so patch status is best described as upstream fix available (PR/commit) with the released patched version not independently confirmed. If you build from source, cherry-pick that commit into your tree or apply the PR diff to src/plugins/janus_videoroom.c before recompiling, since the change is self-contained: it adds a 'starting' atomic flag to janus_videoroom_session and checks 'starting || started' when admitting publishers and counting active publishers. If immediate upgrade is not possible, compensate by controlling who may publish rather than trusting max_publishers as a security boundary - require authenticated room tokens or ACLs so only trusted participants reach the 'publish' path, and enforce publisher caps at your application/signaling layer or through external room provisioning, accepting that this adds latency and operational complexity and may break anonymous rooms; additionally, monitor room publisher counts for values above the configured maximum and alert on them, and do not rely on max_publishers as a capacity-protection control until patched. Note the race is timing-dependent and high complexity, so simple throttling of the publish path offers only partial mitigation with a trade-off in legitimate join latency.

Affected VersionsENISA

janus-gateway 1.4.1
janus-gateway 1.4.2
janus-gateway 1.4.0

Affected Packages

euvd janus_gateway no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The weakness is a classic time-of-check-to-time-of-use (TOCTOU) race condition (CWE-362) inside src/plugins/janus_videoroom.c, the VideoRoom plugin of the Janus WebRTC gateway. Janus tracks each VideoRoom session's publisher state with an atomic integer ('started') and, when a participant issues a 'publish' request, walks the room's participant list to count publishers that have 'started' in order to enforce the configured max_publishers cap. Because a participant is only marked 'started' after the publish path has already been admitted, two near-simultaneous publish requests (or a publish racing against the state transition of an existing session) can both pass the count check before either is reflected in the counter, letting the room exceed its configured publisher limit. The fix introduces a new 'volatile gint starting' field on janus_videoroom_session that is set atomically to 1 immediately before publisher registration is granted, is cleared on media setup, media hangup and the relevant synchronous request paths, and is included alongside 'started' in both the publish handler guard and the max_publishers counting loop; the error message was also reworded to 'Maximum number of active publishers'. The CPE record cpe:2.3:a:meetecho:janus-gateway:*:*:*:*:*:*:*:* is unfixed on a version wildcard, and the description scopes the affected code up to release 1.4.2.

Know when Webrtc gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulDB) PRIMARY 1.3 LOW
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
vuln.today AI 4.2 MEDIUM

Network-reachable but a timing race (AC:H) and a valid room participant (PR:L) are required; limit-bypass harms room integrity/availability (I:L/A:L) with no data exposure (C:N).

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L
4.0 AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (VulDB).

CVSS VectorVendor: VulDB

Attack Vector
Network
Attack Complexity
High
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
Low
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
CVSS changed
Oct 12, 2026 - 12:22 NVD
2.3 (LOW) 1.3 (LOW)
CVE Published
Oct 12, 2026 - 11:45 cve.org
LOW 2.3

DescriptionCVE.org

A weakness has been identified in meetecho janus-gateway up to 1.4.2. This affects an unknown part of the file src/plugins/janus_videoroom.c of the component VideoRoom. This manipulation causes race condition. Remote exploitation of the attack is possible. The attack's complexity is rated as high. It is indicated that the exploitability is difficult. The exploit has been made available to the public and could be used for attacks. Patch name: 27c0d1af888153e818675b56a4e6267f62d57097. Applying a patch is the recommended action to fix this issue. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

Threat Intelligence Overview

EPSS Score
0.2%
Top 92% exploitable
Prevalence
Medium
popular open-source WebRTC server, common in real-time-communication deployments but not universal
Exploit
POC
Public exploit code exists
Data Quality
7 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity LOW
CISA KEV No
Public POC Yes
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
LOW severity (CVSS 0.1-3.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
Poc
System Exposure· derived
Open
Automatable· derived
No
Human Impact· derived
Low

Priority Score

26
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +6
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy