Recently Imunify360 malware researchers received a couple of requests by the community to examine the “Quick Page/Post Redirect Plugin”. The plugin is widely used roughly in ~100k installations. This investigation will expose techniques used by plugins to inject ads passively into websites, in most of the cases the website’s owners do not even know or allow it. It will answer questions made by WordPress' broader community which didn’t have a chance to have proper feedback on forums.

WordPress Community Alerts: Queries Regarding Plugin Security

The following quotes illustrate concerns that are easily found through search engines:

• “Any direction on finding these spam links and removing them?”
• “Yeah, I had that too. Don’t know if it’s this plugin or WordPress that’s to blame.”
• “This plugin is part of an ad network and had a security issue which places Malware on your website. We were getting links appearing on our site from it.”

The plugin is listed in the WordPress repository as of May 29th: 

Suspicious Code Discovery: Identifying Tampered Plugin Code 

The unexpected code was found in the plugin’s sample code.Users claimed it had been installed from a trusted source, the WordPress repository. However, at first glance, It looked like a code injection or tampering upstream. 

We are talking about the following code snippet:

The sample fetches an arbitrary remote payload, which is a potential and passive way to  inject ad content into the website.

Audit Findings: Uncovering Tampered Code

Looking at the WordPress official repository, we can’t find the snippet: https://plugins.svn.wordpress.org/quick-pagepost-redirect-plugin/tags/5.2.3/page_post_redirect_plugin.php

How does the code come in ?

There was a changeset made upstream that committed an updater ability to the plugin, but it was suddenly removed, with records from 4 years ago: Changeset 2474557.

By examining the upstream website, it was possible to correlate the plugin to this link: Anadnet Updates. This version of the plugin includes built-in advertising support and has a feature in the code that updates the plugin itself from their website instead of the WordPress official endpoint.

Fetching the URL above, it ships with a valid JSON that includes a link to a tarball’s plugin/zip file
LINK: https://anadnet.com/updates/?action=get_metadata&slug=quick-pagepost-redirect-plugin

$ curl -s 'https://anadnet.com/updates/?action=get_metadata&slug=quick-pagepost-redirect-plugin' | awk /last_updated/,0It takes to stdout:

The download_url field pulls the tarball 

$ shasum -a 256 tampered/quick-pagepost-redirect-plugin.zip 

SHA256: 19b2c3c07a8bb9601d625964ad520a8f5690bb5860894b354d7c3b59dfb25a68  tampered/quick-pagepost-redirect-plugin.zip

The same plugin with the same version fetched from the WordPress repo 

$ shasum -a 256 wordpress_official_repo/quick-pagepost-redirect-plugin.5.2.3.zip

SHA256: 5bbc032c103275e28e4d12625e2ba3cad0db7308d9a35d4e1097332146f77e31  wordpress_official_repo/quick-pagepost-redirect-plugin.5.2.3.zip

Confirming the plugin’s tag release 5.2.3 between the tampered branch and the wordpress_official_repository:

$ grep -rnP 'Version:\s*[\d\.]{4}' tampered/ wordpress_official_repo/

It correlates the changes using the diff(1) tool, and it is possible to find the unexpected ads ability at filter_the_content_in_the_main_loop():

$ diff -uNp wordpress_official_repo/quick-pagepost-redirect-plugin/page_post_redirect_plugin.php tampered/quick-pagepost-redirect-plugin/page_post_redirect_plugin.php > patch.diff

The code differs between the same release/version, which is not a good releasing practice. The plugin has been passively moved to another tampered “version,” which includes its own proper updater and advertising code.

Although the plugin’s developer implicitly states in the code through the ppr_add_notice(), it is not clear to users how the plugin has been modified

In the release cycle, clarity in the code is a critical standpoint to open-source projects. Even if the project is not fully open-source, releasing a new feature or update must be properly documented in a changelog , including all changes in a new branch.  If there’s a different version distributed upstream with free/pro licensing models, it is essential to bump a new release with proper naming/tags.This allows the user base to follow the changes and decide whether to accept the ads trade-offs or stick with the older ad-free open-source version.

In the WordPress repository, the version from >=5.2.3 doesn’t include the advertising code.

However, considering the upstream history and release practices, switching to an alternative plugin might be safer and more appropriate.

Subscribe to our blog to stay updated on the latest security news and updates. If you haven't tried it yet, check out Imunify360 for comprehensive server security.