Common OJS Security Vulnerabilities to Watch For

A journal website holds sensitive material: authors’ contact details, unpublished manuscripts, reviewer identities and editorial correspondence. A breach is more than a technical problem. It breaks the trust that peer review depends on, can create legal duties, and can take the journal offline for weeks.

Most attacks aren’t personal. Automated tools scan the internet for software with known weaknesses. A journal doesn’t need enemies to be hit; it only needs to be out of date.

The biggest risk: outdated OJS

Running an old version is the most common and most serious weakness. PKP fixes security problems in new releases, and once a fix is public, the old versions’ weaknesses are public too. The current long-term support release is OJS 3.5; see the latest version of OJS.

• OJS 2.x gets no security fixes at all. A journal still on OJS 2 should treat upgrading as urgent.
• OJS 3.0, 3.1 and 3.2 are no longer maintained either. Flaws found since, such as CVE-2024-56525 (a journal editor creating a super-admin role and inserting a backdoor plugin), were fixed only in 3.3 and 3.4 builds.
• OJS 3.3 is a long-term support release that PKP supports until at least 1 January 2027. Plan your move to 3.5 now rather than after support ends.

An old OJS often sits on an old PHP as well, and old PHP stops receiving security fixes too. PHP 7.4, the last PHP 7, lost security support on 28 November 2022, and PHP 8.2’s ends on 31 December 2026. OJS 3.5 needs PHP 8.2 or later.

Common types of vulnerability

SQL injection

An attacker sends crafted input that changes a database query, to read or alter data. Any web application with a database has to guard against it, which is one more reason to keep OJS updated.

Cross-site scripting (XSS)

Malicious script is injected into a page that other people view. In a journal, that can mean hijacked editor sessions or visitors sent to fake sites. Several published OJS flaws are of this type, such as CVE-2023-5894 and CVE-2025-13469, both fixed in later builds.

File upload abuse

Journals accept uploads by design. If files can be reached directly from the web, a disguised script may be run on the server: in OJS before 2.3.7, CVE-2012-1468 let a user with the author role run code this way. That’s why PKP recommends placing the files folder outside the public web folder, or otherwise protecting it from direct access; check yours.

Weak accounts

Shared logins, weak passwords and too many administrators make it easy to take over an account with full control of the journal.

Unmaintained plugins and themes

Third-party plugins and custom themes can carry their own weaknesses, and they’re often what holds a journal back from upgrading. Remove what you don’t use.

Warning signs of a compromise

• Content you didn’t add: strange links, spam pages, or odd results when you search Google for your domain.
• Email trouble: reports that your mail is being blocked, or bounces for messages you never sent.
• Visitor complaints: redirects to other sites, or browser and antivirus warnings on your pages.
• Server changes: files you don’t recognise, sudden spikes in resource use, unusual errors in the logs.
• Account changes: users you didn’t create, or password changes nobody made.

Practical protection

1. Keep OJS up to date. Apply PKP’s maintenance releases for your version promptly, and follow PKP’s announcements for security notices.
2. Run a supported PHP version and keep the server itself patched.
3. Use HTTPS everywhere. Logins and manuscripts shouldn’t travel unencrypted, and ORCID and similar services expect it.
4. Keep the files folder outside the public web folder.
5. Limit administrator accounts. Give people only the roles they need, and remove accounts that are no longer used.
6. Use strong, unique passwords for every editorial and administrator account.
7. Back up automatically, both the database and the files folder. Store backups away from the server and test a restore.
8. Review logs and user accounts now and then, so you know what normal looks like.

If you think you’ve been breached

1. Stay calm but act quickly. Rushed clean-ups can destroy the evidence you need.
2. Note what you’ve seen, and keep copies of logs and changed files before cleaning anything.
3. Contain it: take the site offline if needed, change administrator and server passwords, and end active sessions.
4. Clean and restore from a known-good backup, and update OJS and PHP before going back online.
5. Work out whether personal data was exposed and who needs to be told.

If personal data such as author or reviewer details may have been exposed, data protection laws (for example India’s Digital Personal Data Protection Act, or the GDPR for people in the EU) may require you to notify authorities or the people affected. This guide is general information, not legal advice; take advice for your situation.

Want your journal checked? Our OJS support team reviews OJS installations, applies updates and sets up backups. If you’re on an older version, our OJS upgrade service gets you onto OJS 3.5 safely. This guide is independent and not endorsed by PKP.

Questions

Is OJS secure?

OJS is actively maintained and PKP fixes security problems as they’re found. The risk comes from not applying those fixes: old versions, old PHP and unmaintained plugins.

Is OJS 3.3 still safe to use?

It’s a long-term support release, supported until at least 1 January 2027, so keep it on the latest 3.3 maintenance release and plan your move to OJS 3.5 now.

Our journal is still on OJS 2. How serious is that?

Serious. OJS 2 receives no security fixes, and its requirements name PHP 5 and PHP 7, which no longer get security fixes either. Upgrading should be a priority.

Do we need to tell anyone after a breach?

Possibly. If personal data was exposed, data protection laws may require notification. Take legal advice.