EUVD-2026-90924Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSelf-register via ORCID/SAML
-
DeliverySet malicious SPARQL session name
-
ExploitTrigger state-modifying DELETE/INSERT query
-
ExecutionInject arbitrary triple writes/deletes
-
ImpactCompromise repository-wide metadata integrity
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Query language parameterization
|
| Exploitation Conditions | Requires an authenticated depositor account; the attacker then supplies a crafted session name that djehuty concatenates into a state-modifying SPARQL DELETE/INSERT query, achieving injection. The practical precondition is low because djehuty permits self-registration via ORCID/SAML, so any party able to create an account qualifies. Limiting factors: a logged-in account is mandatory (PR:L, no unauthenticated path), and the installation must be on a version prior to 26.3.2; no non-default configuration is otherwise needed, since the shared RDF store that amplifies impact is the normal deployment mode. |
| Impact | This is a genuine, actionable priority rather than a CVSS-inflated non-issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VI:H/VA:H, score 8.4) aligns tightly with the description: a network-reachable web application flaw, low attack complexity, requiring only a low-privilege authenticated depositor account, with high integrity and availability impact. The severity driver is scope: because the RDF triplestore is shared across all accounts and datasets, a single low-privilege user can rewrite or delete metadata belonging to the entire repository, not just their own records (CWE-943, query-language injection). Mitigating the raw score, exploitation is not fully unauthenticated - but djehuty supports self-registration via ORCID/SAML, so PR:L is a low practical barrier in typical deployments. Exploitation signals are incomplete: no EPSS score was provided, the CVE is not listed in CISA KEV, and no public proof-of-concept is referenced. The fix commit ('Escape the session name field before templating') corroborates the described root cause, so the technical validity is well supported even though real-world exploitation prevalence cannot be quantified from the supplied data. |
| Exploit ScenarioDerived | An attacker self-registers a depositor account via ORCID or SAML, then sets a crafted session name containing SPARQL syntax. When djehuty templates that name into a state-modifying DELETE/INSERT query, the injected SPARQL executes against the shared RDF store, letting the attacker insert or delete arbitrary triples across every account and dataset. No public exploit code is identified at time of analysis, but the single-field injection via a user-controlled session name makes exploitation straightforward for any logged-in user. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 01, 2026
Improper neutralization of query syntax in djehuty, the 4TU.ResearchData research data repository, lets an authenticated depositor supply a crafted session name that is concatenated into a state-modifying SPARQL DELETE/INSERT query, giving them arbitrary write and delete access to triples anywhere in the RDF metadata store. Because that store is shared across every account and dataset in a normal deployment, the result is a repository-wide metadata integrity and availability compromise rather than a self-contained tenant issue (assessed CVSS 3.1 8.1, vendor CVSS 4.0 8.4). The prerequisite is a low barrier: authentication requirements confirmed from the CVSS vector as authenticated (PR:L), but djehuty permits self-registration through ORCID/SAML, so in typical deployments almost anyone can obtain the account needed; no public exploit identified at time of analysis and vendor-released patch: 26.3.2.
RemediationAI
Upgrade djehuty to vendor-released patch 26.3.2 (release tag v26.3.2, https://github.com/4TUResearchData/djehuty/releases/tag/v26.3.2), which contains the session-name escaping fix commit f9f3e47 and the search-order allow-list commit 897c915; full details are in the advisory at https://github.com/4TUResearchData/djehuty/security/advisories/GHSA-9864-23x8-762h. The patch release also adds database migration support, so take a metadata backup before applying it and verify the migration completes. Where immediate upgrade is not possible, the highest-value compensating control is to remove the low-barrier account acquisition path - temporarily disable self-registration via ORCID/SAML or gate new accounts behind manual approval - accepting that this blocks legitimate depositors and may break federated onboarding workflows. In parallel, restrict the session-name input at the edge (reject characters outside a conservative allow-list at a reverse proxy or WAF) with the caveat that such filters are brittle against encoding tricks and only partially compensate. Because the flaw allows deletion of arbitrary triples, treat pre-patch exposure as a data integrity incident: audit recent session names and anomalous SPARQL update activity, compare the RDF store against a known-good metadata backup, and restore or reconcile damaged triples. Keep log retention for all authenticated depositor sessions so any injected queries can be reconstructed.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
djehuty stores research dataset metadata as RDF triples in a SPARQL-queryable store, and state-changing operations are expressed as SPARQL DELETE/INSERT updates. CWE-943 (Improper Neutralization of Special Elements in Data Query Logic) is the root cause class here: user-controlled text - specifically the session name field - is interpolated into a query template without neutralization, so SPARQL operators supplied by the attacker are parsed as query syntax instead of data. Unlike a read-only SELECT injection, this lands inside an update query, meaning injected clauses can restructure or erase unintended triples. The single shared RDF store, rather than per-account graphs, is what lifts the impact from a local record edit to a whole-repository data integrity problem. The vendor fix addresses the root cause directly by escaping the session name field before templating (commit f9f3e47) and, as hardening, restricting search order to an allow-list (commit 897c915), which closes a second path where an unvalidated value reached query construction.
Know when Djehuty gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:N
Network-reachable injection with low complexity; PR:L because a low-barrier self-registered depositor account is required; I:H and A:H from arbitrary triple writes/deletes across the shared store, C:N as the DELETE/INSERT path does not read data back.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
djehuty is a research data repository system developed by 4TU.ResearchData. Prior to version 26.3.2, an authenticated depositor can inject arbitrary SPARQL into a state-modifying (DELETE/INSERT) query by supplying a crafted session name, letting them write (and delete) arbitrary triples anywhere in the RDF store. Because the RDF store is shared across all accounts and datasets, this is an integrity compromise of the whole repository's metadata, not just the attacker's own records. Having a logged-in account is a precondition. djehuty allows self-registration via ORCID/SAML, so this is a low barrier in typical deployments. This issue has been patched in version 26.3.2.
Technical POC Analysis
Evidence base: GHSA-9864-23x8-762h only.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A high-severity defect in djehuty, the platform behind the 4TU.ResearchData repository, lets any authenticated depositor inject crafted session names into the metadata store's write queries, giving them the ability to alter or delete research metadata anywhere in the repository rather than only within their own datasets. Because self-registration through ORCID/SAML makes depositor accounts broadly obtainable and the RDF metadata store is shared across all accounts, the exposure is institutional rather than tenant-isolated: corrupted provenance, citation, and discovery records could undermine trust in the repository as a system of record and disrupt access for the entire user community. No public exploit identified at time of analysis, so leadership should treat this as a pressing remediation obligation rather than an active incident.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.
NoSQL injection exploits databases that don't use traditional SQL syntax-like MongoDB, CouchDB, or Redis-by manipulating queries through unsanitized user input.
Exploit-DB