Loading story…
RustFS disclosed and fixed CVE-2026-73284, an improper privilege management flaw in the AddServiceAccount handler that could let an authenticated low-privilege user create a service account tied to the root credential. The vulnerable logic checked only CreateServiceAccountAdminAction and accepted an attacker-controlled target_user, which was then passed into service-account creation without confirming that the requested parent account was within the caller’s scope. RustFS said the resulting account could be marked as owner-authenticated through prepare_service_account_auth, creating a path to full compromise of confidentiality, integrity, and availability.
The issue is tracked as GHSA-5354 and carries a CVSS 3.1 score of 9.1 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Maintainers addressed the bug in RustFS 1.0.0-beta.11 by adding scope enforcement so non-owners can create service accounts only for themselves or, when using derived credentials, for their own parent account, while owners retain broader cross-user creation rights. The project also merged regression tests covering both the original non-owner abuse case and derived-credential attack scenarios to prevent the authorization bypass from reappearing.
Get the actors, campaigns, and ATT&CK mapping behind it.
2 events from the most recent confirmed update back to the earliest known activity.
The CVE record for the RustFS privilege-management flaw was received by security-advisories@github.com. The issue describes how AddServiceAccount could be abused to create a root-parent service account that authenticates as the owner.
RustFS merged pull request #5141 as commit 9866f68, fixing improper authorization in AddServiceAccount by enforcing that non-owners can create service accounts only within their own scope. The change also added regression testing for the issue tracked as GHSA-5354-r3w2-34m8.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
2 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A critical vulnerability, tracked as CVE-2025-68926, was discovered in the RustFS distributed object storage system. The flaw involves the use of a hardcoded static token (`"rustfs rpc"`) for gRPC authentication, which is publicly exposed in the source code and is non-configurable, with no mechanism for token rotation. This token is valid across all RustFS deployments prior to version 1.0.0-alpha.77, allowing any attacker with network access to the gRPC port to authenticate and perform privileged operations such as data destruction, policy manipulation, and cluster configuration changes. The issue has been addressed in version 1.0.0-alpha.77, which removes the hardcoded credential and implements proper authentication controls. Security researchers have rated this vulnerability as critical, assigning it a CVSS score of 9.8 due to the ease of exploitation and the potential impact on data integrity and availability. Organizations using affected versions of RustFS are strongly advised to upgrade to the patched release immediately to mitigate the risk of unauthorized access and potential compromise of storage clusters. No evidence of exploitation in the wild has been reported as of the latest advisories, but the public nature of the token significantly increases the risk of opportunistic attacks.
Jun 29, 2026
RustDesk addressed **CVE-2026-57850** in version **1.4.9**, fixing a server-side authorization flaw that let an authenticated peer in a limited session send control messages and login options intended only for a full Remote session. The vulnerability affects versions before `1.4.9` and could allow an attacker with low privileges to exceed the permissions granted for session types such as FileTransfer, PortForward, ViewCamera, or Terminal, potentially gaining broader visibility or control over the host. The issue is tracked as **CWE-862** and carries a high-severity **CVSS 3.1** score with vector `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L`. The fix was introduced through pull request **#15469** and commit `493b14ba78abc3dfb33f109c7f93c1c95a1dabc4`, which enforce session-scoped permissions across authenticated connection types and block out-of-scope login, option, and control messages. RustDesk also added auditing and explicit close reasons for scoped-session violations, limited clipboard synchronization and screenshot handling to appropriate contexts, and prevented actions such as privacy mode or virtual display changes in view-camera sessions. The security changes were shipped as part of the broader **1.4.9** release.
Jul 11, 2026
Two critical hardcoded-secret weaknesses were disclosed in widely used open-source infrastructure components, enabling attackers to bypass authentication and obtain administrative control when exposed or left at insecure defaults. In **RustFS** (an object storage platform often used for backups, logs, and operational data), **CVE-2025-68926** (CVSS 9.8) stems from a *non-rotatable static authentication token* embedded in source code on both client and server sides; an attacker with access to the exposed **gRPC management port** can use the known token to bypass authentication and gain admin access, creating risk of data integrity loss and service disruption. In **Open5GS** (an open-source 5G core implementation), **CVE-2026-0622** affects the optional *WebUI* management interface and arises from default **hardcoded cryptographic secrets** used for **JWT signing**. If operators do not change the default environment variables (reportedly set to `change-me`), an attacker can forge valid JWTs, impersonate an administrator, and gain full WebUI privileges—potentially including configuration and subscriber-data management—while also bypassing controls that rely on authenticated context (e.g., CSRF protections).
Jun 29, 2026