CVE-2026-73976 in djehuty
Summary
by MITRE • 10/01/2026
djehuty is a research data repository system developed by 4TU.ResearchData. Prior to version 26.3.2, An unauthenticated attacker can inject SPARQL into the search/listing queries through three separate parameters. Because the affected queries are read (SELECT) queries, this does not write to the store, but it allows: Cross-graph data exfiltration — e.g. UNION-ing in triples from graphs the request was never scoped to (drafts/private/internal data held in the RDF store); denial of service — expensive or malformed queries that tie up the SPARQL backend / web workers. No account or user interaction is required. This issue has been patched in version 26.3.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/01/2026
The djehuty research data repository system, developed by 4TU.ResearchData, serves as a critical infrastructure for managing and sharing scientific datasets. Prior to the release of version 26.3.2, this platform contained significant security vulnerabilities related to its SPARQL endpoint implementation. These flaws allowed unauthenticated attackers to inject malicious SPARQL queries into search and listing operations through three distinct input parameters. The core technical flaw stems from insufficient validation or sanitization of user-supplied data before it is incorporated into database query structures. This lack of proper input handling enables an attacker to manipulate the intended logic of SELECT statements, effectively bypassing access controls that should restrict visibility to specific datasets or graphs within the RDF store.
The operational impact of this vulnerability is severe due to its unauthenticated nature and broad scope. Since no account creation or user interaction is required for exploitation, any external actor on the internet can attempt to exploit these flaws immediately upon discovery. The primary consequence is cross-graph data exfiltration. By injecting SPARQL commands that utilize UNION operations, an attacker can retrieve triples from graphs that are not part of the original query scope. This means sensitive information such as draft datasets, private research data, or internal organizational records stored in the RDF repository could be exposed to unauthorized parties. The ability to access data outside the intended permission boundaries represents a critical failure in data isolation and confidentiality controls within the application layer.
Beyond data theft, the vulnerability also facilitates denial of service attacks against the djehuty infrastructure. An attacker can craft expensive or malformed SPARQL queries that consume excessive computational resources on the backend server. These resource-intensive operations tie up web workers and database connections, potentially rendering the repository unavailable to legitimate users. This type of attack exploits the complexity inherent in query execution engines, where poorly optimized or maliciously constructed requests can lead to significant performance degradation or complete service outages without requiring any form of authentication or privilege escalation.
From a classification perspective, this vulnerability aligns with CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, adapted here for SPARQL query injection contexts. It also relates to CWE-200, where information exposure occurs due to insufficient access control mechanisms. In terms of the MITRE ATT&CK framework, this behavior corresponds to techniques involving unauthorized data exfiltration and resource exhaustion, specifically mapping to tactics that allow adversaries to gather intelligence from cloud databases or compromise system availability through application layer attacks.
The issue has been addressed in version 26.3.2 of the djehuty software. Organizations running earlier versions must upgrade immediately to mitigate these risks. Mitigation strategies should also include implementing strict input validation on all parameters that interact with query builders, employing parameterized queries or safe abstraction layers for SPARQL generation, and deploying web application firewalls configured to detect anomalous SPARQL syntax patterns. Regular security audits of data repository implementations are essential to ensure that access controls remain robust against evolving injection techniques.