Found an exploit in a really old Wordpress plugin...

[trparky]

I was browsing through the Wordfence Web Application Firewall log of my Wordpress site, and I found something interesting. Thankfully it was blocked by Wordfence so that's good—it never did any damage to my site. I don't even have the plugin installed on my site so again, good.

However, I digress—I found an exploit in an old Wordpress plugin. So old that it doesn't seem that Wordpress even lists it as a plugin to be installed. Thankfully.

However, the plugin does exist. I found it on Github and after a little bit of investigation, one of the files in that plugin is indeed vulnerable to that very exploit. A path traversal exploit. There's no input validation or cleanup before passing it to a PHP read() function.

What do I do with this knowledge? Is there a possibility that sites out there have this plugin installed and are vulnerable to this exploit?

Obviously, I don't want to publish this exploit or the name of the plugin publicly since well... duh. But what do I do? I have no idea how to responsibly disclose this vulnerablity.

 

[Mindweaver]

Since it's on Github then I would report it to Github. Hopefully they will at least take it down which would be a big step in the right direction.

 

[Assimilator]

Is the plugin still maintained at all? If so create an issue in their GH that explains you've found a vuln and asks for a direct non-public contact to reach out to, in order to detail it so they can fix it.

If it's abandoned then not much you can do, and if it's old enough to be abandoned it's really on the people using that plugin to stop using abandonware.

 

[bug]

Maybe check the NIST database first, chances are it's reported already: https://nvd.nist.gov/vuln/search

Other than that, what @Assimilator said.

 

[trparky]

Someone suggested that I disclose it to PatchStack. I've done just that.

 

[trparky]

One day I was looking through my Wordfence access logs and came across a weird looking URL… https : // www . toms-world . org/blog/wp-content/plugins/apptha-slider-gallery/asgallDownload.php?imgname=../../wp-config.php

Thankfully, I don’t have that plugin installed into my WordPress installation. You’re going to find out why I said “thankfully” in a moment.

The reason I started looking into this was because the log just looked… funny, weird. Something just didn’t smell right. So, I began doing some looking around on Google and lo and behold, I found a plugin for WordPress named Apptha Slider Gallery on GitHub. I then looked into the exact file name that the… not so good smelling URL referenced. The code is as below…

<?php
/*
***********************************************************/
/**
* @name : Mac Doc Photogallery.
* @version : 2.5
* @package : apptha
* @subpackage : mac-doc-photogallery
* @author : Apptha – [URL]http://www.apptha.com[/URL]
* @copyright : Copyright (C) 2011 Powered by Apptha
* @license : GNU General Public License version 2 or later; see LICENSE.txt
* [USER=105671]@Abstract[/USER] : The core file of calling Mac Photo Gallery.
* [USER=173468]@Creation[/USER] Date : June 20 2011
* @Modified Date : September 30 2011
* */

/*
***********************************************************/

/*The Common load file for the plugin */

require_once( dirname(__FILE__) . ‘/asgallDirectory.php’);

$timg = $_REQUEST[‘imgname’];
$pluginname = ‘apptha-slider-gallery’;
$file = dirname(dirname(dirname(__FILE__))).”/uploads/”.$pluginname.”/”.$timg;
header(‘Content-Description: File Transfer’);
header(‘Content-Type: application/octet-stream’);
header(‘Content-Disposition: attachment; filename=’.basename($file));
header(‘Content-Transfer-Encoding: binary’);
header(‘Expires: 0’);
header(‘Cache-Control: must-revalidate, post-check=0, pre-check=0’);
header(‘Pragma: public’);
header(‘Content-Length: ‘ . filesize($file));
ob_clean();
flush();
readfile($file);

//}
?>

Immediately upon reading that code I had a major face-palm moment.

If you need a clue as to why I had a face-palm moment, take a look at the line that reads “readfile($file);”. The variable $file chiefly gets its value from $_REQUEST[‘imgname’] ( well, ok... $file = dirname(dirname(dirname(__FILE__)))."/uploads/".$pluginname."/".$timg ), however, as you can see, they just concatenate the value of $timg onto the $file variable and… there’s absolutely no user input validation!!! Not even a simple call to basename() to make sure that an attacker can’t do something stupid like “../../../wp-config.php”. A simple call of basename() could have put a stop to this major vulnerability.

They do perform a call to basename() when they declare the "Content-Disposition: attachment" HTTP Header so they knew that calling basename() was a good idea but why the hell didn't they make a call to it in the most important place ever!?!?

But I digress…

I looked about the Internet and began asking about how I can report a vulnerability since I’ve never done this before. Someone mentioned Patchstack so I opened a chat on their site and asked how I can get into contact with one of their security researchers. They gave me some contact information and submitted the details of what I found. Low and behold, I get an email sometime later stating that what I found was indeed a major security vulnerability in a WordPress plugin, a path traversal vulnerability. The bad thing is that this plugin is no longer supported by Apptha and God knows how many WordPress installations might have this extremely vulnerable plugin installed.

Fast forward to today and the vulnerability that I found was given a CVE ID of CVE-2025-31050 with a vulnerability rating of 7.5 on a scale of 1 to 10 giving it a severity of High. Not good, scary even.

Note to Moderators
I have done all the right things. I responsibly disclosed the vulnerability, and I held everything back until I knew a public CVE was published. Everything in this post is now public since the CVE is no longer private.