Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/m1k1o/neko/server >= 0.0.0-20250401220545-fe94c999c6af, < 0.0.0-20260805142851-395ca1a6f62b
Fixed in
0.0.0-20260805142851-395ca1a6f62b· Vendor fix available
Issue
Impact When legacy mode is enabled and `session.implicit_hosting` 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…
Recommended action: Upgrade to 0.0.0-20260805142851-395ca1a6f62b (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/m1k1o/neko/server >= 3.0.0, < 3.0.11; >= 0.0.0-20250322225643-212bf8a60756, < 0.0.0-20260406184107-c54bcf1ee211
Fixed in
3.0.110.0.0-20260406184107-c54bcf1ee211· Vendor fix available
Issue
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…
Recommended action: Upgrade to 3.0.11 or 0.0.0-20260406184107-c54bcf1ee211 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.