OJS Author Vulnerability Could Allow Arbitrary File Deletion Through coverImage.uploadName

A security vulnerability in Open Journal Systems (OJS) could allow an authenticated Author to influence the filesystem path used when deleting a publication cover image. The issue can lead to arbitrary file deletion within the permissions available to the OJS process and could cause severe application disruption if sensitive application files are affected.

Arbitrary File Deletion Found in OJS Publication Handling

Security research into Open Journal Systems (OJS) has identified a path traversal issue involving the coverImage.uploadName publication setting.

The vulnerability occurs when a value supplied through the publication API can be stored as cover-image metadata without sufficient filesystem-path validation.

When the cover image is later removed, OJS uses the stored value during the file deletion process.

This creates a security boundary problem where data originating from an authenticated Author can influence a filesystem deletion operation.

The issue is currently being tracked as a research finding, with the CVE identifier and final affected-version scope pending confirmation.

Author-Level Access Is Sufficient

One of the more concerning characteristics of the issue is the relatively low privilege required to reach the vulnerable functionality.

The research indicates that an authenticated Author can access the publication workflow involved in the vulnerable code path.

The security boundary can therefore be represented as:

Authenticated Author
        │
        ▼
Publication
        │
        ▼
Cover Image Metadata
        │
        ▼
Filesystem Deletion
        │
        ▼
Potential File Deletion

This is significantly different from a vulnerability that requires administrator privileges, because an Author account has substantially fewer permissions than an OJS administrator.

The practical exposure will depend on the application's registration settings, version, deployment configuration, and filesystem permissions.

coverImage.uploadName Is at the Center of the Issue

The vulnerability is related to how OJS processes the uploadName value associated with publication cover images.

During source-code analysis, the research identified a code path where the absence of a temporaryFileId allows the supplied cover-image value to continue through metadata handling without the same validation expected from a normal upload workflow.

The resulting data flow can be summarized as:

API Input
   │
   ▼
coverImage.uploadName
   │
   ▼
Publication Metadata
   │
   ▼
Stored Value
   │
   ▼
Cover Image Removal
   │
   ▼
Filesystem Path Construction
   │
   ▼
File Deletion

The underlying problem is not simply that path traversal characters may be accepted.

The more important issue is that a value originating from application metadata is eventually treated as a filesystem-relevant path without establishing that the resolved path remains inside the intended upload directory.

Filesystem Boundary Is Not Properly Enforced

A secure file-management implementation should ensure that a requested file remains within its designated directory before performing a destructive operation.

Conceptually:

Requested Path
      │
      ▼
Canonicalize / Resolve
      │
      ▼
Inside Allowed Directory?
      │
   ┌──┴──┐
   │     │
  YES    NO
   │     │
 DELETE  REJECT

The vulnerable flow instead allows the stored filename/path to participate directly in path construction before the deletion operation.

This means the application's trust in uploadName becomes the critical security boundary.

Potential Impact

The primary impact is arbitrary file deletion, subject to the filesystem permissions of the OJS process.

Potential consequences include:

• Deletion of files outside the intended publication directory
• Severe application disruption
• Loss of application resources
• Configuration damage
• Selective denial of service
• Complete application unavailability in certain scenarios
• Potential chaining with other vulnerabilities

The severity of the impact depends on which files are accessible to the account running OJS and how the installation is configured.

File Deletion Does Not Automatically Mean RCE

It is important to distinguish the confirmed vulnerability from possible post-exploitation chains.

Arbitrary file deletion alone does not automatically provide Remote Code Execution.

A chain involving configuration destruction, application reinstallation, administrative access, or another vulnerability would depend on the exact OJS version and deployment configuration and must be independently validated.

For this reason, the current research classifies the primary finding as arbitrary file deletion, rather than treating RCE as an intrinsic property of the vulnerability.

Safe Verification Using a Canary File

The vulnerability can be investigated without intentionally damaging application files by using a disposable canary file.

The general verification process is:

Create Disposable Canary
          │
          ▼
Reference Canary Through
Cover-Image Metadata
          │
          ▼
Trigger Cover-Image Removal
          │
          ▼
Check Canary
          │
          ▼
Canary Removed

A successful canary deletion demonstrates that the file-deletion operation can escape the intended directory boundary.

Security researchers should perform this type of testing only against systems they own or systems for which they have explicit authorization.

Affected Versions Require Confirmation

The original research investigated OJS versions in the 3.3.x–3.5.x range.

However, a complete affected-version statement should only be made after reproducing the issue against each relevant release.

The final affected range, fixed release, and CVE identifier should be updated once vendor confirmation is available.

Security Teams Should Review Their OJS Installations

Organizations operating internet-facing OJS installations should review their deployment configuration and monitor for suspicious publication metadata.

Recommended actions include:

1. Verify the exact OJS version running in production.
2. Review whether public registration is enabled.
3. Identify accounts with Author privileges.
4. Review publication API activity for unusual cover-image metadata.
5. Monitor for path traversal patterns in application logs.
6. Review filesystem logs for unexpected deletions performed by the OJS process.
7. Keep OJS and its underlying server environment fully patched.
8. Apply the vendor's security update once an official fix becomes available.
9. Preserve relevant logs if unauthorized filesystem activity is suspected.

Temporary network restrictions can reduce exposure while remediation is being prepared, but they should not replace applying an official security fix.

Recommended Mitigation

Developers should ensure that client-controlled metadata cannot select arbitrary filesystem paths.

Recommended defensive measures include:

Reject Client-Controlled File Paths

When no new upload is being performed, the server should preserve the existing server-controlled file identifier or filename instead of accepting a replacement filesystem path from the client.

Enforce Canonical Path Boundaries

Before a file is deleted, the application should resolve both the candidate path and the permitted base directory and verify that the candidate remains inside the permitted directory.

Prefer Internal File Identifiers

Instead of exposing filesystem paths through API metadata, applications should use internal file identifiers and resolve those identifiers server-side.

Use Defense in Depth

Validation should exist at multiple layers:

API Validation
      │
      ▼
Repository Validation
      │
      ▼
Filesystem Boundary Check
      │
      ▼
Filesystem Permissions

A simple string filter for ../ should not be considered the primary security control for destructive filesystem operations.

Why This Vulnerability Matters

The issue highlights a broader security principle relevant to modern web applications:

Data that is safe as application metadata can become dangerous when it crosses into a filesystem operation.

An application may correctly assume that an uploaded filename is generated by the server. That assumption becomes unsafe when an API path allows clients to supply or modify the same value.

The resulting vulnerability is a classic example of a trust-boundary failure:

Untrusted API Data
        │
        ▼
Trusted Database Value
        │
        ▼
Filesystem Operation

Storing a value in a database does not make that value trusted.

Conclusion

The OJS security issue involving coverImage.uploadName demonstrates how insufficient validation of publication metadata can cross an important security boundary and reach a destructive filesystem operation.

An authenticated Author may potentially influence the path used during cover-image deletion, creating an arbitrary file deletion vulnerability whose ultimate impact depends on the permissions and configuration of the affected installation.

Organizations running OJS should verify their deployed versions, monitor suspicious publication activity, and apply an official security update once a vendor-confirmed fix is available.

The research also reinforces the importance of treating all filesystem paths derived from API input or stored metadata as untrusted until they have been validated against a strict canonical directory boundary.

Sources

• PKP Open Journal Systems: https://github.com/pkp/ojs
• OJS 3.5.0 Release Notes: https://github.com/pkp/ojs/blob/main/docs/release-notes/README-3.5.0
• PKP Security Policy: https://github.com/pkp/ojs/blob/main/SECURITY.md
• CWE-22 — Path Traversal: https://cwe.mitre.org/data/definitions/22.html
• CWE-73 — External Control of File Name or Path: https://cwe.mitre.org/data/definitions/73.html
• Credit: https://github.com/Yucaerin/OJS-Author-Authenticated-Arbitrary-File-Deletion-via-coverImage.uploadName

Disclosure

Researcher: Yucaerin

Date: August 28, 2026

CVE: Pending

Vendor Confirmation: Pending

This article is provided for security research, vulnerability analysis, and authorized defensive testing. Do not test systems without explicit permission.