Gambling commercial inside PHP library used by OJS

[hleonar]

Hello PKP team,

I’d like to report a serious security and reputation concern I discovered while auditing my OJS installation, I’m using ojs 3.5.1 now.

During a system-wide scan for injected keywords like “birototo”, “slot gacor”, and “video slot”, I found that the following file inside the default OJS vendor directory contains hidden links to gambling websites: /lib/pkp/lib/vendor/nesbot/carbon/sponsors.php

Here are a few lines from the file:

‘name’ => ‘Non Gamstop Casinos’,
‘description’ => ‘Casinos not on Gamstop’,
‘website’ => ‘https://www.slotozilla.com/nz/free-spins’,

This file also references other gambling-related domains such as:

• slotozilla.com

• onlinekasyno-polis.pl

• zonaminecraft.net

While this file belongs to the nesbot/carbon package (a Laravel date-time library), it raises major concerns because:

1. It resides within the OJS vendor directory (lib/pkp/lib/vendor/).

2. It may cause search engines (e.g., Google) to index OJS journal URLs along with gambling keywords.

3. It poses a reputation risk for academic institutions using OJS.

Although this file is not directly executed by OJS, it is still problematic because:

• The file is publicly accessible if the server doesn’t block access to /lib/.

• It contains outbound links to gambling and potentially harmful sites.

• It might contribute to unwanted search index contamination (SEO spam)

Steps to Reproduce:

1. Navigate to your OJS installation directory.

2. Run:

   grep -Rni "slot" lib/pkp/lib/vendor/nesbot/carbon/
   

3. You’ll find the gambling-related sponsor definitions in sponsors.php
   

[navotera]

Great finding @hleonar

Although this is not related to PKP team, and I believe that PKP does not have any intention to add this file to the OJS, as it was added automatically using Composer.

However, woow…this is a very interesting finding, it seems like online gambling has become a global phenomenon, and they dare to sponsor an open-source project like Carbon.

Check the gambling company contribution here :
https://opencollective.com/Carbon

I believe this will be removed in the next release of OJS.

Regards
Hendra

[jonasraoni]

Hi!

It’s not feasible for us to micromanage what’s included in 3rd-party packages, so depending on how you’re managing your installation, besides the vendor folder, you might find curious content in the node_modules and plugins that include 3rd-party Composer packages.

This problem should be addressed by this discussion:

https://github.com/pkp/pkp-lib/discussions/8114#discussioncomment-14529100

On our side we’re removing a couple of files when building the release packages, which you may see here (this file that you found should be included as well):

https://github.com/pkp/ojs/blob/main/tools/buildpkg.sh#L40

For now, given the nature of a PHP web server, it would be also nice to have an automated script looking for files that have executing code instead of just declarations (interfaces/classes/etc).

On your side it might be interesting to block access to the files mentioned on the link above.
Perhaps (I’ll do an internal check later, but it should be ok, unless we’re exposing something publicly there using the real URL) the whole lib/* folder can be blocked.

Best,
Jonas Raoni

[asmecher]

Hi all,

The fact of gambling websites sponsoring FOSS libraries isn’t a problem we need (or want) to solve. For example, we also use Smarty as a templating system, and the Smarty website lists a lot of gambling websites as sponsors of the project.

@hleonar, the code you point to (sponsors.php) is used to maintain the readme.md document also shipped with that library. In itself, the sponsors.php script does not generate any output.

It’s possible that search engines could index the readme.md document. It is one of almost 600 Markdown documents included in the lib/pkp/lib/vendor directory containing a mixture of changelogs, documentation, credits, etc.

I don’t believe Google indexes markdown content, so even if someone were to link to these documents in order to e.g. improve SEO, I’m not sure it would be effective.

Long story short, I don’t think there is a short-term problem that needs to be solved here, and as @jonasraoni points out, a long-term change will implicitly move this content out of the web root.

For folks who want to mitigate a perceived risk, you can always use a .htaccess file to prevent direct access to content in lib/pkp/lib/vendor.

Regards,
Alec Smecher
Public Knowledge Project Team