Hi Friends
When I open Submissions (as admin) or the admin Dashboard , I get the modal:
Error
In the browser Network tab, the AJAX calls to _submissions return 500 .
Example entries:
lua
CopyEdit
_submissions?status=1&assignedTo=-1&searchPhrase=&count=30&offset=0 → 500 _submissions?status=1&searchPhrase=&count=30&offset=0 → 500 _submissions?status[]=4&status[]=3&...&count=30&offset=0 → 500
If I temporarily turn on debugging in config.inc.php:
ini
CopyEdit
display_errors = On show_stacktrace = On debug = On
…I then see a PHP fatal (from the failing request):
php
CopyEdit
Fatal error: Uncaught RuntimeException: Unexpected data in output buffer. Maybe you have characters before an opening <?php tag? in /lib/pkp/lib/vendor/slim/slim/Slim/App.php:621 Stack trace: #0 /lib/pkp/lib/vendor/slim/slim/Slim/App.php(317): Slim\App->finalize() #1 /lib/pkp/classes/core/APIRouter.inc.php(115): Slim\App->run() #2 /lib/pkp/classes/core/Dispatcher.inc.php(144): APIRouter->route() #3 /lib/pkp/classes/core/PKPApplication.inc.php(360): Dispatcher->dispatch() #4 /index.php(68): PKPApplication->execute()
With debugging Off , the modal returns and the requests are 500 again.
Hi @Alnasser ,
Would you mind indicating what specific version of OJS you’re using (e.g. 3.3.0-13)?
-Roger
PKP Team
The OJS version is
3.3.0.21
I think there is a security vulnerability related to uploading files in the form of submissions, through which the hacker was able to display this error, as well as delete the previous files published in the first volume of the journal.
Hi @Alnasser ,
What is the value of your files_dir setting in the config.inc.php configuration file?
Regards,
files_dir = “/home/xxxxxxxxxxxxx/domains/ujbatm.urnammuacademy.org/filesxxxxx”
Today, again same problem.
this happen when person visit my website, which i know using the flag counter.
Hi @Alnasser ,
Is that directory inside the web root (in other words, are its contents web-accessible if someone can guess the URL)? If so, that’s a dangerous configuration and would explain how your server got hacked. There are warnings about this in the installation form, configuration file, and in our various related pieces of documentation.
Regards,
To solve this, I upload the lib files from original version the the ojs work again? what is your suggestions?
Hi @Alnasser ,
How to cleaning up a backdoored application is a general web admin question, so you might find good advice on e.g. StackOverflow. But there are some recommendations here:
Hi @srht ,
Earlier releases of OJS 3.3.0-x were vulnerable to some stored XSS attacks, and we’ve heard reports that these have been used to escalate privileges via stored Javascript that gets presented to the manager or site admin. We’re not aware of any of these vulnerabilities in OJS 3.3.0-20 – but here are a few things to check if you did suffer a hack on a previous release.
Some of this would apply to any PHP application, and you might find other helpful info on e.g. StackOverflow.
If you…
Hi @Jon ,
The orthodoxy in dealing with a potentially defaced site is not to trust any of the contents, even if it looks like the hack was never properly invoked.
I would suggest using the standard diff tool (or similar) to compare your codebase against the official OJS 2.4.8-3 release, e.g.:
diff -u -r -N /path/to/unpacked-ojs-2.4.8-3 /path/to/your/ojs_installation
Review the diff to see what has been introduced, watching in particular for unexpected new PHP files and weird-looking additions…
Hi @tecnicouncoma ,
If a rootkit was installed, then you won’t be able to trust the contents of your web root. It’s possible that additional PHP code was introduced there.
The parts of OJS that live in the web root are the source code, configuration file, and public directory. The source code will not be carried across with an upgrade to 3.3.0-20, so you’ll be starting clean there. Review the configuration file and contents of the public directory and ensure they are legit (e.g. free of executa…
Hi @Alice ,
If you can move the files directory outside of public_html (or whatever the equivalent is on your server), and configure config.inc.php to point to its new location, that’ll prevent new malicious attempts to break in.
However, it sounds like someone has already used this to break in and edit files on your server (to add spam to the scripts). They have likely done this by installing a backdoor script somewhere in public_html, and you’ll need to make sure that is gone.
Cleaning up af…
Regards,
asmecher
August 25, 2025, 3:00pm
9
This topic was automatically closed after 12 days. New replies are no longer allowed.
