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

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.