Recurring SEO-cloaking malware re-injection on OJS 3.5.0-4 — appears to be a server/root-level compromise

Software Support
1

  1. Cloaking injected into core files. Two functions — is_google_bot() and a payload function aselolejos() — are inserted at the top (lines ~2–6) of:

    • lib/pkp/includes/bootstrap.php
    • lib/pkp/lib/vendor/autoload.php
    • lib/pkp/lib/vendor/composer/autoload_real.php
    • pages/index/index.php and the root index.php

    The payload function fetches gambling-spam HTML from a raw.githubusercontent.com URL and serves it only to Googlebot (Indonesian gambling keywords — “matauangslot”, earlier “NONO4D”). Exact URL/hashes available on request.

  2. Web shells / a full file-manager dropped into OJS directories:

    • templates/vendor/ — a complete PHP file-manager app (app/, config/, data/User/admin|demo|guest, etc.)
    • a ~750KB jottings/index.php at the web root
    • shells in tools/, templates/vendor/app/controller/utils.php, and plugins/paymethod/paypal/locale/hsb/less.php/css/index.php

  3. Outage: the host’s scanner (Imunify) partially “cleaned” the injected functions, leaving duplicate declarations across the core files → PHP Fatal error: Cannot redeclare aselolejos() → whole site 500s.

Why it keeps coming back (looks like more than an account compromise):

  • Removed files reappear within minutes.
  • A root-owned binary /usr/local/bin/filebrowser runs as a per-account daemon and respawns under a new PID after being killed — which a non-root account can’t do.
  • It survived a server-node migration and a full credential rotation.
  • The attacker repeatedly re-adds themselves as a verified Google Search Console owner (by dropping google-site-verification files).

What we’ve already done: restored the injected core files from the official 3.5.0-4 package and chmod 444’d them; added .htaccess (Require all denied for *.php) in public/, cache/, templates/; rotated all credentials; deployed monitoring; and put the site behind a Cloudflare block. Planning a clean migration to a VPS with a fresh OJS install.

Questions:

  1. Are there known OJS 3.5.0-x or common-plugin vulnerabilities allowing arbitrary file write to templates/, tools/, or pages/ that could be the entry vector? Anything specific to check or patch?
  2. Recommended OJS hardening (shared and VPS): file permissions, securing or removing tools/, locking templates/, files_dir placement.
  3. Has anyone seen this exact campaign (aselolejos / is_google_bot / matauangslot, payload from a GitHub raw URL)?
  4. Best practice for a clean DB + files_dir migration so no reinfected code carries over.
2

Hi @latha_ojs,

I’m not aware of any vulnerability in up-to-date releases of OJS that would explain this, and we’re not seeing it more broadly, which I would expect if there was an issue. As always, I’ll keep an eye out.

I’d recommend a “clean-room” rebuild of your web root, where nothing is copied over without a complete review, and all credentials are reset. As much as possible, do not rely on your existing web root contents, but instead on the original sources. In particular, we’ve seen old issues used to build an escalation chain that leads to creating a new admin account (e.g. via the user import plugin), or to install a new plugin introducing arbitrary code. Both of those paths can lead to backdoors being installed. All known pathways to do that have been solved in current releases, but it’s easy to inadvertently carry them along when rebuilding/upgrading if you’re copying paths from your old installation directory into your new one.

At a glance, the presence of /usr/local/bin/filebrowser can be a legitimate installation. Check to see if File Browser Quantum is supposed to be on your server.

While it is possible that there’s been an escalation to root – and there have been a few publicized flaws in Linux that could explain it – I do consider it unlikely. It’s more likely that an old backdoor has been inadvertently carried into the new installation.

The OJS Admin Guide is the best resource for configuration and hardening.

Regards,
Alec Smecher
Public Knowledge Project Team