Directory Traversalorg.dspace:dspace-api is a DSpace core data model and service APIs.
Affected versions of this package are vulnerable to Directory Traversal through the initCurator reporter output handling in dspace-api/src/main/java/org/dspace/curate/Curation.java. An attacker can overwrite or create files in arbitrary writable locations by supplying a crafted -r reporter path when running a curation task through the web UI. The vulnerable code passed this.reporter directly to new PrintStream(...) without restricting it to a configured base directory, so a DSpace collection, community, or site administrator could direct curation output into unexpected paths such as configuration files or webapp resources. This can break the site or, in chained scenarios, support privilege escalation by placing attacker-controlled content where the server later reads or executes it.
Workarounds
- Temporarily disable all Curation Tasks by commenting out every
plugin.named.org.dspace.curate.CurationTask entry in dspace/config/modules/curate.cfg; this prevents the web UI and dspace curate from accepting the -r reporter output path and blocks the traversal/write attack path.
- If you rely on scheduled
dspace curate jobs, stop or rework those cron jobs before disabling the curation task plugins; this avoids breaking legitimate automated curation runs while you remove the vulnerable feature.
How to fix Directory Traversal? Upgrade org.dspace:dspace-api to version 7.6.7, 8.4, 9.3, 10.0 or higher.
| [,7.6.7)[8.0-rc1,8.4)[9.0-rc1,9.3)[10-rc1,10.0) |
Arbitrary Code Injectionorg.dspace:dspace-api is a DSpace core data model and service APIs.
Affected versions of this package are vulnerable to Arbitrary Code Injection through the Velocity template processing in org.dspace.core.LDN and org.dspace.core.Email. An attacker with DSpace administrator credentials can supply or modify LDN/Velocity template content so the template engine resolves reflective access and executes Java code during LDN message generation. This affects repositories that use LDN message templates, and it can let an authenticated administrator run arbitrary code on the DSpace backend, compromising the server and any data or actions reachable from that process.
Notes
- The vulnerable LDN/email template context exposed the full
ConfigurationService object to Velocity, so template authors could access arbitrary configuration keys rather than just the small set intended for message rendering.
- The issue is limited to deployments using the Velocity-based LDN/message-template path; the maintainer's advisory notes that
ldn.enabled=false disables the known attack path.
Workarounds
- Disable LDN in
dspace.cfg or local.cfg by setting ldn.enabled=false if LDN is not essential; this removes the known attack path for the template RCE issue.
- If you cannot upgrade immediately, manually apply the maintainer-provided patch for your branch to the DSpace backend, then rebuild, redeploy, and restart the backend; this mitigates the vulnerable Velocity template processing used by LDN and email templating.
How to fix Arbitrary Code Injection? Upgrade org.dspace:dspace-api to version 8.4, 9.3, 10.0 or higher.
| [8.0-rc1,8.4)[9.0-rc1,9.3)[10.0-rc1,10.0) |
Directory Traversalorg.dspace:dspace-api is a DSpace core data model and service APIs.
Affected versions of this package are vulnerable to Directory Traversal through the handleCurationTask process in dspace-api/src/main/java/org/dspace/core/LDN.java. An attacker with DSpace administrator credentials can supply an inbound LDN template path that points outside the trusted LDN template directory and make the server read an arbitrary file as an Apache Velocity template. This lets the attacker use a file elsewhere on the filesystem as LDN input, which can disclose sensitive data or be leveraged to execute arbitrary Java code through malicious template content.
Notes
- The vulnerable behavior is broader than just reading LDN templates: the same code path also accepted arbitrary filesystem locations for curation task input and reporter output, so deployments exposing those paths through administrative workflows had the same path-handling weakness.
Workarounds
- Set
ldn.enabled=false in dspace.cfg or local.cfg to disable LDN if it is not essential, which prevents the attacker from abusing LDN message generation to read an arbitrary file as a template.
How to fix Directory Traversal? Upgrade org.dspace:dspace-api to version 8.4, 9.3, 10.0 or higher.
| [8.0-rc1,8.4)[9.0-rc1,9.3)[10.0-rc1,10.0) |
Improper Restriction of Names for Files and Other Resourcesorg.dspace:dspace-api is a DSpace core data model and service APIs.
Affected versions of this package are vulnerable to Improper Restriction of Names for Files and Other Resources via the OREIngestionCrosswalk.ingest process in dspace-api/src/main/java/org/dspace/content/crosswalk/OREIngestionCrosswalk.java. An attacker can ingest a malicious ORE resource by supplying an aggregated resource URI such as file:///etc/passwd, causing the harvester to open and ingest a local server file as a bitstream. This affects OAI harvests where the ORE crosswalk processes attacker-controlled XML from a remote endpoint. The result is disclosure of local file contents inside DSpace items, exposing server data to users who can later access the harvested content.
Workarounds
- Disable the ORE ingestion crosswalk in
dspace.cfg by removing or commenting out org.dspace.content.crosswalk.OREIngestionCrosswalk = ore, \ from plugin.named.org.dspace.content.crosswalk.IngestionCrosswalk; this prevents the OAI harvester from processing attacker-controlled ORE resources that could point to file:///... paths.
How to fix Improper Restriction of Names for Files and Other Resources? Upgrade org.dspace:dspace-api to version 7.6.7, 8.4, 9.3, 10.0 or higher.
| [,7.6.7)[8.0-rc1,8.4)[9.0-rc1,9.3)[10-rc1,10.0) |
