News, updates, trends and the latest
info you need to know about IT

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.