AI Threat Alert
A SQL injection in DIRAC's FileCatalog DatasetManager lets any authenticated user smuggle attacker-controlled SQL into an unescaped f-string query, and the query result is then passed straight to Python's eval(), turning a routine dataset lookup into remote code execution with a 9.9 CVSS score. DIRAC is grid/distributed-computing middleware used to manage large scientific and research dataset catalogs; because only low privileges are required and no user interaction is needed, a single low-trust account (a researcher, a compromised worker-node credential) is enough to fully compromise the server, read dirac.cfg, harvest database passwords, and export every stored proxy and token in the deployment, enabling lateral movement across the whole DIRAC installation. It is not in CISA KEV and no public exploit or Nuclei template exists yet, but the flaw is trivially exploitable — classic string-interpolated SQL feeding eval — and the maintainers explicitly note other functions in the same file share the pattern, so this patch cycle may not close every variant. Downstream exposure is meaningful (2,841 dependents, OpenSSF Scorecard only 6.1/10), so any organization running DIRAC to catalog AI/ML training data should treat this as a same-day patch: upgrade to 8.0.79, 9.0.22, or 9.1.10, and in the interim restrict and monitor calls to checkDataset for anomalous query parameters.
What is the risk?
This is a critical (CVSS 9.9), pre-authentication-adjacent vulnerability: it requires only low privileges (any authenticated DIRAC user) and no user interaction, with scope change and full confidentiality/integrity/availability impact. Exploitability is high from a technical standpoint — the SQL injection is a straightforward unescaped f-string, and the eval() sink is reached almost immediately after the query returns, so building a working exploit requires no AI/ML-specific expertise, just standard SQLi-to-code-execution chaining. There is no evidence of active exploitation (not in CISA KEV, no EPSS data, no public PoC or Nuclei template), which lowers near-term likelihood, but the low bar to exploit and the fact that DIRAC deployments are often shared multi-tenant research/grid environments where many users already hold 'low privilege' accounts significantly raises real-world risk. The vendor's own disclosure flags that the vulnerable pattern (f-string SQL feeding eval) recurs elsewhere in the same file, meaning the current patch should be treated as a first fix, not a guarantee that the underlying pattern is fully eradicated.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| HF Datasets | pip | >= 6, < 8.0.79 | 8.0.79 |
Do you use HF Datasets? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Patch immediately to DIRAC 8.0.79, 9.0.22, or 9.1.10 (all release lines are fixed) — this is the only complete remediation since the injection is in core query-construction logic. Where immediate upgrade isn't possible, restrict which accounts can invoke checkDataset/DatasetManager operations and monitor FileCatalogHandler service logs for dataset query parameters containing SQL metacharacters or anomalous eval-triggering payloads. Rotate database credentials and any proxies/tokens stored in dirac.cfg on hosts that ran a pre-patch version, since exposure cannot be ruled out retroactively. Because the maintainers note the same f-string-to-SQL pattern likely exists elsewhere in DatasetManager.py, audit or code-review that module for other unescaped query construction even after patching, and add SAST/CI rules flagging f-string-built SQL queries and eval() usage on any value derived from a database read.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-61667?
A SQL injection in DIRAC's FileCatalog DatasetManager lets any authenticated user smuggle attacker-controlled SQL into an unescaped f-string query, and the query result is then passed straight to Python's eval(), turning a routine dataset lookup into remote code execution with a 9.9 CVSS score. DIRAC is grid/distributed-computing middleware used to manage large scientific and research dataset catalogs; because only low privileges are required and no user interaction is needed, a single low-trust account (a researcher, a compromised worker-node credential) is enough to fully compromise the server, read dirac.cfg, harvest database passwords, and export every stored proxy and token in the deployment, enabling lateral movement across the whole DIRAC installation. It is not in CISA KEV and no public exploit or Nuclei template exists yet, but the flaw is trivially exploitable — classic string-interpolated SQL feeding eval — and the maintainers explicitly note other functions in the same file share the pattern, so this patch cycle may not close every variant. Downstream exposure is meaningful (2,841 dependents, OpenSSF Scorecard only 6.1/10), so any organization running DIRAC to catalog AI/ML training data should treat this as a same-day patch: upgrade to 8.0.79, 9.0.22, or 9.1.10, and in the interim restrict and monitor calls to checkDataset for anomalous query parameters.
Is CVE-2026-61667 actively exploited?
No confirmed active exploitation of CVE-2026-61667 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-61667?
Patch immediately to DIRAC 8.0.79, 9.0.22, or 9.1.10 (all release lines are fixed) — this is the only complete remediation since the injection is in core query-construction logic. Where immediate upgrade isn't possible, restrict which accounts can invoke checkDataset/DatasetManager operations and monitor FileCatalogHandler service logs for dataset query parameters containing SQL metacharacters or anomalous eval-triggering payloads. Rotate database credentials and any proxies/tokens stored in dirac.cfg on hosts that ran a pre-patch version, since exposure cannot be ruled out retroactively. Because the maintainers note the same f-string-to-SQL pattern likely exists elsewhere in DatasetManager.py, audit or code-review that module for other unescaped query construction even after patching, and add SAST/CI rules flagging f-string-built SQL queries and eval() usage on any value derived from a database read.
What systems are affected by CVE-2026-61667?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, data pipelines, research/grid computing infrastructure, dataset catalog services.
What is the CVSS score for CVE-2026-61667?
CVE-2026-61667 has a CVSS v3.1 base score of 9.9 (CRITICAL).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.002 Data AML.T0025 Exfiltration via Cyber Means AML.T0050 Command and Scripting Interpreter AML.T0055 Unsecured Credentials Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary The FileCatalog DatasetManager runs a query on the database and passes the result to eval. The SQL query contains an injection vulnerability which allows an authenticated user to control the parameter returned to the eval resulting in remote code execution. ### Details The FileCatalog checkDataset function passes its datasets argument directly to the backend DB handler: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/DataManagementSystem/Service/FileCatalogHandler.py#L591-L593 Which in turn passes it to the __checkDataset function: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/DataManagementSystem/DB/FileCatalogComponents/DatasetManager/DatasetManager.py#L390 This uses an f-string to create a query without escaping, resulting in an SQL injection: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/DataManagementSystem/DB/FileCatalogComponents/DatasetManager/DatasetManager.py#L400-L402 The result (which is user controllable due to the SQL injection) is passed into eval almost immediately on return, leading to code execution: https://github.com/DIRACGrid/DIRAC/blob/f7e0a3ac153315030fb3520e8ca747f013758967/src/DIRAC/DataManagementSystem/DB/FileCatalogComponents/DatasetManager/DatasetManager.py#L409 There are other functions in the same file which use a similar pattern and would likely be exploitable in a similar way. ### 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. ### 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/
Exploitation Scenario
An adversary who holds any valid, low-privilege DIRAC account — for example a researcher's credential obtained through phishing, or a compromised worker-node identity in a shared grid environment — calls the FileCatalog checkDataset operation with a crafted dataset name/argument. The unescaped f-string query lets the attacker inject SQL that manipulates the value returned from the database; that manipulated value is passed almost immediately to Python's eval(), executing attacker-supplied code on the FileCatalog server. From there the attacker reads dirac.cfg to obtain database credentials, dumps and exfiltrates all proxies and access tokens DIRAC has stored for its user base, and pivots using those credentials to other services in the grid/data-management deployment — while optionally scrubbing local logs to remove evidence, achieving a stealthy full compromise of the platform that manages the organization's dataset catalog.
Weaknesses (CWE)
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Primary
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Primary
CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
- [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
- [Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H References
Timeline
Related Vulnerabilities
CVE-2026-50027 9.8 mcp-memory-service: auth bypass on document API
Same package: datasets CVE-2026-35492 6.5 kedro-datasets: path traversal enables arbitrary file write
Same package: datasets CVE-2026-52812 Gogs LFS: cross-tenant object disclosure via dedupe bypass
Same package: datasets CVE-2026-48797 backpropagate: auth bypass exposes LLM training plane
Same package: datasets CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Code Execution