https://www.radiomariasp.org/
WFRM-ITStaff opened this issue · comments
Good morning,
The WPMUDEV Defender Pro Security Plugin has identified the following risk:
Progress Bar
Vulnerability found in 2.2.0.
Issue Details
CVSS Score 6.5
#WordPress Progress Bar plugin <= 2.2.0 - Cross Site Scripting (XSS) vulnerability
-Vulnerability type: Cross Site Scripting (XSS)
-No Update Available
Please inform us if there is a security update to fix it.
Can you be specific about where the XSS vulnerabilities are? The last update added sanitization to all areas where user-submitted code could be entered.
Thanks. An XSS attack happens when code is injected into something benevolent by a bad actor, e.g. <img src="<script>alert('you have been hacked');</script>" />.
In WordPress (and in raw PHP), there are functions that strip out any non-text characters, among other things. That was part if what the 2.2.0 update added. Beyond that, in WordPress, some actions (like adding a shortcode) require elevated permissions (e.g. logging in as an editor), which alleviates the vulnerability because in order for it to be a vulnerability at all, you already need to have access to the WordPress admin. That is the case for the Progress Bar plugin, since you already need to be at least an editor capable of creating a post to add a progress bar shortcode or widget.
I suspect this is a false positive like the scan suggests. Sometimes, vulnerability scanners like this look for the vulnerability separate from their WordPress context and ignore the escalated privileges required to make the vulnerability actually a vulnerability. However, to be on the safe side, I will look into integrating with a vulnerability scanning service (Patchstack) to ensure I'm not missing anything.
Besides applying for the managed Vulnerability Disclosure Program for plugins from Patchstack, I've also implemented a simple scanner using the WordFence API via the 10up Vulnerability Scan WP-CLI plugin and made that one of the things that trigger on all code pushes. It's currently reporting no vulnerabilities, but I don't know how deep those scans go.
Again, I think this is a false positive. In order for there to be an XSS attack, you'd already need access to the WordPress admin because there's no other content that could be manipulated (I suppose someone could, theoretically, manipulate the content CSS parameter in the browser, e.g. adding a script to the content: "", but that would just attack yourself, so I don't think that's a relevant attack vector). I'm happy to be proven wrong and fix anything that's exposed that I'm unaware of, but I'm not seeing anything that would be relevant.
I'm going to close this for now, but if you are able to provide more specific details about the detected vulnerability, feel free to re-open. I'll definitely be monitoring this more in the future, so, even though it may be a false positive, I very much appreciate the report.