Currently browsing: Technology

Overview
Dokploy versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch, are vulnerable to OS command injection during the backup creation and restoration processes. The vulnerability stems from unsanitized shell command construction that can allow an attacker to escalate privileges and lead to full compromise of the target device.
Description
Dokploy is an open-source Platform as a Service solution for deploying applications and databases on self-hosted servers. Dokploy allows authenticated users to create and schedule database backups and restore previously created backups. These backup operations are executed by the Dokploy process, which runs with root privileges by default.
Dokploy is vulnerable to OS command injection in its database backup creation and restoration functionality due to insufficient sanitization of user-controlled input before it is incorporated into shell commands. The vulnerable backup functionality constructs database-specific shell commands that directly interpolate a user-supplied database name, while the restore functionality incorporates a user-supplied backupFile value into a shell command. Both operations ultimately pass the resulting command to a shell execution helper that invokes /bin/bash as a child of the Dokploy process, without shell escaping or restrictions on shell metacharacters.
The affected parameters are exposed through tRPC procedures that only validate that the supplied values are non-empty strings. Consequently, authenticated users with permission to perform database backups can supply shell metacharacters that are interpreted by /bin/bash, resulting in arbitrary command execution on the Dokploy host with the root privileges of the Dokploy server process.
Impact
An attacker with authenticated Dokploy account with backup permission (granted by default for database services) can execute arbitrary commands as root (default configuration) on the Dokploy host. Successful exploitation provides full control of the host, including persistent read/write access to the target server’s filesystem and the ability to steal private credentials stored for other tenants managed by the same Dokploy instance.
The vulnerability affects all five database types supported by Dokploy: PostgreSQL, MySQL, MariaDB, MongoDB, and LibSQL. Exploitation was confirmed against versions 0.29.8 and 0.29.11, as well as commit 24b02f5 on the canary branch available on GitHub.
Solution
Unfortunately, Dokploy could not be reached to coordinate this vulnerability; however, the issue has been patched in Dokploy versions 0.29.13 and beyond. The CERT/CC recommends users update immediately. Database administrators or general operators unable to update should mitigate potential attacks by turning off default backup permissions, and restricting these permissions only to necessary users and roles.
Acknowledgements
Thanks to Muhammadjon Ahmadjonov for reporting this vulnerability. This document was written by Alex Lewis.

Overview
A vulnerability in MLflow’s dspy and statsmodels model flavors allows unauthorized pickle deserialization executions despite a safety control. Specifically, the dspy flavor conditionally applies the control based on the model path’s file extension, and the statsmodels flavor does not apply the control.
Description
MLflow is an open-source platform for managing machine learning lifecycles, including model packaging, versioning, and deployment. “Flavors” refer to the specialized frameworks through which supported models are stored and loaded. In response to previous vulnerability concerns, MLflow implemented the MLFLOW_ALLOW_PICKLE_DESERIALIZATION safety control to block and disable executing any pickle deserialization and subsequent loads per the user’s choice.
When loading models through mlflow.pyfunc.load_model(model), users must specify a model flavor and path in an MLmodel file. With the dspy flavor, MLflow checks the value of MLFLOW_ALLOW_PICKLE_DESERIALIZATION, and whether the specified model path ends in .pkl. A model path that does not end in .pkl (even if the file is actually a pickle file), will route to a separate branch for pickle deserialization, bypassing the safety control. However, when loading through the statsmodels flavor, there is no check for MLFLOW_ALLOW_PICKLE_DESERIALIZATION at all.
Impact
Exploitation of this vulnerability allows for arbitrary remote code execution through a malicious pickle-loaded payload, regardless of a user explicitly disallowing pickle serialization, through vulnerable flavor specifications in the MLmodel configuration file. The attack path requires write access to any location from which a user obtains MLflow models. This vulnerability was confirmed against MLflow 3.12.0.
Solution
MLFlow could not be reached to coordinate this vulnerability; however, the statsmodels flavor was patched in versions >= 3.15.0. Users should upgrade immediately. Until a further fix remedying the dspy flavor vulnerability is available, MLflow users who wish to block pickle deserialization and loads should avoid loading any models via the dspy flavor.
Acknowledgements
Thanks to Prasanna Dabi for reporting this vulnerability. This document was written by Alex Lewis.

Overview
A vulnerability exists in Sentry Seer when the system is configured to automatically hand issues to a coding agent for remediation. Successful exploitation results in arbitrary code execution within the coding‑agent environment and access to connected source repositories. This vulnerability is tracked as CVE-2026-90999.
Description
Sentry is a software error‑monitoring and performance‑tracking platform used by developers to detect, diagnose, and understand issues in their applications. It collects telemetry such as exceptions, stack traces, logs, and performance data from applications. Built into Sentry, Seer acts as an automated debugging assistant that converts telemetry into actionable remediation steps and can hand off issues to an integrated coding agent to propose code fixes.
Because Sentry front-end projects commonly expose a public DSN (Data Source Name) to allow browsers to submit this telemetry, an attacker can craft and submit malicious events through this public endpoint. When Seer is enabled to automatically pass issues to a coding agent, these attacker-supplied events can traverse multiple trust boundaries. Ultimately, malicious event fields propagate through Seer’s analysis pipeline, transforming into untrusted instructions that the privileged coding agent may execute.
The vulnerable workflow is as follows:
* Sentry ingests attacker‑generated exception events submitted through the public DSN.
* Seer evaluates whether the event represents an issue eligible for automated remediation.
* Seer generates a root‑cause analysis that uses attacker-controlled event fields, including exception messages, stack traces, source context, and breadcrumbs.
* The generated analysis is embedded directly into the initial prompt provided to the coding agent.
* The coding agent interprets the fabricated analysis as a legitimate description of the victim’s codebase.
* During its investigation, the coding agent downloads and executes a package controlled by the attacker.
* The package executes within the coding‑agent environment prior to any human review of a pull request.
Impact
Successful exploitation may allow arbitrary code execution in the coding‑agent environment that processes the affected repository.
Solution
At the time of this writing, no vendor‑supplied patch information has been provided. Mitigations may include disabling automated remediation flows, restricting coding‑agent package installation, or disabling Seer handoff until a fix is available. Additional defensive filtering of telemetry content before Seer analysis may also reduce risk.
Acknowledgements
Thank you to Nikita Benkovich and Vitalii Valkov, agyn for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
An out-of-bounds (OOB) memory access vulnerability involving unchecked array indexing has been identified in the exllamav3_ext compute unified device architecture (CUDA) extension. Successful exploitation can lead to an immediate denial of service or application instability. This vulnerability is tracked as CVE-2026-84286.
Description
An OOB memory access vulnerability exists in the exllamav3_ext module due to insufficient input validation.
When the kernel parameter K is set to 0 in a crafted input, the extension generates a negative array index, resulting in a CUDA illegal memory access.s. The root cause is a missing bounds check in the kernel-table dispatch process. The checkpoint-derived block index (cbi) is used to access a fixed 24-entry array without confirming that either K or cbi fall within safe limits.
Impact
Primary impacts include Denial of Service (DoS) through process crashes and potential unstable execution states within applications utilizing the library.
Solution
The vendor has addressed this vulnerability in the main repository. Users are advised to update their installations or apply the fix from the merged pull request: https://github.com/turboderp-org/exllamav3/pull/310.
Supply chain
Downstream projects utilizing this library are indirectly exposed to this vulnerability. According to the ExLlamaV3 Dependency Graph, there are 49 total dependencies currently tracking this repository. Notable downstream projects directly affected by this supply chain link include: UnstableLlama / ezexl3 and Ednaordinary / MawDiscord
Developers and maintainers of these dependent repositories are strongly encouraged to rebuild their packages against the patched version of exllamav3_ext.
Acknowledgements
The CERT Coordination Center (CERT/CC) thanks Nathan Keys (professor-moody) for discovering and responsibly reporting this vulnerability.
This AI-assisted vulnerability note was prepared by Laurie Tyzenhaus.

Overview
An incorrect permissions assignment vulnerability in the amwrtdrv.sys kernel driver, included with AOMEI Backupper 8.4.0, allows an unprivileged local user to perform arbitrary writes to the physical disk. When Secure Boot is disabled, this can be leveraged to execute arbitrary UEFI-level code before the operating system loads. This allows an attacker to bypass OS-level security controls, including HVCI, EDR solutions, and Microsoft Defender. The attack may also enable capture of BitLocker Volume Master Key (VMK) material, depending on the system’s BitLocker configuration.
Description
AOMEI Backupper from AOMEI International Network Limited is designed to provide backup and disaster recovery services. It also helps individuals and businesses to create system images, disk clones, and file backups. AOMEI Backupper is available as a Windows application and can be integrated into enterprise backup workflows or directly used by end users.
CVE-2026-12780: An Incorrect Permission Assignment for Critical Resource (CWE-732) vulnerability in the amwrtdrv.sys kernel driver used by AOMEI Backupper 8.4.0 allows an unprivileged local attacker to achieve UEFI-level arbitrary code execution by directly writing to physical disk devices. The driver creates a world-accessible device object without a security descriptor, therefore allowing any user-mode process to open the device and issue unrestricted write requests. Hence, an attacker can modify disk sectors in the pre-partition gap (LBA 34–2047), inject a malicious UEFI payload, and alter the GPT to reference the payload as an EFI System Partition. The payload can then execute during the UEFI Boot Device Selection (BDS) phase, before operating system security mechanisms are loaded.
Impact
An attacker with unprivileged local access to a system running AOMEI Backupper 8.4.0 can exploit this vulnerability by opening the world-accessible \.mwrtdrvDISK0 device object and sending specially crafted write commands to an arbitrary physical disk. When Secure Boot is disabled, a successful exploitation allows the attacker to inject UEFI code that executes before the Windows kernel loads, completely bypassing kernel-mode security features including Hyper-V Code Integrity (HVCI), Endpoint Detection and Response (EDR) solutions, Windows Defender, and Hyper-V isolation. On systems using BitLocker with TPM-only protection, this attack vector enables evil maid attacks whereby VMK credentials can be captured during the pre-boot phase Boot Device Selection (BDS) phase.
Solution
Please see the Vendor Information section for patches provided by AOMEI International Network Limited to address this issue. CERT/CC recommends that AOMEI Backupper users update to a version that includes the corrected amwrtdrv.sys driver and implements appropriate access controls.
Users who cannot immediately apply the available update should consider uninstalling AOMEI Backupper. Alternatively, users may disable the amwrtdrv.sys service by changing its start type from AUTO_START to disabled. Enabling Secure Boot in UEFI firmware settings provides additional defense in depth by requiring signed bootloaders, but it does not address the underlying driver vulnerability.
Acknowledgements
Thank you to SiCk / afflicted.sh for reporting this vulnerability. This document was written by Vijay Sarvepalli.

Overview
The UEFI Shell program may expose raw memory access capabilities that, if present in platform firmware for debugging or advanced support use cases, could be abused to undermine UEFI Secure Boot protections. When the UEFI Shell is included in SPI flash, an attacker with the ability to modify UEFI boot configuration may be able to create multiple boot option entries and bypass controls intended to prevent the UEFI Shell from launching while Secure Boot is enabled. This could allow an attacker to modify the pre-boot environment and execute unauthorized software during system startup.
Description
The Unified Extensible Firmware Interface (UEFI) is a firmware specification that defines the interface between a computing platform’s hardware and operating system (OS) during the early boot process before the operating system is loaded. UEFI Secure Boot helps ensure that only trusted and digitally signed software is executed during these early stages of platform initialization.
The TianoCore EDK II project provides an open-source reference implementation of the UEFI and Platform Initialization (PI) specifications. The project includes the UEFI Shell, which provides command-line utilities for debugging, diagnostics, and advanced platform management. Many OEM and Independent BIOS Vendor (IBV) firmware implementations include the UEFI Shell in SPI flash for service and support purposes. Because the shell executes in the pre-boot environment, it provides powerful commands such as dmem (display memory) and mm (memory modify) that can access physical memory. Many implementations include a boot entry for the UEFI Shell but remove or suppress it when Secure Boot is enabled to reduce the risk of misuse.
A vulnerability disclosed by Eclypsium researcher Stas Lyakhov details a technique in which an attacker with the ability to create additional UEFI boot entries can reference the UEFI Shell even when standard controls are implemented to prevent its execution. An attacker could then exploit the UEFI Shell and its startup scripting capabilities to modify the pre-boot environment, including overwriting Secure Boot-related memory values, and execute unauthorized code during the early boot process.
Impact
An attacker capable of modifying UEFI boot entries may be able to circumvent intended Secure Boot protections and execute arbitrary code before the operating system loads. Code executed during the pre-boot phase may establish persistent access, including the ability to load malicious boot components or kernel-level software that can survive both system reboots and, in some cases, reinstallation of the operating system. Such activity may also reduce the effectiveness of OS-based security controls and endpoint detection and response (EDR) solutions.
Solution
Apply a Patch
Please see the Vendor Information section for responses from vendors that have released updates addressing this issue. Updating UEFI firmware may require OEM-specific tools and deployment processes, as firmware updates are often managed separately from operating system patch management. Follow the guidance provided by your platform vendor when applying firmware updates.
Recommendations for Enterprises
Organizations should review Secure Boot configuration and platform security policies to help prevent or detect unauthorized modifications to UEFI boot entries. Changes to boot configuration should be monitored and audited where possible. Enterprises that use independent endpoint management solutions should consult their OEM vendors for guidance on integrating UEFI firmware updates into their existing firmware lifecycle and patch management processes.
Acknowledgements
Thanks to Stas Lyakhov from Eclypsium for reporting this vulnerability. This document was written by Vijay Sarvepalli.

Overview
Skullcandy Dime 3 wireless earbuds, running firmware version 1.0.0.28, accept a new Bluetooth Classic (BR/EDR) pairing request from an unpaired device without requiring the earbuds to be placed into pairing mode or requiring any physical confirmation or interaction from the owner.
Description
The Skullcandy Dime 3 (Model S2DCW) wireless earbuds, running firmware version 1.0.0.28, accept a new Bluetooth Classic (BR/EDR) pairing request from a previously unpaired device without the device being placed into pairing mode by the owner and without physical confirmation on the earbuds. The device’s Bluetooth PnP modalias identifies the chipset vendor as Airoha Technology Corp. (Bluetooth SIG company ID 0x0094). This vulnerability was previously disclosed in CVE-2025-20701 and is described as: In the Airoha Bluetooth audio SDK, there is a possible way to pair Bluetooth audio device without user consent. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
An attacker is required to be within Bluetooth radio range to the target earbuds, but no prior pairing, physical access, or interaction with the earbuds’ buttons or case is required to exploit the vulnerability. A direct pairing request to the earbuds’ known or discovered Bluetooth Classic address can be sent without a PIN, passkey, or physical confirmation. The pairing/bonding completes without owner action due to the device’s NoInputNoOutput I/O capability. The firmware version displayed on the affected Skullcandy Dime 3 wireless earbuds is 1.0.0.28.
Impact
Once bonded, the attacker’s device is added as a trusted device and can reconnect automatically whenever in range. This allows an attacker to establish an A2DP audio transport, which interrupts the legitimate user’s active connection to their own device. The only indication to the legitimate user is an audible “New device paired” notification, given after the unauthorized pairing has already succeeded, providing no opportunity to block it in advance. This could allow an attacker to hijack the audio session or, depending on device capabilities, potentially access other services exposed over the same Bluetooth Classic connection. An attacker can also access the Dime 3’s Hands-Free/Headset profile and capture live microphone audio.
Solution
The vendor considers the CVE-2025-20701 patch in version 1.0.0.30 to be effective. However, Skullcandy confirmed that the Dime 3 does not support firmware updates through the Skullcandy application. Existing units running the vulnerable firmware cannot currently be updated by customers through the app. As of this writing, there are no known consumer-accessible methods to update an existing unit from the affected firmware version 1.0.0.28 to version 1.0.0.30.
Acknowledgements
Thank you to Jacob Nowak for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
A Server-Side Request Forgery (SSRF) vulnerability exists in Ascensio System SIA’s ONLYOFFICE ownCloud integration plugin (version 9.12). The plugin’s backend endpoint does not adequately validate the user‑supplied document server URL before initiating outbound connections. An authenticated administrator can exploit this flaw to coerce the ownCloud server into issuing arbitrary network requests to attacker‑controlled destinations.
Description
The ownCloud ecosystem delivers a platform for enterprise file collaboration, providing capabilities for storing, syncing, and sharing data across devices. Ascensio System SIA’s ONLYOFFICE provides a connector that integrates with ownCloud, enabling users to open and edit files directly within the cloud storage environment.
When configuring the ONLYOFFICE document server within ownCloud, the plugin accepts a document server parameter and attempts to verify the supplied URL by initiating a connection directly from the ownCloud server. As detailed in CVE-2026-84282, the application does not restrict or sanitize this parameter, allowing an authenticated administrator to provide arbitrary URLs, including internal network hosts or localhost addresses. By submitting crafted configuration requests to the /apps/onlyoffice/ajax/settings/address endpoint, an attacker can instruct the server to make outbound requests to internal systems that are otherwise inaccessible externally. Differences in returned error messages (such as connection failures versus SSL/TLS negotiation errors) enable the attacker to distinguish between open and closed TCP ports, facilitating internal network reconnaissance and port enumeration. The outbound requests originate from the ownCloud server, demonstrating server‑side request execution consistent with an SSRF vulnerability. This vulnerability could allow an attacker to abuse the ownCloud server infrastructure as a proxy to send malicious content to targeted systems.
Impact
Successful exploitation allows an authenticated administrator to:
* Trigger arbitrary outbound network requests from the ownCloud server (SSRF).
* Access and probe localhost services (127.0.0.1) not reachable externally.
* Perform internal network reconnaissance and port scanning.
* Identify open and closed TCP ports through response‑based side channels.
* Increase the attack surface for potential follow‑on exploitation of internal services.
Solution
Unfortunately, the vendor could not be reached to coordinate this vulnerability. While an official patch is not available at this time, there are a few general recommendations that may help mitigate this vulnerability. Disable or remove the plugin until a patched version is released. Network‑level egress controls should be applied to limit outbound connections from the ownCloud server to authorized destinations only.
Acknowledgements
Thank you to Nguyen Huy Hoang, Nguyen Vu Long and Nguyen Tien Dat of ETC JSC for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
Casdoor is an open-source Access Management (IAM) platform used to manage web applications. An authorization bypass vulnerability affects Casdoor versions 3.115.0 and earlier. The vulnerability allows a non-global organization administrator to perform unauthorized administrative actions against arbitrary organizations by exploiting inconsistent object resolution between the authorization layer and downstream controllers. In multi-tenant deployments, an attacker with administrative privileges within a single organization can bypass tenant isolation and perform administrative operations against other organizations.
Description
CVE-2026-15630.
The vulnerability stems from a desynchronization between authorization and action in multiple POST /api/add,delete- endpoints (e.g., /api/add-user, /api/delete-user, /api/add-permission). While the global authorization filter (routers/authzfilter.go) correctly uses the ?id= URL query parameter as the authoritative target for authorization decisions, the affected controllers (controllers/user.go, controllers/permission.go, etc.) ignore ?id= and operate solely on the owner and name fields in the JSON request body. As a result, authorization is evaluated against one object while the requested operation is executed against another, allowing an authenticated organization administrator (IsAdmin=true) to perform unauthorized administrative actions across tenant boundaries.
Impact
An attacker with administrative privileges in a single organization can compromise the isolation guarantees of a multi-tenant Casdoor deployment. Depending on the exposed endpoints and deployment configuration, successful exploitation can allow for administrative operations including user management, privilege management and disruption of single sign-on (SSO) or Security Assertion Markup Language (SAML) identity. The overall impact can escalate to a complete compromise of tenant isolation and, in some deployment scenarios, potential compromise of the entire Casdoor instance.
Solution
Unfortunately, we were unable to reach Casdoor to coordinate this vulnerability. Therefore, at the time of this publication, no vendor patch is known to be available. If upgrading to a fixed release is not yet possible, organizations can consider the following mitigations:

Enforce least privilege by minimizing the number of accounts with IsAdmin=true, disabling any workflows that automatically grant admin privilege
Require multi-factor authentication (MFA) for all administrative accounts and/or administrative actions
Alert on cross-organization administrative activity, including:
Creation of administrator accounts
Deletion of users belonging to other organizations
Modification of permissions across organizational boundaries using wildcard resources=[“”] or actions=[“”] permissive Casbin rules.

Investigate unexplained reductions in user counts or administrative objects within any organization.

Acknowledgements
Thank you to Louis Sanchez of Voke Cyber for reporting this vulnerability. This document was written by Alexander Curtis.