CVE-2026-45579 in DIRAC
Summary
by MITRE • 09/15/2026
DIRAC is an interware, meaning a software framework for distributed computing. Prior to versions 8.0.79, 9.0.22, and 9.1.10, the RequestManagementSystem/Service/ReqManagerHandler.py export_getRequestCountersWeb function passes an authenticated caller-controlled groupingAttribute to RequestManagementSystem/DB/RequestDB.py getRequestCountersWeb. An unrecognized value is resolved against the Request object and evaluated as Python code, allowing a crafted dunder attribute expression to reach operating-system functions and execute commands as the account running the DIRAC services. Successful exploitation can expose dirac.cfg, database passwords, stored proxies, and tokens, fully compromise the DIRAC system, and allow alteration of local log evidence. This issue is fixed in versions 8.0.79, 9.0.22, and 9.1.10.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified within the DIRAC interware framework represents a critical server-side code injection flaw rooted in improper validation of user-supplied input. DIRAC serves as a software framework for distributed computing, managing complex workflows across various resources. The specific weakness resides in the RequestManagementSystem component, particularly affecting versions prior to 8.0.79, 9.0.22, and 9.1.10. In these affected releases, the ReqManagerHandler.py module exposes a function named export_getRequestCountersWeb which accepts an authenticated caller-controlled parameter known as groupingAttribute. This parameter is intended for organizing or categorizing request counters but lacks sufficient sanitization before being passed downstream to RequestDB.py and its getRequestCountersWeb method. The fundamental technical flaw lies in the resolution mechanism, where unrecognized values for this attribute are not rejected outright but are instead processed through a context that allows them to be evaluated as Python code. This behavior effectively creates an arbitrary code execution vector because the framework attempts to resolve the input against Request object attributes without verifying if those attributes exist or are safe to access.
From a technical perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), specifically involving server-side script evaluation. The attacker leverages crafted dunder attribute expressions, which refer to Python's special methods and attributes that begin and end with double underscores such as _class_ or _init_. By manipulating the groupingAttribute parameter, an authenticated user can construct a payload that exploits how DIRAC resolves these names. When the system attempts to process this malicious input, it inadvertently executes arbitrary Python code within the context of the application server. This is not merely a data exposure issue but a full remote code execution vulnerability because the injected code runs with the same privileges as the DIRAC service account. The ability to execute operating-system functions means that an attacker can bypass standard application-level security controls and interact directly with the underlying host environment, turning what appears to be a simple reporting feature into a powerful attack vector for system compromise.
The operational impact of this vulnerability is severe due to the high level of access granted by successful exploitation. Since DIRAC services typically run under specific service accounts that often possess elevated privileges necessary for managing distributed resources, an attacker who exploits this flaw gains control equivalent to that account. This allows for the exfiltration of sensitive configuration files such as dirac.cfg, which may contain database connection strings and credentials. Furthermore, stored proxies and authentication tokens used by DIRAC to interact with other components in the grid can be stolen, enabling lateral movement across the distributed infrastructure. The attacker can also alter local log evidence to cover their tracks, complicating forensic analysis and incident response efforts. Ultimately, this leads to a complete compromise of the DIRAC system integrity, potentially disrupting critical scientific or industrial computing workflows that rely on the framework for task distribution and resource management.
In terms of threat modeling, this vulnerability maps directly to MITRE ATT&CK techniques related to Command and Scripting Interpreter abuse, specifically T1059 which covers various scripting languages including Python. The exploitation path involves Initial Access via authenticated credentials followed by Execution through code injection. Defense in depth strategies are essential for mitigating such risks. Organizations running affected versions of DIRAC must immediately upgrade to version 8.0.79, 9.0.22, or 9.1.10 where the issue has been resolved. For systems that cannot be patched immediately, implementing strict input validation on all parameters passed to RequestManagementSystem functions is critical. This includes whitelisting allowed values for groupingAttribute rather than relying on blacklist approaches which can be bypassed by novel dunder expressions. Additionally, enforcing principle of least privilege for the DIRAC service account limits the blast radius if an exploitation attempt occurs, ensuring that even successful code execution does not grant unrestricted access to sensitive configuration files or operating system commands. Regular auditing of authentication logs and monitoring for unusual patterns in request counter queries can also aid in early detection of such injection attempts.