CVE-2026-85663 in Aim
Summary
by MITRE • 09/04/2026
Aim 3.29.1 remote tracking server fails to authenticate requests and dispatches arbitrary methods through getattr without allowlist validation. Unauthenticated attackers can register clients, instantiate Repo resources, and invoke arbitrary methods to read experiments or delete runs.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in Aim version 3.29.1 represents a critical failure in access control mechanisms within its remote tracking server architecture. The core technical flaw stems from the improper implementation of method dispatching for incoming API requests. Instead of validating that specific HTTP methods or endpoints are explicitly permitted, the system utilizes Python's getattr function to dynamically resolve and invoke methods based on user-supplied input without any prior allowlist validation. This design pattern effectively bypasses standard authentication checks because the underlying mechanism does not distinguish between authenticated administrative actions and unauthenticated operations when resolving method calls. Consequently, an attacker who can reach the remote tracking server endpoint is able to interact with internal objects directly through this reflection-based invocation path.
From a technical perspective, this flaw allows for arbitrary code execution in the context of the application's runtime environment relative to data access permissions. By exploiting the lack of input validation on method names or endpoints, an unauthenticated actor can register new client sessions without providing valid credentials. Once registered, these clients gain the ability to instantiate Repo resources, which serve as containers for experiment metadata and artifacts. This capability is particularly dangerous because it allows attackers to manipulate the state of tracking repositories that may contain sensitive machine learning model configurations, hyperparameters, or training data logs. The absence of authentication at this stage means that any entity on the network with access to the server port can perform these actions, turning a service intended for authorized team collaboration into an open interface for data manipulation.
The operational impact of this vulnerability is severe, primarily affecting the integrity and confidentiality of machine learning workflows. Attackers can read experiments by invoking methods designed to retrieve experiment details, potentially exposing proprietary model architectures or sensitive training datasets that were not intended for public access. More critically, the ability to delete runs allows malicious actors to cause significant denial of service conditions or data loss within an organization's ML pipeline. The destruction of run records can disrupt ongoing research projects, invalidate historical performance metrics, and force teams to retrain models from scratch, resulting in substantial computational waste and project delays. In environments where Aim is used for compliance auditing or regulatory reporting, the ability to alter or delete experiment history also poses a risk to data integrity requirements mandated by industry standards.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization checks before method invocation. It also maps closely to ATT&CK technique T1078 Valid Accounts, as the attacker leverages valid but unauthenticated client registrations to gain foothold within the application logic. Furthermore, the use of getattr without validation is a classic example of CWE-470 Use of Externally-Controlled Input to Select Classes or Code, which often leads to broader security compromises if not strictly mitigated through allowlisting patterns. The flaw highlights the risks associated with dynamic method resolution in web services where input sanitization and strict access control lists are not enforced at the entry point of request handling.
To mitigate this vulnerability, organizations running Aim version 3.29.1 should immediately upgrade to a patched release that implements proper authentication middleware before any method dispatching occurs. If upgrading is not immediately feasible, network-level controls such as firewall rules or reverse proxy configurations can be employed to restrict access to the tracking server port exclusively from trusted IP addresses and internal subnets. Additionally, implementing strict input validation on all API endpoints to ensure only whitelisted methods are callable via reflection mechanisms would address the root cause of this flaw. Security teams should also audit existing Aim deployments for any signs of unauthorized client registrations or unexpected deletions in experiment history to assess potential compromise scope.