Latest News

Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11 fail to properly validate team membership permissions in the Add Channel Member API, which allows users from one team to access user metadata and channel membership information from other teams via the API endpoint.

A vulnerability exists in Keycloak's server distribution where enabling debug mode (--debug <port>) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (0.0.0.0). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine.

A fast-spreading threat, known as the screen-sharing scam, is using a simple feature on WhatsApp to steal money…

In 2025, employees are still using weak passwords. Instead of forcing an impossible change, security leaders are working around the problem.

### Impact This affects any Incus user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user. The most common case for this would be systems using `incus-user` with the less privileged `incus` group to provide unprivileged users with an isolated restricted access to Incus. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unpriivleged user on the host to gain root privileges. ### Patches A patch for this issue is available here: https://github.com/lxc/incus/pull/2642 The first commit changes the permissions for any new storage pool, the second commit applies it on startup to all existing storage pools. ### Workarounds Permissions can be manuall...

The EVE X1/X5 server suffers from multiple authenticated OS command injection vulnerabilities. This can be exploited to inject and execute arbitrary shell commands through multiple scripts affecting multiple parameters.

A vulnerability exists in Streamlabs Desktop where importing a crafted .overlay file can cause uncontrolled CPU consumption, leading to a denial-of-service condition. The .overlay file is an archive containing a config.json configuration. By inserting an excessively large string into the name attribute of a scene object within config.json, the application's renderer process (Frameworks/Streamlabs Desktop Helper (Renderer).app) spikes to over 150% CPU and becomes unresponsive. This forces the victim to terminate the application manually, resulting in loss of availability. An attacker could exploit this by distributing malicious overlay files to disrupt streaming operations.

Europol-led Operation Endgame seizes 1,025 servers and arrests a key suspect in Greece, disrupting three major global malware and hacking tools, including Rhadamanthys, VenomRAT and Elysium botnet.

### Impact _What kind of vulnerability is it? Who is impacted?_ An unauthenticated attacker can exploit this vulnerability to bypass all authentication mechanisms in the Milvus Proxy component, gaining full administrative access to the Milvus cluster. This grants the attacker the ability to read, modify, or delete data, and to perform privileged administrative operations such as database or collection management. All users running affected Milvus versions are strongly advised to upgrade immediately. ### Patches _Has the problem been patched? What versions should users upgrade to?_ This issue has been fixed in the following versions: • Milvus 2.4.24 • Milvus 2.5.21 • Milvus 2.6.5 Users should upgrade to these patched versions or later to mitigate the vulnerability. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ If immediate upgrade is not possible, a temporary mitigation can be applied by removing the sourceID header from all in...

### Summary When `Defaults targetpw` (or `Defaults rootpw`) is enabled, the password of the target account (or root account) instead of the invoking user is used for authentication. `sudo-rs` prior to 0.2.10 incorrectly recorded the invoking user’s UID instead of the authenticated-as user's UID in the authentication timestamp. Any later `sudo` invocation on the same terminal while the timestamp was still valid would use that timestamp, potentially bypassing new authentication even if the policy would have required it. ### Impact A highly-privileged user (able to run commands as other users, or as root, through sudo) who knows one password of an account they are allowed to run commands as, would be able to run commands as any other account the policy permits them to run commands for, even if they don't know the password for those accounts. A common instance of this would be that a user can still use their own password to run commands as root (the default behaviour of `sudo`), effectiv...