Impact
When legacy mode is enabled and session.implicithosting is enabled, the legacy WebRTC data channel incorrectly authorizes input events due to a logic error in LegacyIsHost().
As a result, an authenticated room member may be able to send mouse and keyboard input through the legacy WebRTC control channel even when controls are locked or the member would otherwise not be authorized through the modern control API.
The issue affects only the legacy WebRTC input path. The modern HTTP/WebSocket control path correctly enforces authorization checks and is not affected.
To exploit this issue, an attacker must:
Be authenticated as a room member. Successfully establish a WebRTC connection. Access a deployment using the legacy WebRTC input handler.
No unauthenticated access or privilege escalation outside the application is possible.
Patches
The issue has been fixed in v3.1.5 by correcting the authorization logic in the legacy WebRTC handler.
Users should upgrade to v3.1.5 or later. Fix: 395ca1a
Workarounds
Users who cannot immediately upgrade can mitigate the issue by one of the following:
Disable legacy mode if it is not required. Disable implicit hosting (session.implicithosting=false). Restrict access to trusted authenticated users.
Credits
Thanks to @KasperBuilds for responsibly disclosing this vulnerability and reaching out directly. This contribution helped strengthen the project, and the whole community benefits from it.
Impact
Any authenticated user can immediately obtain full administrative control of the entire Neko instance (member management, room settings, broadcast control, session termination, etc.). This results in a complete compromise of the instance.
Patches
The vulnerability has been patched in the following releases:
- v3.0.11 (backport release) - v3.1.2 (latest stable release)
Users should upgrade to v3.0.11 or later (for the 3.0 branch) or v3.1.2 or later.
Workarounds
If upgrading is not immediately possible, the following mitigations can reduce risk:
- Restrict access to trusted users only (avoid granting accounts to untrusted parties) - Run the instance only when needed; avoid leaving it continuously exposed - Disable or restrict access to the /api/profile endpoint if feasible - Monitor for suspicious privilege changes or unexpected administrative actions
Note: These are temporary mitigations and do not fully eliminate the vulnerability. Upgrading is strongly recommended.
Credits Neko thanks @blitzkrieg-patch for responsibly disclosing this vulnerability and reaching out directly. This contribution helped strengthen the project, and the whole community benefits from it.