• Resolved ellmann creative

    (@ellmanncreative)


    Today, I have received a report about a severity 6.1 vulnerability in the plugin “WC Ajax Product Filters”.

    However, the link given under “Vulnerability Information” results in a “404 Page Not Found” on wordfence.com. The exact link is: https://www.wordfence.com/threat-intel/vulnerabilities/id/530dc336-e961-462a-ad7b-ac46fa3d953a?source=plugin

    I checked the Wordfence vulnerability database, but I can’t find this plugin in the database at all.

    What’s going on?

Viewing 7 replies - 1 through 7 (of 7 total)
  • Hi @ellmanncreative. I’m just a user like you, so I’m just sharing what I find. If you take a look at the “scanner” json file, that id does show up there. It gives a slug of wordpress.org/plugins/wc-ajax-product-filter/, which does work, and says:

    WooCommerce Ajax Product Filter <= 5.1.0 – Reflected Cross-Site Scripting

    For whatever that’s worth.

    Thread Starter ellmann creative

    (@ellmanncreative)

    @mike80222 Yeah, and thanks for looking into it.

    Interesting. Since I don’t know which file that is, can you please take a look and confirm that it says “<= 5.1.0”? The latest version of the plugin is 4.2.0, and I currently have 4.1.0 installed. Might it be saying “<= 4.1.0” instead?

    Also, https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/wc-ajax-product-filter/ does not exist – it should, if there are CVEs registered for it.

    I’m not sure what to make of this. WordFence’s vulnerability websearch consistently returns a 500 error, so I can’t even tell if the plugin exists in the DB under a different slug or something.

    It’s interesting however, that the one I have is named “WC Ajax Product Filters”, while the one on wordpress.org is “WCAPF – WooCommerce Ajax Product Filter”. Same slug. I also have it on a different site, and there it’s version 4.2.0 – but still “WC Ajax Product Filters”…

    Thread Starter ellmann creative

    (@ellmanncreative)

    I think I’ve figured it out.

    There are two plugins, sharing the same slug – one provided by wordpress.org, the other – by the theme I’m using (Goya).

    The one provided by Goya seems to be a branch of the official one, split at version 2.0.3 – right before the “Pro” functionality (and the associated “buy pro!” option) was introduced. While the official (public repo) plugin went on to become v3.0.0 in its changelog (and is now v4.2.0), this one’s next (and last mentioned) revision is a maintenance release 2.0.3.1 that seems to backport some fix or another; the version it’s reporting to WordPress is v4.2.1.

    This plugin looks mighty fishy, and I’m not sure what Goya is doing here. It’s clearly a “mistaken identity” situation, except not quite? It is the same plugin… only a much, much older version of it, and it just so happens to share the same slug. I can see how WordFence would be confused by it.

    Interesting. Since I don’t know which file that is …

    @ellmanncreative, You can download the files here:

    https://www.wordfence.com/api/intelligence/v2/vulnerabilities/scanner
    https://www.wordfence.com/api/intelligence/v2/vulnerabilities/production

    And then search for the id. Beyond that, your guess is as good as mine 🙂

    Plugin Support wfpeter

    (@wfpeter)

    Hi @ellmanncreative and thanks @mike80222 for your input.

    Apologies for the confusion here, the particular link that was failing as a 404 had been set to scanner-ready prematurely, although we can confirm the issue is covered by existing firewall rules so there should be no further action required at your end.

    Thanks,
    Peter.

    Thread Starter ellmann creative

    (@ellmanncreative)

    @wfpeter

    Not quite.

    Thank you for letting me know about the 404, that was a puzzler.

    As for the plugin itself: I have received confirmation that it is indeed an early fork of the plugin available on the WP repository. I was told it’s now in a major way a very different plugin, however. They (i.e. the theme and plugin developers) are also reluctant to change the slug due to the negative impact it would have on existing installations.

    I’m sure this isn’t the only example of such situations in the wild. It would mean that this issue is a “false positive” that’s bizarrely not exactly unrelated. How does WordFence deal with such naming conflicts? I mean, I’m sure it’s not the only plugin out there that happens to share a slug with something that exists in the public repo?

    As an aside – does WordFence track when any given vulnerability was introduced? It would be possible to set manual exclusion rules for such situations, when the precise split-off version is known. In this particular case, if the issue was introduced after v2.0.3 – it’s likely that this “sister plugin” isn’t actually affected.

    Thread Starter ellmann creative

    (@ellmanncreative)

    Well, I’m marking this one as “resolved”. Whether WordFence does anything to detect similar situations in the future is now a matter of their policy, I suppose. Good luck. 🙂

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Vulnerability reported for a plugin, but link is 404 and the plugin is not in DB’ is closed to new replies.