search

10up / wpcli-vulnerability-scanner

WP-CLI command for checking installed plugins and themes for vulnerabilities reported on wpvulndb.com
MIT License
274 stars 40 forks source link

introduced_in field not working as designed #59

Closed TheLastCicada closed 2 years ago

TheLastCicada commented 2 years ago

Jozsef Kozo performed the following tests and has this report:

So there is a vulnerability in the sassy-social-share that was introduced in 3.3.23 and fixed in 3.3.24.

If I test the with the latest available version(3.3.25) the “introduce in” and the “fix” column shows the expected results, however, the scanner plugin marks as a vulnerable plugin. 


| name                        | installed version | status                                                               | introduced in | fix             |

+-----------------------------+-------------------+----------------------------------------------------------------------+---------------+-----------------+

| sassy-social-share          | 3.3.25            | Sassy Social Share 3.3.23 - Missing Access Controls to PHP Object In | 3.3.23        | Fixed in 3.3.24 |

[jkozo@24793d5e921f wp-content]$ wp vuln plugin-status --porcelain

sassy-social-share

I think the scanner plugin logic is wrong here, it shouldn’t mark as a vulnerable plugin.

On the other hand, if I test with a non-vulnerable lower version one, the “introduced in” and the “fix” columns are empty.


| name                        | installed version | status                                                             | introduced in | fix |

+-----------------------------+-------------------+--------------------------------------------------------------------+---------------+-----+

| sassy-social-share          | 3.3.20            | No vulnerabilities reported for this version of sassy-social-share | n/a           | n/a |

Our scanner should report a plugin as vulnerable if the installed version is between the version numbers in "introduced in" and "fix". This is a pretty serious problem with the scanner to have this logical problem. If the version number is not in that range, it should not be flagged as vulnerable.

jeffpaul commented 2 years ago

@TheLastCicada @kojraai noting that we're blocked on developing against this until we can source an API token. If someone can provide that to me privately, then that will unblock @rahulsprajapati's work on this... thanks!