What is the CVSS score of EUVD-2026-78894?

EUVD-2026-78894 has a CVSS 3.1 base score of 9.9 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Which versions of DIRAC are affected by EUVD-2026-78894?

DIRAC's RequestManagementSystem contains a critical remote code execution vulnerability (CVSS 9.9) allowing any authenticated grid user to execute arbitrary system commands with service-level…. A patch is available.

How to fix or mitigate EUVD-2026-78894?

Within 24 hours: isolate affected DIRAC servers from non-essential network access, revoke and regenerate all database credentials and grid user proxies stored by the system, and enable detailed logging of RequestManagementSystem access. Within 7 days: complete assessment of which grid users accessed the system since deployment and audit logs for evidence of exploitation; coordinate with connected organizations sharing credentials. Within 30 days: maintain enhanced monitoring for exploitation attempts, monitor vendor advisories for eventual patch availability, and consider deploying network-level request filtering for the vulnerable export_getRequestCountersWeb service method until patched.

DIRAC EUVD-2026-78894

| CVE-2026-45579 CRITICAL

Eval Injection (CWE-95)

2026-07-13 https://github.com/DIRACGrid/DIRAC

GHSA-9jpv-c7p4-997x PYSEC-2026-3462

RCE Code Injection

9.9

CVSS 3.1 · Vendor: https://github.com/DIRACGrid/DIRAC

Severity by source

Vendor (https://github.com/DIRACGrid/DIRAC) PRIMARY

9.9 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

9.9 CRITICAL

Network-reachable service callable by any authenticated user (PR:L) with a trivial eval payload (AC:L); scope changes (S:C) as service-account RCE exposes other users' proxies/tokens, yielding full C/I/A impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from Vendor (https://github.com/DIRACGrid/DIRAC).

CVSS VectorVendor: https://github.com/DIRACGrid/DIRAC

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jul 13, 2026 - 19:34 vuln.today

Analysis Generated

Jul 13, 2026 - 19:34 vuln.today

CVE Published

Jul 13, 2026 - 17:20 github-advisory

CRITICAL 9.9

DescriptionCVE.org

Summary

An remote code execution vulnerability exists in RequestManager due to the use of eval on untrusted input that allows any authenticated user to run code/commands on the DIRAC server as the system user running the DIRAC services.

Details

The export_getRequestCountersWeb function is callable by any authenticated user and just passes its parameters directly to the database instance: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/RequestManagementSystem/Service/ReqManagerHandler.py#L270

If the groupingAttribute string is unrecognised, Request. is prepended to it and the result is passed into an eval() call: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/RequestManagementSystem/DB/RequestDB.py#L766-L776

By passing in a dunder string that is applicable to the Request object, it's possible to work back up to functions in the os module and trigger them to be called in the server context.

There are other uses of eval in ReqManager/RequestDB which may be equally accessible.

Impact

This allows any authenticated user to run commands on the server, which allows a full compromise of the DIRAC system (they can read the local dirac.cfg, get database passwords and export all stored proxies and tokens). If local logging is used, they can also remove evidence of the exploit from the log (it leaves an exception printout in the RequestManager log when used).

Patched versions:

https://pypi.org/project/DIRAC/8.0.79/ https://pypi.org/project/DIRAC/9.0.22/ https://pypi.org/project/DIRAC/9.1.10/

AnalysisAI

Authenticated remote code execution in DIRAC's RequestManagementSystem lets any logged-in grid user run arbitrary commands as the DIRAC service account, enabling full compromise of the DIRAC installation. The flaw stems from an eval() call reachable through the export_getRequestCountersWeb service method, and successful exploitation exposes dirac.cfg secrets, database credentials, and all stored user proxies and tokens. Rated CVSS 9.9; no public exploit code has been released, though the vendor advisory documents a complete working exploitation path.

Technical ContextAI

DIRAC is a Python-based distributed computing (grid) middleware framework used to manage jobs, data, and workloads across federated computing resources, notably in high-energy physics communities. The vulnerable code lives in the RequestManagementSystem: the DISET service method ReqManagerHandler.export_getRequestCountersWeb (ReqManagerHandler.py) forwards caller-supplied parameters directly to RequestDB. In RequestDB.py, if the groupingAttribute value is not a recognized attribute, the code prepends 'Request.' to the raw string and passes the result into a Python eval() call. This is a textbook CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code / 'Eval Injection'): untrusted input reaches a dynamic code evaluation sink. Because eval executes against a live Request object, an attacker can traverse Python dunder attributes (e.g., __class__, __bases__, __subclasses__/__globals__) to reach the os module and invoke system commands in the server process context. The CPE identifies the affected package as pkg:pip/dirac (PyPI 'DIRAC').

RemediationAI

Vendor-released patch: upgrade to DIRAC 8.0.79, 9.0.22, or 9.1.10, whichever matches your release line (8.0.x users go to 8.0.79, 8.1/9.0.x users go to 9.0.22, and 9.1.x users go to 9.1.10). Installation packages are at https://pypi.org/project/DIRAC/8.0.79/, https://pypi.org/project/DIRAC/9.0.22/, and https://pypi.org/project/DIRAC/9.1.10/, and full details are in advisory https://github.com/DIRACGrid/DIRAC/security/advisories/GHSA-9jpv-c7p4-997x. If immediate patching is not possible, restrict network access to the RequestManager service so it is reachable only from trusted hosts, and tighten DIRAC group/authorization policies so that only strictly necessary users hold accounts able to call ReqManagerHandler methods - bearing in mind the advisory notes that any authenticated user can trigger this, so limiting the authenticated user base directly reduces exposure. Because the vendor warns of other potentially reachable eval() uses in ReqManager/RequestDB, blocking or disabling the RequestManagementSystem service entirely (trade-off: request/operation management functionality is lost) is a stronger stopgap than trying to filter individual parameters. After patching, treat any secrets reachable from the server as compromised: rotate database passwords stored in dirac.cfg and re-issue affected proxies and tokens.