Giter VIP home page Giter VIP logo

wpcli-vulnerability-scanner's Introduction

WP-CLI Vulnerability Scanner

Check WordPress core, installed plugins and themes for vulnerabilities.

Support Level WordPress tested up to version MIT License Functional Tests

Installation

Global command, automatically

It can be installed as a wp-cli package via git repo which is the most preferred way to install.

wp package install 10up/wpcli-vulnerability-scanner:dev-stable

API Access

WP-CLI Vulnerability Scanner works with WPScan, Patchstack and Wordfence Intelligence to check reported vulnerabilities; you can choose any one of these three to use. You will need to add a constant in your wp-config.php to decide which API service you want to use (by default WPScan API will be used).

To use WPScan API:

define( 'VULN_API_PROVIDER', 'wpscan' );

To use Patchstack API:

define( 'VULN_API_PROVIDER', 'patchstack' );

To use Wordfence Intelligence API:

define( 'VULN_API_PROVIDER', 'wordfence' );

Note: Authentication is not required for the Wordfence Intelligence Vulnerability API ( https://www.wordfence.com/wti-community-edition-terms-and-conditions/ ). VULN_API_TOKEN is not required if using Wordfence as your provider.

For WPScan and Patchstack you will need to register for a user account and supply an API token from the chosen API service. Once you have acquired the token, you can add it as a constant in wp-config.php as follows:

define( 'VULN_API_TOKEN', 'YOUR_TOKEN_HERE' );

Global command, manually

Clone this repo, checkout to stable branch and require wpcli-vulnerability-scanner.php from wp-cli config. E.g. in ~/.wp-cli/config.yml [other config locations]

require:
  - /path/to/this/repo/wpcli-vulnerability-scanner.php

Standard plugin

This repo can be installed as a regular plugin. There is no UI, but the command will become available.

wp plugin install --activate https://github.com/10up/wpcli-vulnerability-scanner/archive/stable.zip

After plugin installation, you can verify the command is in place with wp help vuln

Usage

wp vuln status
  • Options:
  • --test Load test data
  • --format=<format> Accepted values: table, csv, json, count, ids, yaml. Default: table
  • --nagios Output for nagios
  • --reference includes the reference link of the vulnerability within the output
wp vuln core-status
  • Options:
  • --format=<format> Accepted values: table, csv, json, count, ids, yaml. Default: table
  • --nagios Output for nagios
  • --reference includes the reference link of the vulnerability within the output
wp vuln plugin-status
  • Options:
  • --test Load test data
  • --porcelain Only print slugs of vulnerable plugins with updates
  • --format=<format> Accepted values: table, csv, json, count, ids, yaml. Default: table
  • --nagios Output for nagios
  • --reference includes the reference link of the vulnerability within the output
wp vuln theme-status
  • Options:
  • --test Load test data
  • --porcelain Only print slugs of vulnerable theme with updates
  • --format=<format> Accepted values: table, csv, json, count, ids, yaml. Default: table
  • --nagios Output for nagios
  • --reference includes the reference link of the vulnerability within the output

Example output

Checking WordPress core, plugins and themes for reported vulnerabilities:

$ wp vuln status

Vulnerability API Provider: Patchstack
WordPress 6.2.2
+-----------+-------------------+-----------------------------------------------------------+---------------+----------+----------+
| name      | installed version | status                                                    | introduced in | fixed in | severity |
+-----------+-------------------+-----------------------------------------------------------+---------------+----------+----------+
| WordPress | 6.2.2             | No vulnerabilities reported for this version of WordPress | n/a           | n/a      | n/a      |
+-----------+-------------------+-----------------------------------------------------------+---------------+----------+----------+
Plugins
+-----------------------------+-------------------+----------------------------------------------------------------------------------------------------------------+---------------+----------+---------------+
| name                        | installed version | status                                                                                                         | introduced in | fixed in | severity      |
+-----------------------------+-------------------+----------------------------------------------------------------------------------------------------------------+---------------+----------+---------------+
| simple-podcasting           | 1.5.0             | No vulnerabilities reported for this version of simple-podcasting                                              | n/a           | n/a      | n/a           |
| woocommerce                 | 7.8.2             | No vulnerabilities reported for this version of woocommerce                                                    | n/a           | n/a      | n/a           |
| wordpress-seo               | 20.2              | Wordpress Yoast SEO plugin <= 20.2 - Authenticated (Contributor+) DOM-Based Cross-Site Scripting vulnerability | <= 20.2       | 20.2.1   | Medium 6.5/10 |
+-----------------------------+-------------------+----------------------------------------------------------------------------------------------------------------+---------------+----------+---------------+
Themes
+-------------------+-------------------+-------------------------------------------------------------------+---------------+----------+----------+
| name              | installed version | status                                                            | introduced in | fixed in | severity |
+-------------------+-------------------+-------------------------------------------------------------------+---------------+----------+----------+
| twentytwentythree | 1.1               | No vulnerabilities reported for this version of twentytwentythree | n/a           | n/a      | n/a      |
+-------------------+-------------------+-------------------------------------------------------------------+---------------+----------+----------+

Using the JSON format:

$ wp vuln status --format=json

{"core":[{"name":"WordPress","installed version":"6.2.2","status":"No vulnerabilities reported for this version of WordPress","introduced in":"n\/a","fixed in":"n\/a","severity":"n\/a"}],"plugins":[{"name":"simple-podcasting","installed version":"1.5.0","status":"No vulnerabilities reported for this version of simple-podcasting","introduced in":"n\/a","fixed in":"n\/a","severity":"n\/a"},{"name":"woocommerce","installed version":"7.8.2","status":"No vulnerabilities reported for this version of woocommerce","introduced in":"n\/a","fixed in":"n\/a","severity":"n\/a"},{"name":"wordpress-seo","installed version":"20.2","status":"Wordpress Yoast SEO plugin <= 20.2 - Authenticated (Contributor+) DOM-Based Cross-Site Scripting vulnerability","introduced in":"<= 20.2","fixed in":"20.2.1","severity":"Medium 6.5\/10"}],"themes":[{"name":"twentytwentythree","installed version":"1.1","status":"No vulnerabilities reported for this version of twentytwentythree","introduced in":"n\/a","fixed in":"n\/a","severity":"n\/a"}]}

Checking any given theme:

$ wp vuln theme-check twentyfifteen --version=1.1

Vulnerability API Provider: Patchstack
+---------------+-------------------+--------------------------------------------------------------+----------+----------+
| name          | installed version | status                                                       | fixed in | severity |
+---------------+-------------------+--------------------------------------------------------------+----------+----------+
| twentyfifteen | 1.1               | WordPress Twenty Fifteen Theme <= 1.1 - Cross Site Scripting | 1.2      | n/a      |
+---------------+-------------------+--------------------------------------------------------------+----------+----------+

Using the JSON format:

$ wp vuln theme-check twentyfifteen --version=1.1 --format=json

[{"name":"twentyfifteen","installed version":"1.1","status":"WordPress Twenty Fifteen Theme <= 1.1 - Cross Site Scripting","fixed in":"1.2","severity":"n\/a"}]

Example usage

Basic

wp plugin update $(wp vuln plugin-status --porcelain)

Will simply error out if there are no slugs returned by the plugin-status command. Can suppress the output by appending &> /dev/null

wp theme update $(wp vuln theme-status --porcelain) &> /dev/null

Scheduled/Cron

0 0 * * * wp theme update $(wp vuln theme-status --porcelain) &> /dev/null
0 0 * * * wp plugin update $(wp vuln plugin-status --porcelain) &> /dev/null

0 0 * * * is everyday at midnight. For assistance creating an alternate schedule, check out http://crontab.guru/. For example, 0 0 * * 1,4 runs at midnight every Monday and Thursday.

With email notifications

Included is a sample bash script, includes/vuln.sh. This can be customized and used in a cron job so that you can be alerted when vulnerabilities are found.

  • WPCLIPATH should be the full path to your wp command. The script will attempt to discover this automatically if the given filename does not exist

  • RECIPIENT should be an email address which will receive the notifications

  • SUBJECT is the email subject

This readme does not discuss configuring the mail command on your server. To run a simple test, try

echo "This is the body text" | mail -s "Email subject" [email protected]

Nagios

wp vuln plugin-status --nagios will give output for Nagios monitoring.

Check uninstalled themes and plugins

Check a specific version of a theme or plugin. Example:

wp vuln theme-check twentyfifteen --version=1.1

Or check several at once (cannot accept versions)

wp vuln plugin-check wppizza wordpress-seo

Running Tests

Prerequisites:

Must have environment variables for VULN_API_PROVIDER and VULN_API_TOKEN

To run tests against WPScan API:

export VULN_API_PROVIDER='wpscan'
export VULN_API_TOKEN='Your API Token Here'

To run tests against Patchstack API:

export VULN_API_PROVIDER='patchstack'
export VULN_API_TOKEN='Your API Token Here'

To run tests against Wordfence Intelligence API, VULN_API_TOKEN is not required:

export VULN_API_PROVIDER='wordfence'

Install dependencies

composer prepare-tests

Note: Not uncommon for composer to run out of memory, you may need to take steps to free up memory on your end

Run tests

WPScan API

composer behat -- features/vuln-wpscan.feature

PatchStack API

composer behat -- features/vuln-patchstack.feature

Wordfence API

composer behat -- features/vuln-wordfence.feature

Support Level

Active: 10up is actively working on this, and we expect to continue work for the foreseeable future including keeping tested up to the most recent version of WordPress. Bug reports, feature requests, questions, and pull requests are welcome.

Changelog

A complete listing of all notable changes to WP-CLI Vulnerability Scanner are documented in CHANGELOG.md.

Contributing

Please read CODE_OF_CONDUCT.md for details on our code of conduct, CONTRIBUTING.md for details on the process for submitting pull requests to us, and CREDITS.md for a listing of maintainers of, contributors to, and libraries used by WP-CLI Vulnerability Scanner.

Like what you see?

wpcli-vulnerability-scanner's People

Contributors

allan23 avatar bmarshall511 avatar burhandodhy avatar cadic avatar dkotter avatar eugene-manuilov avatar hulet avatar iamdharmesh avatar jeffpaul avatar oscarssanchez avatar pabamato avatar rahulsprajapati avatar ritesh-patel avatar szepeviktor avatar thelastcicada avatar tott avatar trepmal avatar tylercherpak avatar vladox avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wpcli-vulnerability-scanner's Issues

Invalid argument supplied for foreach()

Not sure who is working on this now that Kailey's gone, but I just installed this on the xylemappliedwater.com network and whenever I use it I get:

PHP Warning:  Invalid argument supplied for foreach() in /var/www/html/wordpress/dev/wp-content/plugins/wp-vulnerability-scanner/wp-vulnerability-scanner.php on line 415
Warning: Invalid argument supplied for foreach() in /var/www/html/wordpress/dev/wp-content/plugins/wp-vulnerability-scanner/wp-vulnerability-scanner.php on line 415

Release version 1.0.0

Describe your question

This issue is for tracking changes for the 1.0.0 release. 🎉 Target release date: April 2022.

Pre-release steps

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.0.0 for your changes.
  • Version bump: Bump the version number in wpcli-vulnerability-scanner.php if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md.
  • Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the latest stable release.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone.
  • Close the milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.0.0 do not make it into the release, update their milestone to 1.1.0, or Future Release.

Post-release steps

  • Ensure release publishes to npm
  • Investigate automation in publishing future releases to npm

Code of Conduct

  • I agree to follow this project's Code of Conduct

wordpress-seo vuln not found

# wp vuln status
...
+-----------------------------------+-------------------+--------------------------------------------------------------------------+----------------+
| name                              | installed version | status                                                                   | fix            |
+-----------------------------------+-------------------+--------------------------------------------------------------------------+----------------+
| wordpress-seo                     | 7.5.3             | No vulnerabilities reported for this version of wordpress-seo            | n/a            |

but wpscan tells me from the outside

[+] wordpress-seo
 | Location: https://xxx/wp-content/plugins/wordpress-seo/
 | Last Updated: 2021-04-06T15:56:00.000Z
 | [!] The version is out of date, the latest version is 16.1.1
 |
 | Found By: Comment (Passive Detection)
 |
 | [!] 2 vulnerabilities identified:
 |
 | [!] Title: Yoast SEO <= 9.1 - Authenticated Race Condition
 |     Fixed in: 9.2
 |     References:
 |      - https://wpscan.com/vulnerability/bd32be83-db19-4026-adc9-9da284849ee3
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19370
 |      - https://plugins.trac.wordpress.org/changeset/1977260/wordpress-seo
 |      - https://packetstormsecurity.com/files/150497/
 |      - https://github.com/Yoast/wordpress-seo/pull/11502/commits/3bfa70a143f5ea3ee1934f3a1703bb5caf139ffa
 |      - https://www.youtube.com/watch?v=nL141dcDGCY
 |
 | [!] Title:  Yoast SEO 1.2.0-11.5 - Authenticated Stored XSS
 |     Fixed in: 11.6
 |     References:
 |      - https://wpscan.com/vulnerability/8bc4cf95-79f7-4d92-b320-a841ab7e6a6f
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13478
 |      - https://gist.github.com/sybrew/2f53625104ee013d2f599ac254f635ee
 |      - https://github.com/Yoast/wordpress-seo/pull/13221
 |      - https://yoast.com/yoast-seo-11.6/
 |
 | Version: 7.5.3 (100% confidence)
 | Found By: Comment (Passive Detection)

Both tools are the latest version.

Rename "fix" key/column to "fixed in".

Is your enhancement related to a problem? Please describe.

Currently, we have the "fix" column in the vulnerability output, and it contains values like n/a, Fixed in x.x.x and Not fixed. This issue is created for rename the fix column to "fixed in" and remove the prefix "Fixed in" from the value and make it version only (like x.x.x).

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

plugin update command getting mangled

I've got a site that is perfect for testing this as it has a few known vulnerabilities in older plugins:

screenshot 2016-06-04 08 12 17

The table is looking awesome! You'll notice the wp plugin update recommended command at the bottom of the table has gone a bit crazy.

Release version 1.1.0

Describe your question

This issue is for tracking changes for the 1.1.0 release. 🎉 Target release date: October 2022.

Pre-release steps

n/a

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.1.0 for your changes.
  • Version bump: Bump the version number in wpcli-vulnerability-scanner.php if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md.
  • Props: update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other README.md changes as necessary.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the latest stable release.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone.
  • Close the milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.1.0 do not make it into the release, update their milestone to 1.2.0, or Future Release.

Post-release steps

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add --skip-cache flag

Is your enhancement related to a problem? Please describe.

We have seen intermittent issues where the transient value storing API information gets stuck in Memcached and does not expire on time. This has been challenging to replicate and I think the best solution would be to add optional functionality to bypass the cached transient key and ensure a call to the API is made. This would be helpful to users conducting a daily scan who never need cache.

Describe the solution you'd like

Add --skip-cache or another similar flag to the available plugin flags to make an API call and not check for the presence of the transient. I believe this logic is happening here: https://github.com/10up/wpcli-vulnerability-scanner/blob/develop/wpcli-vulnerability-scanner.php#L1044

Mock WPScan API for Functional tests

Is your enhancement related to a problem? Please describe.

Functional tests using WPScan as an API provider fail due to the Daily API limits. To fix this failure and make functional tests work properly, we can mock WPScan API calls.

Designs

We have implemented an API mock in 10up/classifai#334 we can follow something similar here.

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

PHP deprecated method

On WP 4.9.5 I get this message:

Non-static method WP_Vul_Scanner::loadScripts() should not be called statically in /Users/victordieppa/Projects/flowable/docroot/wp-includes/class-wp-hook.php on line 286

Release version 1.2.0

This issue is for tracking changes for the 1.1.0 release. 🎉 Target release date: July 2023.

Pre-release steps

  • Review and merge #90
  • Review and merge #92
  • Review and merge #94

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.2.0 for your changes.
  • Version bump: Bump the version number in wpcli-vulnerability-scanner.php and any other relevant files if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md.
  • Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other README.md changes as necessary.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.2.0 do not make it into the release, update their milestone to 1.3.0 or Future Release.

Post-release steps

--format=ids

The readme indicates that you can use --format=ids but the result looks like:

vuln-plugin-status-format-ids

Maybe you could pull the WPScan vulnerability ID from the API response? Or maybe it would be better to just drop support for the ids format entirely?

Consider upgrading to v3 of API

I'm not sure if this package is still maintained, but it looks like WPVulnDB recently opened up v3 of their API which requires all requests to be sent with an auth token (you are still using v1).

I reached out to the WPScan team who have indicated that they won't be maintaining the older versions indefinitely... It is unclear if they will be blocking access completely.

Maybe the token could be accepted as a command line option (e.g. --token=asd123) and the readme could encourage users to set a default value via WP-CLI config?

wp vuln fix does not seem to actually be fixing anything

Output from wp vuln status:

[root@single1 mu-plugins]# wp --allow-root vuln status
Plugins
+--------------------------------------------+-------------------+---------------------------------------------+----------------+
| name                                       | installed version | status                                      | fix            |
+--------------------------------------------+-------------------+---------------------------------------------+----------------+
| add-to-any                                 | 1.6.8             | No reported vulns for add-to-any            | n/a            |
| batcache                                   | 1.2               | No reported vulns for batcache              | n/a            |
| broken-link-checker                        | 1.10.9            | No vulns reported for this version of broke | n/a            |
|                                            |                   | n-link-checker                              |                |
| sem-external-links                         | 6.5.1             | No reported vulns for sem-external-links    | n/a            |
| duracelltomi-google-tag-manager            | 1.1.1             | No reported vulns for duracelltomi-google-t | n/a            |
|                                            |                   | ag-manager                                  |                |
| google-sitemap-generator                   | 4.0.8             | No reported vulns for google-sitemap-genera | n/a            |
|                                            |                   | tor                                         |                |
| restricted-site-access                     | 5.1               | No reported vulns for restricted-site-acces | n/a            |
|                                            |                   | s                                           |                |
| simple-page-ordering                       | 2.2.4             | No reported vulns for simple-page-ordering  | n/a            |
| smart-404                                  | 0.5               | No reported vulns for smart-404             | n/a            |
| verify-google-webmaster-tools              | 1.3               | No reported vulns for verify-google-webmast | n/a            |
|                                            |                   | er-tools                                    |                |
| wordpress-importer                         | 0.6.1             | No reported vulns for wordpress-importer    | n/a            |
| wp-bugherd-master                          | 0.1.0             | No reported vulns for wp-bugherd-master     | n/a            |
| wordpress-seo                     | 2.3.5             | Yoast SEO <= 3.2.4 - Subscriber Settings Se | Fixed in 3.2.5 |
|                                            |                   | nsitive Data Exposure                       |                |
| 10up-sso-client                            | 1.0.0             | No reported vulns for 10up-sso-client       | n/a            |
| index                                      |                   | No reported vulns for index                 | n/a            |
| load                                       |                   | No reported vulns for load                  | n/a            |
| vulncli                                    | 0.0.1             | No reported vulns for vulncli               | n/a            |
+--------------------------------------------+-------------------+---------------------------------------------+----------------+
Run `wp plugin update wordpress-seo`
Themes
+----------------+-------------------+-----------------------------------------------------+-----+
| name           | installed version | status                                              | fix |
+----------------+-------------------+-----------------------------------------------------+-----+
| kaazing        | 0.1.0             | No reported vulns for kaazing                       | n/a |
| root@          | 0.1.0             | No reported vulns for root@                         | n/a |
| twentyfifteen  | 1.2               | No vulns reported for this version of twentyfifteen | n/a |
| twentyfourteen | 1.4               | No reported vulns for twentyfourteen                | n/a |
| twentythirteen | 1.5               | No reported vulns for twentythirteen                | n/a |
+----------------+-------------------+-----------------------------------------------------+-----+
Nothing to update

Then, if we run wp vuln fix.....

root@single1 mu-plugins]# wp --allow-root vuln fix
Plugins
+--------------------------------------------+-------------------+---------------------------------------------+----------------+
| name                                       | installed version | status                                      | fix            |
+--------------------------------------------+-------------------+---------------------------------------------+----------------+
| add-to-any                                 | 1.6.8             | No reported vulns for add-to-any            | n/a            |
| batcache                                   | 1.2               | No reported vulns for batcache              | n/a            |
| broken-link-checker                        | 1.10.9            | No vulns reported for this version of broke | n/a            |
|                                            |                   | n-link-checker                              |                |
| sem-external-links                         | 6.5.1             | No reported vulns for sem-external-links    | n/a            |
| duracelltomi-google-tag-manager            | 1.1.1             | No reported vulns for duracelltomi-google-t | n/a            |
|                                            |                   | ag-manager                                  |                |
| google-sitemap-generator                   | 4.0.8             | No reported vulns for google-sitemap-genera | n/a            |
|                                            |                   | tor                                         |                |
| restricted-site-access                     | 5.1               | No reported vulns for restricted-site-acces | n/a            |
|                                            |                   | s                                           |                |
| simple-page-ordering                       | 2.2.4             | No reported vulns for simple-page-ordering  | n/a            |
| smart-404                                  | 0.5               | No reported vulns for smart-404             | n/a            |
| verify-google-webmaster-tools              | 1.3               | No reported vulns for verify-google-webmast | n/a            |
|                                            |                   | er-tools                                    |                |
| wordpress-importer                         | 0.6.1             | No reported vulns for wordpress-importer    | n/a            |
| wp-bugherd-master                          | 0.1.0             | No reported vulns for wp-bugherd-master     | n/a            |
| wordpress-seo                     | 2.3.5             | Yoast SEO <= 3.2.4 - Subscriber Settings Se | Fixed in 3.2.5 |
|                                            |                   | nsitive Data Exposure                       |                |
| 10up-sso-client                            | 1.0.0             | No reported vulns for 10up-sso-client       | n/a            |
| index                                      |                   | No reported vulns for index                 | n/a            |
| load                                       |                   | No reported vulns for load                  | n/a            |
| vulncli                                    | 0.0.1             | No reported vulns for vulncli               | n/a            |
+--------------------------------------------+-------------------+---------------------------------------------+----------------+
Success: Updated 0/0 plugins.
Themes
+----------------+-------------------+-----------------------------------------------------+-----+
| name           | installed version | status                                              | fix |
+----------------+-------------------+-----------------------------------------------------+-----+
| kaazing        | 0.1.0             | No reported vulns for kaazing                       | n/a |
| root@          | 0.1.0             | No reported vulns for root@                         | n/a |
| twentyfifteen  | 1.2               | No vulns reported for this version of twentyfifteen | n/a |
| twentyfourteen | 1.4               | No reported vulns for twentyfourteen                | n/a |
| twentythirteen | 1.5               | No reported vulns for twentythirteen                | n/a |
+----------------+-------------------+-----------------------------------------------------+-----+
Nothing to update

Nothing seems to actually update. I've got a good test case here, so let me know when I should retest this.

Should this support the --network flag?

On a multisite, does this check all plugins and themes on the network or just the main site? I suppose if it used wp plugin list to get the list of plugins, that doesn't have the --network flag and gives you all plugins. Just wondering if this is something we need to think about.

Add Functional Tests

Is your enhancement related to a problem? Please describe.

Currently, the repo runs only sample tests on PR. Some additional functional tests are needed with WPScan and Patchstack both to give comfort on future PRs.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Installing via `wp-cli package install` no longer works

# wp --allow-root package install [email protected]:10up/wpcli-vulnerability-scanner.git
Installing package 10up/wpcli-vulnerability-scanner (dev-master)
Updating /root/.wp-cli/packages/composer.json to require the package...
Registering [email protected]:10up/wpcli-vulnerability-scanner.git as a VCS repository...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Generating rules
Resolving dependencies through SAT
Looking at all rules.

Dependency resolution completed in 0.001 seconds
Your requirements could not be resolved to an installable set of packages.
Problem 1
    - Root composer.json requires 10up/wpcli-vulnerability-scanner dev-master, found 10up/wpcli-vulnerability-scanner[dev-fix/format-results, dev-trunk, dev-develop] but it does not match the constraint.
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
---
Error: Package installation failed (Composer return code 2).
Reverted composer.json.

PHP version 7.4.24.

suggestion: increase memory limit

Sometimes wp install crashes because of memory limit.

This is how to install in those cases, may be useful having it in readme

php -d memory_limit=512M wp-cli.phar package install [email protected]:10up/wp-vulnerability-scanner.git

Does not notify if API quota is filled for the day

Describe the bug

Even if my API quota for wpvulndb.com is full for the day the vulnerability scanner just says no vulnerabilities found

Steps to Reproduce

  1. Go to wpvulndb.com and create new account
  2. Install wp-vulnerability-scanner and set up fresh API key in wp-config
  3. Run wp-vulnerability-scanner on a site a until the free quota of 50 is full (1-3 times probably enough usually with a bigger site)
  4. Check wpvulndb.com account to see that the quota is indeed full
  5. Run call to wpvulndb.com API manually ex:
curl -H "Authorization: Token token=API_TOKEN" https://wpvulndb.com/api/v3/wordpresses/494
  1. Observe that API answers: Retry Later
  2. Test wp vuln status once more and see that everything looks like its running pretty normally

Expected behavior

I would expect the tool to clearly state ERROR API QUOTA FULL or something

Use the new "introduced_in" API field to more accurately identify vulnerable versions

Recently WPSCAN introduced the "introduced_in" field to the API to more accurately identify vulnerable versions. We should take advantage of this. Here's part of the announcement:

"This field is optional, and at the beginning we expect it to be used quite rarely, but hopefully will be used more and more as we expand our team. When used, the field will contain the version number of the WordPress, plugin, or theme, that the vulnerability was first introduced in. This will compliment the fixed_in field and help reduce false positive results where a user uses an older version of a plugin that is not vulnerable."

Correctly identifying the versions of the plugin that are vulnerable is critical to decision making and we should use this field.

Test against WordPress 5.9

Is your enhancement related to a problem? Please describe.
Once WordPress 5.9 is released, we'll want to test WP-CLI Vulnerability Scanner to see if any incompatibility issues arise.

Describe the solution you'd like

  • test WP-CLI Vulnerability Scanner on WordPress 5.9
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: n/a.

introduced_in field not working as designed

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.

wp vuln plugin-status reports no vulnerability with known vulnerable plugin

I apologize if I'm just using this tool wrong, but it appears to have a bug.

I was testing, and attempted wp vuln plugin-status while Contact Form 7 version 4.4.2 was installed. The command returned the proper version number, but indicated there were no vulnerabilities reported.
image

However, WPVulnDB reports a bug in CF7 that was resolved in 5.0.4.

I believe this likely has something to do with the arguments being passed to the if statement on line 695 of wp-vulnerability-scanner.php:

} elseif ( version_compare( $version, $vuln->fixed_in, '<' ) ) {

... but I'm uncertain of how to properly debug this so I can attempt to fix it myself. I also tested on another old version of plugin with a known vulnerability (NextGen Gallery 2.2.12), but it too reported no vulnerabilities.

Is this an error in my usage, or is this a bug?
Thanks!

Update docs to note command output format

Is your enhancement related to a problem? Please describe.

There's nothing that shows in the readme/docs of what the vuln scanner CLI output looks like, so a sample output from a sample command (or perhaps a couple options show) would be helpful for folks to understand what the result of running our command does here.

Designs

n/a

Describe alternatives you've considered

n/a

Code of Conduct

  • I agree to follow this project's Code of Conduct

Adding API token to WP-CLI config

Hello,

As it stands right now, using the v3 WPVulnDB API, the API token needs to be defined in the site's wp-config.php. This is fine when working with a single WP site, however, I as a tech support rep in a hosting company I work with a lot of different sites on a daily basis. Having to edit the wp-config.php every time can quickly become tedious. Would it be possible to add the API token to the WP-CLI config, so that the same token can be used with all sites on a single server?

Comparison with Patchstack's WP-CLI command

Is your enhancement related to a problem? Please describe.

WP Scan has increased the price of their API, so we'd like to investigate options on adding support for Patchstack's API here.

Designs

n/a

Describe alternatives you've considered

n/a

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add Vulnerability Reference link information.

Is your enhancement related to a problem? Please describe.

Add Vulnerability Reference link information to provide the functionality to users to view more details on vulnerability. the default behavior should be like what we have currently, reference link information should be added only when the --reference flag gets passed to the command.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Unable to install as global package

When executing the command:

wp package install [email protected]:10up/wp-vulnerability-scanner.git

I get the following error:

Installing package 10up/wp-vulnerability-scanner (dev-master)
Updating /root/.wp-cli/packages/composer.json to require the package...
Registering [email protected]:10up/wp-vulnerability-scanner.git as a VCS repository...
Using Composer to install the package...

Loading composer repositories with package information
Warning: The "https://wp-cli.org/package-index/packages.json" file could not be downloaded: Peer certificate CN=ssl391970.cloudflaressl.com' did not match expected CN=wp-cli.org'
Failed to enable crypto
failed to open stream: operation failed

Error: Package installation failed. Reverted composer.json

Broken table layout when reporting status for WordPress 4.9.6

Running wp vuln status through WordPress 4.9.6 breaks the table layout when the package reports any vulnerabilities with WordPress version (not plugins, not themes. See screenshots).

Expected behavior:

Table layout is not broken. Expected to see the same layout as it is with the reports of plugins and themes.

Current behavior:

The table layout breaks.

Steps to reproduce:

Run wp-vulnerability scanner through a WordPress 4.9.6 install
1.- wp vuln status

Screenshots:

Layout broken when reporting problems with WordPress 4.9.6:

brokenlayourwpcli

Layout is fine when reporting WordPress 4.9.7

nobroken

Does not seem to be working

wp vuln status does not seem to report the vulnerabilities

For example I have the plugin wordpress version: 11.5 installed (Yoast SEO)

  • wp vuln status --nagios gives me OK - no vulnerabilities found
  • another similar tool alerts me correctly
  • I can see the vulnerability for the same plugin and version listed at https://wpvulndb.com/vulnerabilities/9445

How can I troubleshoot this?

Unable to install as global package

# wp package install [email protected]:10up/wpcli-vulnerability-scanner.git --allow-root
Warning: Package name mismatch...Updating from git name '10up/wpcli-vulnerability-scanner' to composer.json name '10up/wp-vulnerability-scanner'.
Installing package 10up/wp-vulnerability-scanner (dev-master)
Updating /root/.wp-cli/packages/composer.json to require the package...
Registering [email protected]:10up/wpcli-vulnerability-scanner.git as a VCS repository...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Looking at all rules.

Dependency resolution completed in 0.016 seconds
Your requirements could not be resolved to an installable set of packages.
Problem 1
    - The requested package 10up/wp-vulnerability-scanner could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see https://getcomposer.org/doc/04-schema.md#minimum-stability for more details.
 - It's a private package and you forgot to add a custom repository to find it

Read https://getcomposer.org/doc/articles/troubleshooting.md for further common problems.
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
---
Error: Package installation failed (Composer return code 2).
Reverted composer.json.

I don't know why the rewrting in line 2 is done, but I suspect it's the source of the problem.

# wp  --version
WP-CLI 2.4.0

Unit Tests

If this is something we're going to grow going forward we should consider adding at least basic unit tests

Invalid output for status command when using format option

There are two parts to this... When running wp vuln status --format=json:

  1. The headers are still being printed (WordPress %%VERSION%%, Plugins, Themes, Nothing to update).
  2. Output is presented as three separate JSON encoded arrays.

Because of this you cannot easily reuse the output from this command:

public function test( $args, $assoc_args ) {
    $parsed = WP_CLI::runcommand( 'vuln status --format=json', [
        'return' => true,
        'parse' => 'json',
    ] );

    var_dump( $parsed ); // NULL
}

The same goes for all other allowed formats.

Not sure if this is important to you or not but I thought I should point it out since this seems like it would be the main use for these alternative output formats.

Code sniffer issues

Note: I'm running PHPCS against "WordPress" code standards for this ticket.

A number of items, such as the inline control statement on line 13 (if ( !defined( 'WP_CLI' ) ) return;) don't adhere to proper WordPress standards and should be cleaned up before making public.

Remove cache API response

Per @dkotter

I was able to download Yoast 7.5.3 from here: https://github.com/Yoast/wordpress-seo/releases/tag/7.5.3. Running a scan on that does properly flag that as being insecure and needing to be updated.

That said, the concern here was that maybe there's some issue around caching. We do use a transient to cache the API response (see https://github.com/10up/wpcli-vulnerability-scanner/blob/develop/wpcli-vulnerability-scanner.php#L943). You could easily have a scenario where a scan is run, the API responses are cached and a vulnerability is reported before that cache expires. The next time you run a scan, it wouldn't make a fresh API request and would use the cached data instead, giving you a false result.

But that transient is only cached for a single hour so I don't think that's a fairly common scenario that would happen. Looking at the original report here, Yoast 7.5.3 is being used and the vulnerability there was reported in November of 2018 (while the report here comes from April 2021). Seems unlikely then that this would be the result of stale data, though since every set up is slightly different, possible some weird caching situation.

I think we could easily add a --no-cache flag to our commands, bypassing this cache check. But in my opinion, I'd suggest we remove that caching all together. I understand that the free plan from WP Scan has fairly small limits, so caching helps reduce the likelihood that those limits are reached, but this seems like a tool we would always want fresh data and never want cached data. This isn't something that runs regularly from user requests, it's a command that either is manually run or triggered by something like cron. So I can't think of a reason why we wouldn't want to just remove those caching lines.

All that said, still not sure that is the root cause of this reported issue. Again, can definitely see this causing issues and it does need fixed but seems unlikely that it caused the original reported issue here, just based on timelines.

Originally posted by @dkotter in #54 (comment)

This makes sense to me ^

Add Severity information

Is your enhancement related to a problem? Please describe.

Add the Severity column to the output to show the CVSS score and severity of the vulnerability. The value should show information in this format Severity SCORE/Out_of_SCORE, Example: High 7.1/10

Ref:
image

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Display inconsistencies

While I'm guessing this is because of the API return, the inconsistencies in the theme display here might prove troublesome in public:

screen shot 2016-06-24 at 11 45 40

Potential issue with composer.

Describe the bug

As reported in the slack thread here, we are facing the following error with WP-CLI Vulnerability Scanner:

Error: You appear to be running a development version of 10up WP-CLI Vulnerability Scanner. Please run `composer install` in order for things to work properly.

Steps to Reproduce

Check the information on the slack thread here

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Themes not installed show up in vulnerability list

When I get the human-readable output, 3 themes are listed that I don't have installed.

Screenshot (or see attached):
screenshot 2016-06-04 07 43 48

Now compare that to a wp-cli list of themes:
screenshot 2016-06-04 07 44 47

To confirm, here's my themes directory:
screenshot 2016-06-04 07 45 13

I'm testing this on my personal site thelastcicada.com. I can get you SSH access to this box if you want.

Array to string conversion PHP warning when running with no arguments

Describe the bug

If you run wp vuln status, passing no arguments, you'll see a PHP warning about an array to string conversion in wpcli-vulnerability-scanner.php on line 124.

Steps to Reproduce

  1. Install this plugin
  2. Ensure PHP is configured to show warnings
  3. Run wp vuln status
  4. You should see the PHP warning as described

Screenshots, screen recording, code snippet

PHP Warning: Array to string conversion in /var/www/wpclean.local/wp-content/plugins/wpcli-vulnerability-scanner/wpcli-vulnerability-scanner.php on line 124

Environment information

  • Device: PC
  • OS: Ubuntu 22.04.2 LTS

WordPress information

WordPress 6.1.1

Code of Conduct

  • I agree to follow this project's Code of Conduct

PHP 5.4 + only?

If we're to open-source this do we want to stop at PHP 5.4 as opposed to 5.3 (which products like ElasticPress support). The use of, for example, short array openings break 5.3 compatibility.

What's the URL for the API?

Is your enhancement related to a problem? Please describe.
Yes, there's many sites with similar name as vulndb

Describe the solution you'd like
What's the URL for the api?

Designs

Describe alternatives you've considered

Additional context

Determining whether or not a vulnerability is found with core-status for vuln.sh

I'm trying to modify the vuln.sh script to include the core-status option. Kailey's existing script checks to see if there's a non-zero length string (if [ ! -z...) for plugins and themes, and assumes there's a vulnerability if it's true. The output for core-status always returns a non-zero length string so that won't work with this option. Is there something unique in the output of core-status when a vulnerability is found that we can test for? Or would we be better off testing for No reported vulnerabilities when no vulnerability is found?

Change --fix to a separate command

Rather than a flag, I think --fix would be better as it's own command. So instead of wp vuln status --fix, it would be wp vuln fix. Any reasons not to do that?

Change default behavior

What do you think of making the default behavior for wp vuln status what is now the --verbose flag? What if it showed a nice table when you ran it with no flags, and you had to add the --quiet flag to have it show output only if there's a vulnerability? I'm not sure if this would be a non-standard setup for wp-cli, which would be a good reason to keep it how it is.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.