ethicalhack3r

@hallsofmontezuma what version was this fixed in? We couldn’t see anything in the changelog.

@angelika Reisiger – well spotted! no wonder we missed them! We’ll have to keep an eye out for this in the future.

@gdavide – I searched for the git commit but couldn’t find it. I have contacted the researcher to ask for further details but have not heard back. If you have the time and will it would be very helpful if you found the commit 🙂

I can see how that would get annoying. For us, and probably for most users, the first thing we check when we come across an old vulnerability is the plugin’s changelog.

If the fix is mentioned in there, we take the plugin developer’s word for it, if it is not in there we will try to contact the developer or reproduce ourselves.

Maybe mentioning them as fixed (the ones that have been) in the changelog would prevent a lot of users from getting to the stage where they email you for further information?

Sent LayerSlider devs a tweet asking for further info – https://twitter.com/_WPScan_/status/645509398295658496

@aitpro

Thanks for the information, added the fixed in to the vulnerability – https://wpvulndb.com/vulnerabilities/7637

Your changelog hosted on ww.wp.xz.cn seems to have an issue and it is cut short, I downloaded the plugin and couldn’t find a changelog file in there from a quick look. We use the changelog as a source of information to identify fixed in information.

Comparing version numbers without using the ‘fixed in’ information would lead to a lot of false negatives. Some developers leave issues unfixed for multiple versions, some never fix at all.

Scanning the plugin’s code using static code analysis would also create a lot of false negative and false positive reports.

Look at the current best freely available PHP Static Code Analysis tool, RIPS, and you will see that static code analysis needs human interpretation to properly identify vulnerabilities.

Not just any human interpretation either, but someone quite familiar with PHP and has a good understanding of software security. This is not realistic for the average WordPress user.

Our solution (wpvulndb.com) may not be perfect, but we believe it is the current best way to record and distribute this information. And all for free! (for non commercial users)

We are constantly adding new issues and updating old ones with new information.

Hi,

Ryan from wpvulndb.com here. What version was this issue fixed in?

We couldn’t find any mention of it in the plugin’s change log.

Once we know the version we can update our entry and mark it as being fixed.

Thanks,
Ryan

No problem! 🙂

We’ve made it easier for ourselves to spot the missing fixed in information on our end so hopefully we’ll see a decrease in False Positives going forwards.

All In One WP Security & Firewall – https://wpvulndb.com/plugins/all-in-one-wp-security-and-firewall – all show as fixed in our database

Dynamic Widgets <= 1.5.1 – Cross-Site Scripting (XSS) – https://wpvulndb.com/vulnerabilities/6278 – added fixed in

Enable Media Replace <= 2.3 – Multiple Vulnerabilities – https://wpvulndb.com/vulnerabilities/6432 – added the fixed in tag

Media File Renamer <= 1.7.0 – Persistent Cross-Site Scripting (XSS) – https://wpvulndb.com/vulnerabilities/7135 – added fixed in tag (may not be accurate as author does not know when the issue was fixed although confirmed it does not affect the latest version)

WP RSS Multi Importer <= 3.11 – Cross Site Request Forgery (CSRF) – https://wpvulndb.com/vulnerabilities/7546 – added fixed in

We don’t yet have a good system in place for reporting issues such as these. We currently rely on adhoc feedback like this to fix any missing data from our databases. We do have our contact details on https://wpvulndb.com/contact which will get through to us for now. If anyone has a some good suggestions on allowing this kind of information to be fed back to us we would be more than happy to listen.

Any questions/comments let me know! Also, thanks for the heads up! 🙂