Open Journal Systems runs tens of thousands of journals, most of them at universities with small editorial teams and no dedicated security staff. That combination makes OJS attractive to attackers, but not for the reasons editors usually assume. Almost nobody is trying to steal your manuscripts. They want your domain’s reputation, your editors’ access, or your journal’s name.
Below are the six patterns behind most OJS incidents discussed on the PKP community forum and in the scholarly publishing press, roughly in order of how often they come up. Each ends with what actually stops it.
1. Spam registrations and profile spam
This is the most common problem on OJS by a wide margin. The registration form is open, there is no CAPTCHA, and bots create accounts by the hundred. Each account fills the biography, affiliation or homepage field with links to gambling, pharmaceuticals or essay mills. OJS renders public profile pages, so your journal’s domain now hosts thousands of pages of spam that Google indexes.
The damage is reputational and it compounds. Search engines lower their trust in the whole domain, legitimate articles rank worse, and in severe cases the journal is flagged as hacked content in Search Console. Indexing services that evaluate a journal’s website will not be impressed either.
What stops it: restrict self-registration under Users & Roles → Site Access Options, enable the CAPTCHA options in config.inc.php, and clean out the existing spam accounts. Then check site:yourjournal.org in Google every month.
2. Stolen or reused editor passwords
Editors manage several journals, sit on several editorial boards and keep several OJS accounts. The passwords tend to be the same. When any unrelated service leaks its password database, attackers try those credentials everywhere, including the login page of your journal. This is credential stuffing, and it is fully automated.
An attacker with an editor account can accept or reject submissions, read confidential reviews and reviewer identities, download unpublished manuscripts, and send email from the journal to every author in the system. The worst documented cases involve fake acceptance letters sent to authors who then paid fees to a third party.
What stops it: a longer minimum password (min_password_length in config.inc.php), no shared accounts, and above all two-factor authentication for anyone who can make an editorial decision. OJS has no 2FA of its own; our Two-Factor Authentication plugin adds TOTP verification with per-role enforcement, so a leaked password alone is no longer enough to log in.
3. Outdated OJS installations
OJS versions from the 3.1 and 3.2 era have vulnerabilities that were disclosed and fixed years ago. Automated scanners fingerprint the version from the page source and try the known exploits. There is no targeting involved; your journal is simply on a list.
What stops it: upgrading to a supported 3.4.x or 3.5.x release and following the PKP announcements. If the upgrade is blocked by an old custom theme or plugin, that theme or plugin is now the security problem.
4. Journal hijacking
This one does not involve your server at all. Attackers register a look-alike domain, copy your journal’s name, ISSN, editorial board and design, and start “accepting” papers for a fee. Authors find the clone through search engines or through fake indexing entries, pay, and receive nothing, or receive a “publication” on the fake site. Your journal’s name is what gets damaged.
Hijacked journals are a documented, growing problem in scholarly publishing, and journals from Latin America, the Middle East and South Asia are heavily targeted because their names are less familiar to authors abroad.
What stops it: you cannot prevent someone from registering a domain, but you can make the original easy to verify. Keep your ISSN record and your entries in indexing services up to date with the correct URL, publish a clear statement of your official domain and fee policy, and check the Retraction Watch Hijacked Journal Checker periodically. If you find a clone, report it to the registrar, to Google, and to the indexes that list you.
5. File uploads landing inside the web root
OJS stores every uploaded file, including submission files from anonymous authors, in the directory set by files_dir. Some installations put that directory inside the public web root for convenience. Combined with a permissive server configuration, this means an uploaded file can be requested directly by URL, and in the worst case a disguised PHP file can be executed.
What stops it: move files_dir outside the web root and make sure the web server serves nothing from it. This is a one-time configuration change.
6. Access nobody revoked
Guest editors from a special issue, a departed managing editor, the IT student who set up the installation in 2019: their accounts often keep Journal Manager or Site Administrator roles for years. Any of those accounts, with a forgotten password sitting in an old inbox, is an entry point.
What stops it: an annual review of who holds privileged roles, and the habit of removing access on the day someone leaves. Two Site Administrators is enough for almost any installation.
What a compromise actually costs
Editors sometimes assume the cost of an incident is a weekend of cleanup. In practice the bill includes: search rankings that take months to recover, an indexing evaluation that fails because the site was flagged, authors who lose trust after receiving fraudulent emails, and, if backups were never tested, years of published content. None of that is theoretical; every item on that list has happened to real journals, and the PKP forum archive is full of the cleanup threads.
The thirty-minute version
If you have half an hour today:
- Check your OJS version and plan the upgrade if it is below 3.4.
- Confirm
force_ssl = Onand that the site loads only over HTTPS. - Restrict self-registration and enable the CAPTCHA.
- Enable two-factor authentication for administrators and editors.
- Look at the last month of new user registrations.
For the complete list, including backups, plugin hygiene and monitoring, see our 12-step OJS security checklist.