Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Janis Elsts

    (@whiteshadow)

    If you follow the “References” link in that report and then find the “Plugin page” link, you will see that the report is actually about a different plugin that, unfortunately, happens to have the same name as this one. The report does not apply to this plugin.

    Thread Starter eLeXeM

    (@elexem)

    ugh. Please accept my apologies for missing that.

    I’m rather fond of your Admin Menu Editor. ??

    Paul

    (@paultgoodchild)

    @elexem , @whiteshadow
    That’s a strange one! Ideally our Shield plugin shouldn’t be reporting that falsely. Sometimes with plugin slugs, looking up vulnerabilities can return erroneous results when plugin slugs get mixed about, but we’ll definitely take a look into this and see whether we can figure out the root cause of it to prevent it reoccurring.

    My suspicion is that the original plugin with the vulnerability has been since closed, and so look-up using the plugin slug is getting a little confused as the original plugin no longer exists and so the plugin API won’t offer it.

    Sorry for the trouble to both of you with this! And particularly to you, @whiteshadow – it’s certainly not our intention to indicate to folks that your plugin has vulnerabilities when it doesn’t!

    Paul

    (@paultgoodchild)

    @elexem , @whiteshadow
    A quick follow-up on this. We’ve identified the problem and it’s now been fixed… this should hopefully not happen again. If something does crop up at any point in the future, however, please do feel free to reach out to us and make us aware that something’s not being correctly reported.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Reflected Cross-Site Scripting (XSS) vulnerability’ is closed to new replies.