Fake issues in OJS 3.3.0.21

Fake issues were generated without any user from the journal doing this. They uploaded this DOI:

10.56727/bsm.v8i1

This is how the site shows the fake issue:

Currently the DOI takes you to this site:

If you search the DOI on the browser, you can see different pages of OJS with the same problem in different versions (3.3.x .x, 3.4.x.x, 3.5.x.x).

I’ve found this post in this forum, it’s the same issue that I have, they used old OJS versions: Publishing fake issues in third-party OJS (without hacking into OJS)

Can you please tell me if there´s an upcoming solution/fix?

Thanks in advance

What application are you using?
OJS 3.3.0-21
PHP 8.1.27
Mysql 11.4.7

@asmecher - thoughts on this one? The bug that you mentioned in the thread reference seemingly is resolved for 3.3.0-21 - might something else be causing this?

-Roger

Hi @jessica,

What is the upgrade history of the installation? For example, did you upgrade to OJS 3.3.0-21 from an older release like 3.3.0-16 within the last 6 months?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

Just to clarify, the fake issue was created in the version 3.3.0.21. Here’s my upgrade history installation:

Thanks

Hi @jessica,

The mechanism by which we’ve seen folks getting attacked in the wild is via installations older than OJS 3.3.0-16 (or so), where there was a stored XSS attack in the “preferred public name” field. Attackers could enter Javsacript into that field as unprivileged users, and cause it to be executed on a privileged user’s browser, which could then be leveraged to do a number of things – import XML, upload plugins, create privileged users, and more.

With the upgrade to 3.3.0-16 (ish) or newer, that particular possibility was closed, but if it had been already used to expand the attacker’s possibilities, then just the upgrade by itself might not close all doors. For example, the attacker could’ve added Javascript to exfiltrate passwords as users logged in; they could’ve uploaded a plugin that installed a backdoor to run arbitrary code server-side; etc. Some of those tools might persist after the upgrade to a “safe” version of OJS – if a user was able to create a new Journal Manager account on 3.3.0-14, then upgrading to 3.3.0-20 would not have removed that account.

Your upgrade from a “known risky” OJS (3.3.0-14) to a “safe so far” OJS (3.3.0-20) was relatively recent – May 2025 – leaving quite a long period of time since the discovery of the XSS issue (which IIRC was late 2023) for someone to cause trouble that might persist with the upgraded installation.

The good news is that I haven’t seen any evidence that these attacks were particularly sophisticated; there probably aren’t deeply-hidden back doors or anything tricky like that. It’s likely that someone either created a privileged account, or exfiltrated an existing one’s password, and that cleaning that up should solve the problem.

I would suggest these steps:

  1. Delete any unexpected issues.
  2. Review the list of Journal Managers, Journal Editors, and Administrators to ensure there are no surprise entries. If there are, remove them.
  3. Use new, safe passwords for all the existing privileged accounts.
  4. Stay up to date with the newest releases.

I suspect that will resolve the problem. It is possible that something more devious is happening, e.g. a hidden back-door somewhere in the system; if you do see evidence of that, then it’ll be necessary to do more investigation on the server side.

I’m always attentive to the possibility that something new is going on here that I haven’t covered above – if you think that’s the case, please feel free to provide details to me, via private message if you think they’re sensitive (i.e. an undisclosed security problem).

Thanks,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi @asmecher

I already went through the steps you just suggested. If I find anything more, I’ll reach out to you in a private message, or I"ll create a new post.

Thanks.

Hi @jessica,

You might be able to find out more by tracking the problem user through the web server access log. If the fake issue was brought in through the XML import/export, then you’ll see activity on URLs that look like …/management/importexport/plugin/NativeImportExportPlugin/import – these will be very rarely used, so few false positives to worry about (unless your workflow includes regular XML import). That might get you to a user IP address, and from there you can track that IP address’s interaction in the system.

Regards,
Alec Smecher
Public Knowledge Project Team

(…and of course, please double-check that your files_dir as configured in config.inc.php is not inside the web root! That’s a common misconfiguration that often leads to hacks.)

Hi @jessica,

I can confirm that the problem is what I pointed out above – your files_dir is inside the web root. Please move it somewhere safe!

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

Regarding the “files_dir” inside the web root you mentioned, starting from 3.3.0.20 my installation was done with Docker and Official Docker images. The structure of my private files are the same as mentioned in the containers/docs/easyOJS.md at main · pkp/containers · GitHub . As a far I can see, the /var/www folder is not exposed.

grep2

I’ve checked the access.log file, and filter through the path “management/importexport/plugin/NativeImportExportPlugin/import” and couldn’t find any trace to a suspicious user IP address, but I’m actively monitoring the logs.

Regards

Hi @jessica,

I’ll send a private message with details.

Thanks,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

Reading is containers related, as I got some time, I contacted Jessica to take a look and all looks fine with her installation.

OJS is up to date, permissions are fine, and I can ensure the private folder is not exposed. I also checked with her the list of admins and journal managers, just in case the journal was left by the previous hack and we also used scripts and rootkit checkers to find if they left any backdoor… but nothing jumped.

BTW, in the docker containers the privatefolder lives at /var/www/files that it’s safe folder as far is not web-maped by default. The public folder instead, in the other hand, in /var/www/html/publicand it’s the usual DocumentRoot open to the world by default.

I don’t know what else to check. What details do you need?

Cheers,
m.

Hi all,

@jessica, I misunderstood your first post and thought you were in charge of the installation hosting the second journal, to which the mystery DOI linked. I see now that you’re administering the first, not the second.

I would suggest taking a database dump and reviewing it for malicious Javascript that might’ve been introduced. Look e.g. for <script – searching case insensitively. This might help identify any remaining elements of a previous hack that might be e.g. exfiltrating passwords.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi all,

@asmecher It’s correct, the site I’m administering is the first one.

I checked the database dump for a malicious Javascript like you mentioned, and I didn’t find anything suspicious.

Thanks

Hi @jessica,

I’m not sure where else to point you; if it were my installation, I’d look through the access logs for unexpected activity. You’ve already looked for import operations, and not turned anything up, so the next thing would be to look for operations that e.g. create or publish issues, to see if that was done manually. These should be uncommon enough operations that you won’t have many log entries to look through.

I’d also be tempted to take the OJS installation directory and run a diff to compare it with a stock version of the codebase. In addition to modifications, look for extra files e.g. backdoor scripts or unexpected plugins.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi you both,

I’ve followed the thread and I’m also out of ideas because everything seems perfect.

Comparing code with diff would be a good recommendation in general, but with Docker you just have to restart the container to return to the initial code of the image (which you’ve already done several times), so there’s no risk there.

I have also asked her to use rootkit detection tools and check the contents of the public and private folders again (with a script that filters the content) in case there is anything unexpected… but she has already done all that.

With no other ideas, I suggested to Jessica that she leave a tmux terminal with an access log with a grep to show when the import/export plugin is accessed (even send her an email)… if it happens again, at least we’ll know when and from which IP address.

At this point, the only thing I can think of is that the information you were given is incorrect and that the problem occurred in the old version of OJS but that you are now immune.

Jessica, is it possible that the dates were mixed up and the attack actually happened before everything was dockerised?

Hi @asmecher and @marc,

I’m not sure if this DOI https://doi.org/10.56727/bsm.v8i1 was added before I upgraded the site to the version 3.3.0.21 in Docker, and I recently notice it.

I will do everything you mentioned. I have the tmux terminal with a grep to show when the import/export plugin is accesed.

If the DOI were to appear I’ll let you know, so far I haven’t seen anything out of the normal.

Thanks

1 Like

Hi @jessica / @marc,

I think that’s probably the likeliest situation – that the issue was added before the upgrade. We’re attentive to security issues and thus far have seen no evidence that the latest releases of OJS (3.3.x, 3.4.x, or 3.5.x) are susceptible. But please do let us know if you see anything different!

Thanks,
Alec Smecher
Public Knowledge Project Team

2 Likes

This topic was automatically closed after 12 days. New replies are no longer allowed.