Security issue: Hacking via submission in OJS 2.4.8

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

Thanks, Alec, for checking into that.


My journals website was also hit today,

I followed your instructions above and moved the files directory outside the webroot and configured the Config file to read it.

but the problem still there
here is my weblink for one of the journals in that website the rest are giving the same problem (blank screen)

Please advice me

Hi @yasser,

Once your server has been accessed by a hacker, it’s good policy not to trust anything on it. As usual, your PHP error log will probably indicate an error message that corresponds to the blank page, but I would suggest either replacing your OJS code with a fresh copy (and reviewing everything that you haven’t replaced), or using a standard tool like diff to compare your installation against the stock version of the same release.

Alec Smecher
Public Knowledge Project Team

thanks… i could return the system back to work, i found that the Hacker could delete some sub-folders plus the Cash folder, i got them back from the backup and it works fine now,
now i have to find out how could he reach that far to delete these folders
is there any help to find out?

Hi @yasser,

Cleaning up after a security incursion is beyond the scope of this forum, but broadly speaking, it’s good policy not to trust content there. I’d suggest using diff to compare your installation against the stock release of OJS 2.4.8 – there’s too much content there to reliably check by hand.

It’s common practice to leave a PHP backdoor installed after this kind of a break-in, so it’s definitely not safe to trust your setup once you’ve got it working again.

Alec Smecher
Public Knowledge Project Team

Hello @yasser,

Can you please tell which folders and files you upload from backup again. I tried the “cache” folder but problem still continue.


Alec, how about a small web based tool that would scan each OJS site for this vulnerability? People could request their site be scanned and you or a website would email them the results. That way the code or vulnerability is not in the wild.

Hi radjr

There are a myriad of technical and legal reasons why that would not be a good idea. Legally doing a vulnerability scan on someone else’s server is fraught with problems, from checking if the requester has authorization and even with any subsequent opinion on whether a site has passed or is OK. The only person doing a scan of your system should be yourself. Also technically such a system could also itself be abused. The only sure way is to read the README on installation before installing and follow its advice. And trying to blacklist extensions leads to a false security.


A potentially good implementation of this would be similar to the Drupal status report functionality, which checks internally if files paths expected to be private appear to be accessible by HTTP request (at least from itself). This check is, of course, imperfect and could result in a false negative, but would likely catch a number of bad configurations for folks who aren’t reading the documentation and aren’t reading the installation instructions.