Hello everyone,<\/p>\n\n\n\n
A while back, when I was hunting on a private program on HackerOne. Let’s call it redacted.com<\/strong>. I saw it was using WordPress CMS at redacted.com\/blog\/<\/strong><\/p>\n\n\n\n I performed ffuf<\/a> scan with my custom WordPress plugin wordlist and found some interesting plugins. One of which was JH 404 <\/a>Logger<\/a> plugin. Being a PHP enthusiast, I quickly downloaded WordPress and extracted it to my Apache httpd server directory, and started the server. Then I installed the JH 404 Logger plugin on it.<\/p>\n\n\n\n Then I checked what it really does and what are its functionalities. It is a simple plugin to record the visits at 404 URLs with their paths and counts and displays that on the WordPress dashboard but the catch is, it doesn’t sanitize the path of 404 URL which I found by reviewing the source code of the plugin. Quickly created a report and sent it to that private program. But guess what, they marked it as Informative. Cause it wasn’t in their scope. But it was never mentioned in their scope that redacted.com\/blog is not in scope. They only mentioned blog.redacted.com is not in-scope in their policy. Moving ahead then I thought to report it to the developer of this plugin. But he never responded back to me even after several tries. So then, I reported it to the WordPress team but they said due to a high number of reports every day I won’t receive any further communication regarding this. Then I reported this vulnerability to wpscan<\/a> and in no time they verified and assigned a CVE id CVE-2021-24176<\/a> to it.<\/p>\n\n\n\n That’s how I got my first CVE.<\/p>\n\n\n\n
So, I immediately created a 404 URL with the payload –<\/p>\n\n\n\nhttp:\/\/localhost\/blog\/non_existing_path'\"><img src=qw.jpg onerror=alert(0)>'<\/code><\/pre>\n\n\n\n
I tried explaining even though redacted.com\/blog is not in scope, but still, this vulnerability impacts the main domain redacted.com<\/strong> which is in-scope. As because of this vulnerability in this plugin an attacker can perform stored XSS and they weren’t even using httponly<\/strong><\/em> flag on their auth cookie. It can allow an attacker to steal the victim’s cookie or execute any arbitrary Javascript code. But they kept denying this and never accepted it and guess what they are still using this plugin at redacted.com\/blog<\/strong><\/p>\n\n\n\n