Urgent: Security Breach / Hacking Incident - [tadabbur journal]

Software Support
1

Support Message

Subject: Urgent: Security Breach / Hacking Incident - [tadabbur journal]

Describe the issue or problem:

Subject: Urgent: Security Breach and Malicious Redirect on my OJS Site

Message: Hello, my website [https://tadabburmag.sa/index.php/tadabburmag/ar\] has been compromised. It is being redirected to an Indonesian gambling site (salt777). I have detected malicious PHP files and backdoors injected into my directories.

I am using OJS 3.5.0-3. Please help me with the following:

  1. Scan my account for malicious scripts and “backdoors”.

  2. Check the server logs to identify the entry point of this hack.

  3. Verify if the .htaccess file or DNS settings have been tampered with

Steps I took leading up to the issue:

  1. Navigate to the journal URL: [ https://tadabburmag.sa/index.php/tadabburmag/ar\]

  2. Attempted to log in using admin credentials.

  3. Noticed [specific error or change, e.g., “Access Denied” or “Malicious script warning”].

  4. Checked the file directory and found [mention any strange files if you saw them].

  • Version: [e.g., OJS 3.5.0-3] (Check your version.php file if you can’t log in).

  • Hosting: [hostinger].

Additional information:

  • Date of discovery: [11-1-2026]

moustafa mahmoud

2

Hi @tadabburmag,

What is your files_dir (in config.inc.php)?

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like
3

Thank you for the critical insight. I have confirmed that my “files_dir” was indeed configured insecurely inside public_html. I am currently moving it to a secure location outside the web root as advised.

Beyond fixing this path and upgrading the OJS version, could you please provide a checklist or any specific recommendations for “hardening” my OJS installation?

I want to ensure all backdoors are closed and prevent any future recurrence.

Best regards,

4
  • check your folder permission it should be 755 for folder and 644 for files
  • Upgrade to Latest Version,
  • make sure your files_dir is outside of web_root
  • cek the databases for user_groups role= 1 make sure just only one user withs this role
1 Like
5

See https://docs.pkp.sfu.ca/admin-guide/en/securing-your-system#security-checklist

1 Like
6

Hello PKP Community,

​I am writing to seek urgent advice regarding a persistent security breach in our journal (OJS version 3.4.0.8).

​The Issue:

Despite performing a clean upgrade and securing the server, an attacker repeatedly manages to upload a Google Site Verification HTML file (e.g., google[random_chars].html) directly into the public_html root directory. They use this to verify ownership in Google Search Console and hijack our SEO.

​What we have already done:

We have followed the standard security recommendations:

​files_dir: Moved completely outside the web root (public_html).

​Permissions: Reset file permissions (755 for directories, 644 for files). Config file is protected.

​Database: Scanned journal_settings, announcements, and navigation tables for malicious scripts/iframes.

​Passwords: Changed all passwords (Hosting, FTP, DB, OJS Admin).

​Clean Install: We replaced core OJS files with fresh copies from the official PKP website.

​Config: Disabled display_errors and enabled force_ssl.

​The Problem:

Even after these steps, the attacker uploaded the verification file again today. This suggests a hidden backdoor (Webshell) or a vulnerability we are missing.

​My Questions:

​Are there specific directories in OJS 3.x where backdoors are commonly hidden (e.g., inside plugins or public) that we should manually inspect?

​Since the files_dir is secured, could this be an exploit through a specific plugin?

​What specific entry in the Access Logs (POST requests) should we look for to identify the upload source?

​Any guidance or tools to detect this persistent backdoor would be greatly appreciated.

Just to emphasize: We have successfully upgraded to the latest OJS version (3.4.0.8), yet the security breach persists. The attacker is still managing to exploit the system despite the software being up-to-date."

​Thank you.

7

Hi @tadabburmag,

The attack you experienced was likely automated, and you’re probably seeing repeated attacks through an already-installed web shell (as you suspect).

To resolve this, treat everything in public_html as untrustworthy. If you can, move all the contents of that directory somewhere safe (not web-accessible), leaving a totally empty public_html. Then rebuild its contents from “trustworthy” sources – a fresh download of OJS 3.4.0, for example. When you do have to use contents from the old untrustworthy directory, vet them carefully.

This is good general practice for a PHP-based web application; you might find similar recommendations or guidance for Wordpress, Drupal, etc.

Note that OJS 3.4.0-8 is not the latest; at the moment, the most recent 3.4.0-x release is 3.4.0-10.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like