Djehuty
Monthly
Unauthenticated SPARQL injection in djehuty, the 4TU.ResearchData research data repository, before version 26.3.2 lets remote attackers manipulate the SELECT queries behind the search and listing endpoints through three separate request parameters, enabling cross-graph data exfiltration and resource-exhaustion denial of service. Because no account, credentials, or user interaction are required, any instance exposing its search/listing functionality to the network is at risk; the injected queries are read-only, so no data can be written or altered, but triples held in graphs outside the request's intended scope (drafts, private, or internal RDF data) can be pulled in via UNION-style constructs, and deliberately expensive or malformed queries can tie up the SPARQL backend and web workers. A vendor-released patch exists in 26.3.2 and has been published as advisory GHSA-7gp2-rxw9-vw6p, and no public exploit code or confirmed active exploitation was identified at time of analysis.
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.
Unauthenticated SPARQL injection in djehuty, the 4TU.ResearchData research data repository, before version 26.3.2 lets remote attackers manipulate the SELECT queries behind the search and listing endpoints through three separate request parameters, enabling cross-graph data exfiltration and resource-exhaustion denial of service. Because no account, credentials, or user interaction are required, any instance exposing its search/listing functionality to the network is at risk; the injected queries are read-only, so no data can be written or altered, but triples held in graphs outside the request's intended scope (drafts, private, or internal RDF data) can be pulled in via UNION-style constructs, and deliberately expensive or malformed queries can tie up the SPARQL backend and web workers. A vendor-released patch exists in 26.3.2 and has been published as advisory GHSA-7gp2-rxw9-vw6p, and no public exploit code or confirmed active exploitation was identified at time of analysis.
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.