説明
このプラグインは WPVulnerability API と連携して、WordPress コア、プラグイン、テーマ、PHP バージョン、Apache HTTPD、nginx、MariaDB、MySQL、ImageMagick、curl、memcached、Redis、SQLite のリアルタイム脆弱性評価を提供します。
WordPress ダッシュボードに詳細なレポートを直接表示し、潜在的なセキュリティリスクを常に把握できます。サイトのセキュリティ状況に関する定期通知を設定して、情報過多にならずに常に情報を得られます。使いやすさを重視した設計で、サイトの個人データを保存・取得することなく、プロアクティブなセキュリティ対策をサポートします。
データの信頼性
データベースが提供する情報は、サードパーティによってレビューされたさまざまな情報から取得したものです。情報については、いかなる種類の責任も負いません。自己責任で行動してください。
プラグインの使い方
WP-CLI
次の WP-CLI コマンドで脆弱性を管理・チェックできます:
- コア:
wp wpvulnerability core - プラグイン:
wp wpvulnerability plugins - テーマ:
wp wpvulnerability themes - PHP:
wp wpvulnerability php - Apache HTTPD:
wp wpvulnerability apache - nginx:
wp wpvulnerability nginx - MariaDB:
wp wpvulnerability mariadb - MySQL:
wp wpvulnerability mysql - ImageMagick:
wp wpvulnerability imagemagick - curl:
wp wpvulnerability curl - memcached:
wp wpvulnerability memcached - Redis:
wp wpvulnerability redis - SQLite:
wp wpvulnerability sqlite
プラグインの設定には次のコマンドを使用できます:
- コンポーネントを非表示:
wp wpvulnerability config hide <component> [on|off] - 通知メール:
wp wpvulnerability config email <emails>(カンマ区切り) - 通知頻度:
wp wpvulnerability config period <never|daily|weekly> - ログ保持期間:
wp wpvulnerability config log-retention <0|1|7|14|28>(日数単位) - キャッシュ期間:
wp wpvulnerability config cache <1|6|12|24>(時間単位)
すべてのコマンドは --format オプションで出力形式を指定できます:
--format=table: 結果をテーブル形式で表示します (デフォルト)。--format=json: 結果を JSON 形式で表示します。
ヘルプが必要ですか ?
wp wpvulnerability --help: WPVulnerability コマンドのヘルプ情報を表示します。wp wpvulnerability [command] --help: 指定した WPVulnerability コマンドのヘルプ情報を表示します。
REST API
WPVulnerability プラグインは、WordPress サイトのさまざまなコンポーネントの脆弱性情報を取得するための複数のREST API エンドポイントを提供します。
- コア:
/wpvulnerability/v1/core - プラグイン:
/wpvulnerability/v1/plugins - テーマ:
/wpvulnerability/v1/themes - PHP:
/wpvulnerability/v1/php - Apache HTTPD:
/wpvulnerability/v1/apache - nginx:
/wpvulnerability/v1/nginx - MariaDB:
/wpvulnerability/v1/mariadb - MySQL:
/wpvulnerability/v1/mysql - ImageMagick:
/wpvulnerability/v1/imagemagick - curl:
/wpvulnerability/v1/curl - memcached:
/wpvulnerability/v1/memcached - Redis:
/wpvulnerability/v1/redis - SQLite:
/wpvulnerability/v1/sqlite
WPVulnerability REST API は認証にアプリケーションパスワードを使用します。リクエストの Authorization ヘッダーに有効なアプリケーションパスワードを含める必要があります。
認証付きリクエストの例
curl -X GET https://example.com/wp-json/wpvulnerability/v1/plugins -u username:application_password
username を WordPress のユーザー名、application_password をアプリケーションパスワードに置き換えてください。
追加設定
“From:” メール (バージョン3.2.2以降)
何らかの理由でプラグインから送信されるメールの From をサイト管理者とは異なるものにする必要がある場合は、wp-config.php に定数を追加して変更できます:
define( 'WPVULNERABILITY_MAIL', 'sender@example.com' );
定数が有効な場合、設定画面に表示されます。
チェックの強制非表示 (バージョン4.1.0以降)
特定のコンポーネントを常に非表示にしたい場合は、wp-config.php に定数を定義できます。true に設定すると、設定画面で自動的にチェックされ、関連する解析がスキップされます。
例:
define( 'WPVULNERABILITY_HIDE_APACHE', true );
利用可能な定数: WPVULNERABILITY_HIDE_CORE、WPVULNERABILITY_HIDE_PLUGINS、WPVULNERABILITY_HIDE_THEMES、WPVULNERABILITY_HIDE_PHP、WPVULNERABILITY_HIDE_APACHE、WPVULNERABILITY_HIDE_NGINX、WPVULNERABILITY_HIDE_MARIADB、WPVULNERABILITY_HIDE_MYSQL、WPVULNERABILITY_HIDE_IMAGEMAGICK、WPVULNERABILITY_HIDE_CURL、WPVULNERABILITY_HIDE_MEMCACHED、WPVULNERABILITY_HIDE_REDIS、WPVULNERABILITY_HIDE_SQLITE。
キャッシュ期間 (バージョン4.1.0以降)
デフォルトでは、API からのデータは12時間キャッシュされます。変更するには、wp-config.php に WPVULNERABILITY_CACHE_HOURS を 1、6、12、24 のいずれかで定義してください。この値は設定画面と WP-CLI コマンドを上書きします。
define( 'WPVULNERABILITY_CACHE_HOURS', 24 );
ログローテーション (バージョン4.2.0以降)
WPVulnerability は最新の API レスポンスを保存するので、新しいログタブから最近の呼び出しを確認できます。wp-config.php に WPVULNERABILITY_LOG_RETENTION_DAYS を定義して、保持するエントリーの日数を制御できます。対応する値は 0、1、7、14、28 で、0 を使用するとログを完全に無効化します。
define( 'WPVULNERABILITY_LOG_RETENTION_DAYS', 14 );
定数が存在する場合、その値が設定 UI と WP-CLI の両方に強制適用され、環境全体で一貫したログローテーションが保証されます。
セキュリティ設定 (バージョン4.3.0以降)
WPVulnerability はサーバーソフトウェア (ImageMagick、Redis、Memcached、SQLite) の検出にハイブリッドアプローチを使用します。PHP 拡張を優先 (最も安全) し、次にシェルコマンドをフォールバックとして使用 (最も正確) します。この動作は wp-config.php のセキュリティ設定定数で制御できます。
シェルコマンドのグローバル無効化:
define( 'WPVULNERABILITY_DISABLE_SHELL_EXEC', true );
シェルコマンドの使用を完全に無効化します。PHP 拡張のみにフォールバックします。精度の低下が許容できる場合に最大セキュリティとして使用してください。
セキュリティモード (standard/strict/disabled):
define( 'WPVULNERABILITY_SECURITY_MODE', 'strict' );
standard– ハイブリッド検出: PHP 拡張を優先し、シェルコマンドをフォールバックとして使用 (デフォルト、最高精度)strict– PHP 拡張のみ、シェルコマンドなし (高セキュリティ、精度低め)disabled– ソフトウェア検出なし (最大セキュリティ)
コンポーネントホワイトリスト:
define( 'WPVULNERABILITY_SHELL_EXEC_WHITELIST', 'imagemagick,redis' );
指定したコンポーネントのみシェルコマンドを許可します。対応コンポーネント: imagemagick、redis、memcached、sqlite。細かい制御に使用してください。
例:
最大セキュリティ (シェルコマンドなし):
define( 'WPVULNERABILITY_SECURITY_MODE', 'strict' );
ImageMagick のシェル検出のみ許可:
define( 'WPVULNERABILITY_SHELL_EXEC_WHITELIST', 'imagemagick' );
完全無効化:
define( 'WPVULNERABILITY_DISABLE_SHELL_EXEC', true );
すべてのシェルコマンドはハードコードされ検証済みです。ユーザー入力は一切関与しません。コマンドはセキュリティ監査のためにログに記録されます。
互換性
- WordPress: 4.7 – 7.1
- PHP: 7.0 – 8.5
- WP-CLI: 2.3.0 – 2.12.0
セキュリティ
このプラグインは各バージョンで以下のセキュリティ対策とレビュープロトコルに準拠しています:
- WordPress プラグインハンドブック
- WordPress プラグインセキュリティ
- WordPress API セキュリティ
- WordPress コーディング規約
- Plugin Check (PCP)
プライバシー
- このプラグインおよび WordPress Vulnerability Database API は、サイト、ユーザー、プラグイン、テーマ、コンテンツに関する情報を収集しません。
脆弱性
- バージョン4.2.2.1でセキュリティの脆弱性が発見・修正されました。以前のすべてのバージョン (3.3.0〜4.2.1) が影響を受けます。バージョン4.2.2.1以降にアップデートしてください。
セキュリティの脆弱性を発見しましたか ? ROBOTSTXT から非公開でご報告ください。
貢献者
このプラグインへの貢献は、WPVulnerability GitHub リポジトリで行えます。
インストール
自動ダウンロード
WordPress のプラグインセクションにアクセスし、[wpvulnerability] を検索して、プラグインをダウンロードしインストールしてください。
手動ダウンロード
ZIP を解凍し、/wp-content/plugins/wpvulnerability/ ディレクトリにアップロードします。 アップロードするとプラグインリストに表示されます。
FAQ
-
脆弱性情報はどこから取得していますか ?
-
WPVulnerability.com API を元にしています。この API に表示される脆弱性は、CVEs などのさまざまなソースから取得しています。
-
サイトのデータはどこかに送信されますか ?
-
いいえ、送信されません。ユーザーのプライバシーは私たちにとって非常に重要です。私たちはユーザーのデータを商品化しません。
-
どのような脆弱性を見つけますか ?
-
WordPress コア、プラグイン、テーマ、PHP、Apache HTTPD、nginx、MariaDB、MySQL、ImageMagick、curl、memcached、Redis、SQLite の脆弱性が記録されます。
-
サイトに脆弱性がある場合、どうすればいいのでしょうか ?
-
まずは安心してください。脆弱性の内容を調べ、特に影響を受けた要素の最新バージョンが適用されているか確認してください。WordPress とすべてのプラグインを常に最新の状態に保つことを強くお勧めします。ウェブサーバー、データベース、その他のソフトウェアなど WordPress 以外の脆弱性については、ホスティングプロバイダーに修正を依頼してください。
評価
貢献者と開発者
WPVulnerability はオープンソースソフトウェアです。以下の人々がこのプラグインに貢献しています。
貢献者変更履歴
[5.1.6] – 2026-08-22
修正
- 「アンインストール時にすべてのプラグインデータを削除する」設定を保存しても致命的エラーが発生しなくなりました (WordPress の管理 API が読み込まれる前に
add_settings_error()が呼び出されていました)。 - 通知チャンネルを完全に無効化できるようになりました。従来はチェックを外したチェックボックスが送信されないため、すべてのチャンネルのチェックを外して保存しても、以前のチャンネルが有効なままでした。
- 「プラグインをリセット」と「すべてのログを削除」で、2つのログストア (API リクエストログとシェル実行監査ログ) の両方を消去するようになりました。従来はシェル監査のストアが一度も削除されず、また処理の実行時点でログの投稿タイプがまだ登録されていなかったため、どちらの削除も何も行わないまま終了していました。
- 「デバッグ」タブの API 接続テストが実際の API ルートを使用するようになりました。WordPress コアのプレリリース版 (7.1-alpha など) は安定版のマイルストーンにまとめられ、プラグインとテーマは存在しない複数形のルート (HTTP 404) ではなく実際のスラッグのルートに対してテストされます。
- コンポーネントのアイコンに、明示的な width/height 属性と適切な代替テキストを設定しました。同じアイコンは通知メールとサイトヘルスにも埋め込まれますが、これらの場所ではプラグインの CSS が読み込まれないため、サイズ指定のない SVG が本来の 800×800 のサイズで表示されていました。
変更
languages/wpvulnerability.potを新しい文字列で再生成しました。
互換性
- WordPress: 4.7 – 7.1
- PHP: 7.0 – 8.5
- WP-CLI: 2.3.0 – 2.12.0
テスト
- PHP コーディング規約: 3.13.6 (エラー0件)
- WordPress コーディング規約: 3.4.1
- PHPStan: 2.2.9 (レベル 9、エラー0件)
- PHPUnit: 9.6.36 (54テスト)
[5.1.5] – 2026-08-22
変更
- コントリビューターリストの先頭が ROBOTSTXT の組織アカウントになり、その次が Javier Casares になりました。他のコントリビューターに変更はありません。
- ソース参照が現在のコードと一致するよう
languages/wpvulnerability.potを再生成しました。文字列のセットに変更はなく (450件)、同梱のすべての翻訳を照合し、完全に最新の状態を維持しています。
互換性
- WordPress: 4.7 – 7.1
- PHP: 7.0 – 8.5
- WP-CLI: 2.3.0 – 2.12.0
テスト
- PHP コーディング規約: 3.13.6
- WordPress コーディング規約: 3.4.1
- PHPStan: 2.2.9 (レベル 9、エラー0件)
- PHPUnit: 9.6.36 (45テスト)
[5.1.4] – 2026-08-22
ハイライト
- サイトヘルスの脆弱性テストが、すべての WordPress バージョンで再び動作するようになりました。従来は成立することのない可用性チェックによって、どの環境でも通知なく無効化されていました。また、管理画面のフォームでシークレットをマスクするようにし、5.6 から 8.5 までの実際の PHP インタープリターで互換性を検証しました。
修正
- サイトヘルス統合は
class_exists( 'WP_Site_Health' )を条件にテストを登録していましたが、コアがこのクラスを遅延読み込みするのは、プラグインがモジュールを読み込むinitより後です。そのためこのガードは常に false と評価され、13件の脆弱性テストはサイトヘルスに一度も表示されていませんでした。現在はフィルターを無条件に登録しており、WordPress 5.2 未満では単に実行されないだけになります。 - デバッグツールの「すべてのキャッシュを削除」で
wpvulnerability-plugins-cache-dataのタイムスタンプオプションも削除するようになり、実行後にプラグインのデータセットが完全に更新されるようになりました。 - 通知メールの「From:」アドレスを、すべてのコードパスで
sanitize_email()によりサニタイズするようになりました。 - プラグイン一覧テーブルの「最終更新日」列は、テーブルの行ごとにプラグインのデータセット全体をデコードしていました。現在はリクエストごとに1回だけデコードします。
- 脆弱性のあるテーマ数を読み取る際の、重複した
json_decode()呼び出しを削除しました。 wp_date()の互換性ポリフィルが、WordPress 4.7–5.3 で致命的エラーを起こさなくなりました。コアはwp_maybe_decline_date()を無条件に呼び出しますが、この関数は 5.4 以降にしか存在しないため、現在は呼び出しの前に存在チェックを行っています。- コアとソフトウェアの JSON ゲッターは、エンコードに失敗した場合に空文字列ではなく
'[]'を返すようになり、プラグインとテーマのゲッターと挙動が揃いました。
セキュリティ
- Webhook の URL (Slack、Teams、Discord) と Telegram ボットトークンを、管理画面の設定フォーム (シングルサイトとサイトネットワーク) でマスクし、末尾の4文字のみを表示するようにしました。従来はページの HTML にそのまま出力されていました。入力欄はプレーンテキストのフィールドなので、マスクした値がブラウザーの URL 検証にかかることはありません。マスクされた値を変更せずにフォームを保存した場合は保存済みのシークレットが維持され、フィールドを空にすれば従来どおり削除されます。
- 不要になった
register_uninstall_hook()の登録を削除しました。uninstall.phpがこれに取って代わっており、この登録は不要な自動読み込みオプションの行を追加していました。 - シングルサイトの設定登録でも
show_in_rest => falseを明示的に指定するようになり、マルチサイトの構成と揃いました。
変更
- 管理画面の CSS/JS アセットを、wp-admin のすべての画面ではなく、WPVulnerability の設定ページ、ダッシュボード、プラグイン/テーマの一覧テーブルでのみ読み込むようにしました。
- シェルの利用可否チェック (
wpvulnerability_can_shell_exec()) の結果をリクエストごとにキャッシュするようにし、呼び出しのたびにプロセスを起動しないようにしました。
互換性
- WordPress: 4.7 – 7.1
- PHP: 7.0 – 8.5
- WP-CLI: 2.3.0 – 2.12.0
- 実際の PHP インタープリター 5.6.40、7.0.33、7.1.33、7.2.34、7.3.33、7.4.33、8.0.30、8.1.34、8.2.33、8.3.33、8.4.24、8.5.9 で検証しました。すべてのプラグインファイルは 7.0 以上では lint がクリーンに通り、5.6 では失敗するため、宣言している下限バージョンが正しいことを確認できました。PHPCompatibility のゲートは 7.0-8.5 でクリーン、wp-compat の WordPress 下限 4.7 でもクリーンです。
テスト
- PHP コーディング規約: 3.13.6
- WordPress コーディング規約: 3.4.1
- PHPStan: 2.2.9 (レベル 9、エラー0件)
- PHPUnit: 9.6.36 (45テスト)
以前のバージョン
完全な変更履歴を確認したい場合は、changelog.txt ファイルをご覧ください。



