Security issue: Hacking via submission in OJS 2.4.8

Our website has been hacked via submission to OJS 2.4.8.
Please advise how we can fix this security flaw.

@Roumen_Anguelov Respected Member, Can you please give the detail regarding the “hack via submission in ojs 2.4.8” like how you discovered the hack? what all things got altered? If possible, can you please post the screenshot of the same. Has the hacker altered the database or the frontend of the journal site?
Have you taken adequate measures to prevent common hacking techniques like sql injection, denial of service attack etc?
For more details regarding security of your website, you can google “penetration testing techniques for website”. you will find lot of resources on google regarding the same.

1 Like

Hi @Roumen_Anguelov ,

I’ll need more information in order to determine what’s happened – can you provide more details?

One known vector that has been used to attack OJS installations is to take advantage of a common misconfiguration in the files directory. Is your files directory accessible directly via the web server? If so, then it’s possible for authors to upload malicious files (e.g. PHP scrips) and then invoke them by requesting them directly from the submissions directory via the web server. We recommend placing the files directory outside of the web server’s root, or protecting it from direct access e.g. using an .htaccess file. See docs/README for information.

Alec Smecher
Public Knowledge Project Team

Same thing here. Yes, there is a big security issue. I disabled OJS waiting for update. This is the information:

  • Hacker logged as an author (with a gmail account antisuperior1) (he is an indonesian using lonesomedevilz as nickname)
  • he uploded a defacion script (>Mr. DellatioNx196 GaLers xh3LL Backd00r) as a phtml file
  • he installed a subdir under /files the ran several script (I succeeded hacking 3 external site from my server before he was stopped)

This is the files he installed:

  • abg.html (the defaction screen)
  • col.php a multi attack script + drupal.php to attack drupal
  • eeq.php some insults
  • idx.php
    *rock-you.txt a liste of hacked sites
  • fucntion.php installing other scripts

I tried ro modify Filemanager.php to limit the alloed filetypes but no success.

The journal is offline until a solution avoiding upload of scripts would be available

@palmpiiic, what are you using for your files_dir setting in

As @asmecher mentions, this directory should not be directly web-accessible because it risks exactly the scenario you describe.

Yes. I kept the default dir. So it is indeed web accessible but I can’t really chose another one because I’m on a shared host. If I put
Order allow,deny
Deny from all
in .htaccess could it be sufficient?


Well I got today similar situation. Even if /files directory (and all subdirtectories) give error 403 when accessed, the phtml was run from submission site and ojs was compromised. Any solution?

Hi @TruePepe,

Either move the files directory outside of your web root, or ensure that access to anything there is fully blocked using a mechanism like .htaccess. See the “Recommended Configuration” section in docs/README.

Alec Smecher
Public Knowledge Project Team

I chose .htaccess with Order allow,deny
Deny from all

That’s make likely unaccessible. Anyway should you not prevent this by including such a .htaccess by default?
Furthermore, event by moving ./files to non accessible place, that means hackers can upload weird things like phtml event if they can’t use them right now.

Hi @palmpiiic,

Hackers uploading files to private storage areas isn’t really a risk, unless the storage area is later moved to a public area. Journals may want to upload e.g. source code as part of a valid submission, so we don’t restrict file types for upload.

Not all servers obey .htaccess files, and shipping one with the system would force us to move the files area into the web server’s purview, so we’ve chosen not to do that.

Alec Smecher
Public Knowledge Project Team

Thank you. Anyway, is there a way to limit the mime type of allowed file to docx and pdf? I feel no secure about having inert hacking code on my server.

something like
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$type = finfo_file($finfo, $_FILES[‘myfile’][‘tmp_name’]);
if($type == ‘application/pdf’){
//Is a PDF

I saw on internet many ojs sites are currently attacked

Hi @palmpiiic,

You could adapt FileManager::uploadFile to check MIME types. However, following the recommendations in docs/README will keep your system safe from attacks of this kind without needing to limit the accepted upload types.

Alec Smecher
Public Knowledge Project Team


In the case that the files directory is public, is it enough that you move the directory outside the web root and edit or would you need other changes as well to prevent something breaking down?

Hi @ajnyga,

Yes, moving the directory outside the web root and changing the directory in should solve the problem without introducing others.

Alec Smecher
Public Knowledge Project Team


Unfortunately it happened to me to be hacked (it altered me the home page of my site) by the same Indonesian guys which apparently they are doing it for fun. That because my “files” folder was created initially inside the public html.

(I limited the submissions by registered users.
Many suspect users (mostly from Indonesia) made accounts and tried to upload scripts but nothing happened.)

The situation it is really frustrating for the real submitters: they make an account and cannot submit. Many leaves.

Please let me know if I can let the submissions enabled after moving\modifying the directory outside the public_html.
A few questions:

  1. I already have a couple of journals and articles published. Does the change in the config.php doesn’t affect the integrity of database and all the structures already created with the old configuration?

  2. It is really safe against the future attacks of this kind? It is necessary to add some .htaccess rules too.

  3. What changes I have to do excepting the path in config.php and the physical location of the files?
    My OJS version is

Thank you and my best regards.

Hi @nepos,

There are two solutions to this:

  • Move the files directory out of the web root. All you should need to do is physically move the directory, then update your to configure it with the new files_dir.
  • Alternately, use an .htaccess file to protect the directory from direct access.

Both of these approaches will solve the problem adequately. Neither of these approaches should cause ongoing problems, such as integrity problems with existing submissions.

Alec Smecher
Public Knowledge Project Team

My OJS site was hacked earlier this week. The hacker uploaded a file called dia.phtml as an author submission. Neither the filename or its contents were properly sanitized by OJS before upload and so the hacker executed the php script that was stored in the dia.phtml file.

I contacted OJS staff and they responded quickly and I thank them for doing so. I was essentially told that I hadn’t followed the installation instructions properly.

I’m not entirely satisfied with this response and so have a few questions for possible discussion:

  1. Why would the configuration file within release be setup so that, by default, an OJS installation will write file uploads to a directory below the webroot? The developers know that OJS is vulnerable to a number of serious attacks under this setup and, yet, this is how the configuration file is setup by default?

  2. Why are not all malicious file extensions properly verified before permitting a file to upload? This vulnerability within OJS was publicly disclosed several years ago ( If I upload a .php file, OJS sanitizes the filename extension so that I cannot execute the script. Why does OJS not also sanitize a .phtml file extension?

  3. While I disagree philosophically with the practice of allowing files to be uploaded that have not been properly validated and sanitized, let’s ignore that for the moment. What proportion of all OJS installations require authors to upload code such that it is necessary to allow scripts – and, therefore, malicious scripts – to be uploaded by default?

Any feedback appreciated.

Hi @Callahan,

I’m sorry you’ve been hit by this – it seems that it’s a common misconfiguration and that has caught some recent attention by hackers.

  1. The default in the installation form attempts to go one level up from the base directory. For lack of a common hosting environment – it’s impossible to know where an appropriate place for this would be in the general case, and many/most of our users run with small commodity hosting accounts – users will tend to install OJS in a public_html directory, and thus the default would suggest a files subdirectory parallel to that, which should be outside of the web root. The configuration file’s “files” setting should not appear in the installation form when the system is installed.

  2. It would be possible to e.g. force a filename suffix on uploaded files, but if that were done without moving the file storage area out of the web root (or protecting direct access using an .htaccess mechanism), there would still be a basic problem that submission files could be accessed/downloaded directly. This could permit unauthorized access to the journal’s internal documents. Note that as far as I’m aware, OJS does not sanitize any extensions – .php or .phtml – but a blacklist/whitelist approach is problematic because there are valid uses for .php scripts, such as a software journal in which source code is uploaded for review, and because it’s problematic to maintain either white or blacklists of this kind – .pl? .exe? .bat? .sh? .app? Our chances of making this list comprehensive enough for general security are very low.

  3. I don’t expect that many do make use of script uploads as valid journal content, but OJS is a general-purpose tool, and we try to maintain it using few assumptions about how it’s used.

The installation form, README documentation, etc. note that the file storage area should be kept outside of the web root; doing this solves both the problem of malicious uploads, and of unmediated access to submission files.

Alec Smecher
Public Knowledge Project Team

Hi Alec,

Thanks for the detailed response. Much appreciated.

  1. We’ll have to chalk this one up to a philosophical difference. To not validate or sanitize user data and simply attempt to store this data above the webroot is not good enough, at least for me; especially when it’s clear that multiple users are having not only their installations but their server environments exposed to serious attacks.

  2. I’m pretty sure you guys are sanitizing some file extensions. I uploaded a test.php file and I believe it was converted to a .txt file extension.

  3. Again, philosophically, this makes little sense to me. What you regard as making as few assumptions as possible is what I regard as carelessness (I don’t mean this as a personal attack). Again, this has been pointed out before by others ( Philosophically, I think you have some level of responsibility to verify malicious file extensions before upload that trumps your commitment to a general purpose tool.

At any rate, I doubt we will reach full agreement on these issues. However, I do appreciate your response and your willingness to interact on these matters.

Hi @Callahan,

Just a note on sanitization of PHP uploads – that does appear to be the case:

…but I think that probably dates to the first introduction of that class, before our current approach to security was particularly matured. This alone isn’t trustworthy, obviously.

Alec Smecher
Public Knowledge Project Team