プラグイン名	Progress Planner
脆弱性の種類	クロスサイトスクリプティング (XSS)
CVE番号	CVE-2026-28116
緊急	低い
CVE公開日	2026-06-02
ソースURL	CVE-2026-28116

Urgent: Cross‑Site Scripting (XSS) in Progress Planner plugin (≤ 1.9.0) — What WordPress Site Owners Must Do Now

日付： 2 June 2026
著者： WP-Firewall セキュリティチーム

まとめ：

クロスサイトスクリプティング (XSS) 脆弱性 (CVE‑2026‑28116) has been disclosed in the WordPress plugin “Progress Planner” affecting versions ≤ 1.9.0. The vendor released a patch in version 1.9.1. The vulnerability requires Editor privileges to be triggered and requires user interaction. The Common Vulnerability Scoring System (CVSS) base score is 5.9. Although the reported priority is “Low”, this issue can be chained into more serious attacks on many sites if left unaddressed. This post explains the risk, real‑world exploitation scenarios, immediate mitigation measures, detection and recovery steps, and how WP‑Firewall can protect your site — including how to get started with our Free plan.

---

目次

• What was reported (quick facts)
• Why XSS still matters on WordPress sites
• Technical overview of the Progress Planner XSS (what we know)
• 現実的な悪用シナリオとビジネスへの影響
• Immediate actions — step‑by‑step (what to do within the next hour, 24 hours, 7 days)
• If you cannot update the plugin immediately — short‑term mitigations
• 悪用と妥協の指標（IoC）を検出する方法
• Recovery and forensics checklist if you suspect a compromise
• Hardening and long‑term defenses (policy + technical)
• How WP‑Firewall protects you (features useful for this issue)
• 今すぐサイトを保護 — WP‑Firewallの無料プランから始めましょう
• 概要と最終的な推奨事項

---

What was reported (quick facts)

• Affected plugin: Progress Planner (WordPress plugin)
• Vulnerable versions: ≤ 1.9.0
• Patched version: 1.9.1
• 脆弱性の種類：クロスサイトスクリプティング（XSS）
• CVE: CVE‑2026‑28116
• CVSS base score: 5.9
• Required privilege for exploitation: Editor
• Extraneous requirement: User interaction (e.g., clicking a crafted link or submitting a form)
• Reported by: security researcher (credit as published by the vendor)

If you run Progress Planner on your site, check your plugin version immediately and apply the patch (1.9.1 or later) as your first and most important step.

---

Why XSS still matters on WordPress sites

XSS is one of the oldest web vulnerabilities, but it remains pervasive — especially on platforms like WordPress where many plugins render user‑supplied content. On WordPress, XSS can have outsized impact for several reasons:

• WordPress sites are ecosystems of core + themes + plugins. A single plugin with an XSS flaw can affect the entire site.
• Roles like Editor and Author are common on multi‑contributor sites. If an Editor account (or compromised Editor) can inject script into pages or admin screens, the attacker can target administrators and site visitors.
• XSS is often an enabler: once an attacker executes JavaScript within a privileged user’s browser (for example, an administrator), they can escalate to account takeover (cookie theft, CSRF to privileged endpoints), install backdoors, inject persistent malicious content, or pivot to other systems.
• Automated exploit kits and mass‑scanning tools look for XSS vectors in widely‑used plugins and themes; an unpatched plugin can become a high‑volume entry point.

Even when a vulnerability has a “low” priority rating, the practical risk depends on context — number of sites running the plugin, how Editor roles are assigned, and whether administrative users have visited exploitable pages. That’s why rapid mitigation is necessary.

---

Technical overview of the Progress Planner XSS (what we know)

Public disclosure indicates that Progress Planner versions up to and including 1.9.0 contain an XSS issue. The vendor’s advisory lists:

• 脆弱性クラス: クロスサイトスクリプティング (XSS)
• 必要な権限: エディター
• User interaction needed

Although the vendor’s public write‑up does not always publish full proof‑of‑concept exploits for responsible disclosure reasons, the presence of an XSS vulnerability typically means that at least one plugin endpoint or field accepts input that is later rendered without proper output encoding/escaping. Common examples in plugins include:

• Text fields, descriptions or notes saved as post meta or plugin settings that are later displayed in admin UI without proper escaping.
• AJAX endpoints that echo input back to the browser without filtering or escaping.
• Shortcodes, widgets, or front‑end components that render stored content but fail to sanitize or escape HTML.

Because this issue requires Editor privileges, an attacker either needs an Editor account, or must trick an existing Editor to perform an action that triggers the payload (for example, clicking a link sent via email or a crafted admin URL).

Key takeaways from the technical posture:

• This is not a remote unauthenticated takeover (no direct RCE), but it is a vector for account takeover and site compromise when combined with social engineering or privilege abuse.
• The patch is available in 1.9.1. Updating is a complete fix from the vendor side and must be the first remediation step.

---

現実的な悪用シナリオと影響

Below are plausible scenarios that show why even an XSS requiring Editor privileges is dangerous:

1. Editor‑to‑Admin pivot
   • An attacker gains access to an Editor account (credential reuse, phishing, or a compromised sub‑contractor).
   • The attacker creates content containing malicious JavaScript that is stored by the plugin.
   • When an Administrator opens the plugin page or any page where the stored content renders, the script executes in the Administrator’s browser. The script reads the admin session cookie or uses the admin’s authenticated session to perform actions (create a new admin user, change settings, upload a backdoor plugin, modify content).
   • Outcome: Full site takeover.
2. Social engineering within the organization
   • The attacker crafts a link that triggers reflected XSS or leads the Editor to perform an action (submit a crafted form). The Editor is tricked into clicking. The script executes in the Editor’s browser and can manipulate content or send auth tokens back to the attacker.
3. Persistent reputational and SEO damage
   • Stored XSS payload modifies front‑end content for site visitors (inserts spam links, redirects to malicious domains, or serves fake advertisements). This damages SEO, may get the site flagged by search engines, and costs time and money to remediate.
4. Supply‑chain leverage
   • If the plugin is used by many sites, an attacker who can exploit Editor accounts across multiple sites can run mass campaigns (e.g., ad fraud, phishing distribution), using the plugin as the initial vector.

Even when exploitation requires user interaction, many real world campaigns successfully use social engineering to trigger those interactions. Treat this as a high‑urgency patch event.

---

直ちに行うべきアクション — ステップバイステップ

If you operate a WordPress site using Progress Planner, follow this prioritized checklist.

Actions to take in the next hour

1. プラグインのバージョンを確認してください
   • Dashboard → Plugins → find Progress Planner. If version is ≤ 1.9.0, act immediately.
2. If possible, update to 1.9.1
   • Update the plugin to version 1.9.1 or the latest release provided by the author. This is the definitive fix from the vendor.
3. Restrict Editor activity temporarily
   • If you cannot update immediately, temporarily limit Editor capabilities:
     • Disable the Editor role from creating or editing content that the plugin processes.
     • Alternatively, temporarily demote Editor users until patched.
4. Enable WP‑Firewall protection rules (if you use a WAF)
   • Deploy generic XSS protection rules or the virtual patch we describe below.
   • If you’re on the WP‑Firewall platform, ensure your site has the managed firewall and WAF enabled and that threat rules are active.

Actions to take within 24 hours

1. Scan the site for suspicious scripts or injected content
   • 検索 post_content そして post_meta のため 、）パンくずリストをレンダリングするページや既知のプラグインエンドポイントの下にあるページをターゲットにします。, onerror=, オンロード=, ジャバスクリプト:, 評価(, または疑わしいbase64ブロブ。.
   • Search the uploads directory for newly created PHP files or unknown files.
2. Review Editor accounts and recent activity
   • Review user list — look for unknown/editor accounts.
   • Review Recent Activity and audit logs (if available) to see if Editors have added content that could exploit the flaw.
3. Force password reset for privileged users if compromise is suspected
   • If you identify unusual activity, force password resets for Editors and Administrators.

Actions to take within 7 days

1. 完全なマルウェアスキャン
   • Run a complete site scan (files + database). If using WP‑Firewall, run the scanner included in the service.
2. Full site backup
   • Create a clean, offline backup prior to any remediation attempts that will modify data for forensic purposes.
3. Patch other plugins and core
   • While you’re patching Progress Planner, ensure WordPress core, themes, and other plugins are also up to date.

---

If you cannot update immediately — temporary mitigations (virtual patching)

If updates are delayed (compatibility testing, staging requirements, or hosting restrictions), use these mitigations:

1. Block known exploit payloads via WAF rules
   • Add rules to block requests containing suspicious script tags or JavaScript event attributes in the plugin’s endpoints.
   • Example (pseudocode/modsec style):
     • Block requests where REQUEST_URI matches plugin admin or AJAX endpoints and ARGS|ARGS_NAMES contain <script または onerror= または ジャバスクリプト:.
   • Tuning: avoid overly broad rules that break valid content; restrict rules to plugin endpoints and admin contexts.
2. プラグイン管理ページへのアクセスを制限する
   • Use .htaccess, web server rules, or an access control plugin to limit access to the plugin’s admin pages by IP (if your admin team uses fixed IPs) or VPN only.
3. プラグインを一時的に無効にする
   • If the plugin is not essential for immediate site operation, deactivate it until you can safely update.
4. Harden Editor interactions
   • Prevent Editors from uploading certain file types.
   • Limit Editor ability to add untrusted HTML or scripts by using content sanitizers or by disallowing embedding raw HTML in the block editor.
5. コンテンツセキュリティポリシー（CSP）を適用します。
   • Implement a restrictive CSP that blocks inline scripts and only allows scripts from trusted origins. This reduces the impact of injected scripts, though CSP must be tested to avoid breaking legitimate admin scripts.
6. Monitor and alert on suspicious changes
   • Turn on file integrity monitoring and alerting for modifications to core plugin files and uploads.

Although these are stopgap measures, they buy time for a full update and forensic review.

---

侵害を検出する方法 — 侵害の指標（IoCs）

Search for the following signs in both files and database:

データベースチェック

• post_content または 11. postmeta を含む 、）パンくずリストをレンダリングするページや既知のプラグインエンドポイントの下にあるページをターゲットにします。, onerror=, オンロード=, ジャバスクリプト:, or suspicious encoded strings (base64, escape sequences).
• Unexpected shortcodes or plugin options containing HTML/JS.
• New or modified posts/pages you did not authorize.

ファイルシステムチェック

• に新しいPHPファイル /wp-content/アップロード/ または他の書き込み可能なディレクトリ。.
• Modified plugin or theme files (compare with vendor package).
• Suspicious cron jobs or scheduled tasks added via wp_cron.

Behavioral and traffic indicators

• Visitors seeing redirects to spam/myriad ad domains or popups.
• Search engine warnings or sudden drops in organic traffic.
• Log entries showing repeated POST requests to plugin endpoints with script tags or unusual payloads.

User & account indicators

• New Administrator accounts or changes to user roles you did not authorize.
• Failed login attempts followed by successful sessions from unusual IPs.

If you see any of these, treat the site as potentially compromised and follow recovery steps below.

---

Recovery and forensic checklist (if you suspect compromise)

1. サイトを隔離する
   • Put the site into maintenance mode or take it temporarily offline to prevent further damage and data exfiltration.
2. 証拠を保存する
   • Take a snapshot of the database and filesystem before making any changes.
   • Collect server logs (web server, PHP, WAF logs) and export them for analysis.
3. Clean and remove malicious content
   • Remove injected scripts found in posts, plugin options, and theme files.
   • Revert modified plugin files to vendor copies (delete and re‑install plugin if necessary).
   • Remove unknown or suspicious PHP files in uploads.
4. 資格情報をローテーションする
   • Force password resets for all users with elevated privileges — Admin, Editor, Author.
   • Revoke any active sessions (WordPress supports session invalidation through user meta or single sign‑on solutions).
5. Reinstall clean plugin package
   • Delete the vulnerable plugin and install a fresh copy of version 1.9.1 (or later) from the official source. Do not restore from a backup that predates the clean state without inspection.
6. 再スキャンと監視
   • Run a full malware scan post‑cleanup and continue monitoring logs for reoccurrence.
7. 専門的な助けを考慮してください
   • If the attack seems complex or you lack internal resources, engage an incident response provider with WordPress experience.
8. インシデントを文書化する
   • Keep a timeline of what was found, remediation steps, and why decisions were made. This is invaluable for post‑mortem and insurance purposes.

---

強化と長期的な防御

To reduce the risk from similar vulnerabilities in the future, adopt this layered approach:

1. 最小権限の原則
   • Avoid giving Editor or Author credentials to users who do not need them.
   • Use granular capability plugins or custom roles where possible.
2. 多要素認証（MFA）を強制してください。
   • 昇格された権限を持つすべてのユーザーにMFAを要求する。.
3. Continuous patching policy
   • Maintain a weekly or bi‑weekly schedule for patching plugins and themes in staging before production.
4. ステージングとテスト
   • Test all plugin updates in a staging environment before production where practical.
5. Regular security scanning
   • Schedule automated file and database scans for malicious content and anomalies.
6. Web Application Firewall (WAF) with virtual patching
   • A managed WAF can block exploitation attempts in real time even before vendor patches are installed.
7. コンテンツセキュリティポリシー（CSP）とセキュリティヘッダー
   • Implement a CSP to limit inline scripts, enforce HTTPS, and set appropriate X‑Frame‑Options, X‑Content‑Type‑Options, and Referrer‑Policy headers.
8. ファイル整合性の監視とバックアップ
   • Keep immutable, off‑site backups and regularly verify their integrity.
9. 監査ログと監視
   • Keep audit logs for user activity and file changes; integrate with alerts for suspicious events.

---

How WP‑Firewall protects you (the features that matter for this issue)

At WP‑Firewall we focus on practical, layered protection that specifically addresses the sort of risk posed by the Progress Planner XSS:

• 管理されたファイアウォールとWAF
  • Our managed firewall inspects incoming requests, blocks known malicious payloads (script injection patterns), and isolates suspicious requests aimed at plugin admin and AJAX endpoints.
  • Virtual patching: when we detect a new vulnerability, our team can deploy targeted WAF rules to block exploit attempts across your sites while you plan and deploy vendor updates.
• マルウェアスキャナーとファイル整合性チェック
  • Scheduled scans look for malicious files and injected scripts. File integrity monitoring alerts you to changes in plugin files or unexpected uploads.
• OWASPトップ10の緩和
  • Prebuilt signatures and rulesets mitigate common injection vectors like XSS, SQLi, and others.
• Attack detection and logging
  • Detailed logs show attempted exploitation patterns and source IPs. These logs help you identify suspicious user accounts and attackers’ infrastructure.
• 7. 事件を疑う場合、私たちのチームは段階的な修復ガイダンスを提供します：隔離、監査、資格情報のローテーション、および復元。
  • Our team provides playbooks and recommended steps if we detect an active exploitation attempt.

Feature mapping to Progress Planner issue

• If you cannot update immediately, WP‑Firewall’s WAF signatures and virtual patching block payloads that would exploit unescaped fields and plugin endpoints. This drastically reduces the risk window.
• Our malware scanner will detect and flag injected scripts in the database and uploads directory.
• The managed firewall can restrict access to admin endpoints by IP or geography while you remediate.

---

今すぐサイトを保護 — WP‑Firewallの無料プランから始めましょう

If you’re reading this and want to get an immediate, practical layer of protection in front of your WordPress installs, sign up for the WP‑Firewall Basic (Free) plan. The free plan includes essential protections that are directly relevant to this vulnerability:

• Managed firewall with WAF (blocks common XSS patterns)
• セキュリティトラフィックのための無制限の帯域幅
• Malware scanner that inspects files and database for injected scripts
• Prebuilt mitigation for OWASP Top 10 risks (including XSS)

Upgrade paths are available if you want automatic malware removal, IP blacklist/whitelist controls, virtual patching, and managed services. Start with the Free plan today and reduce your exposure while you schedule patching and cleanup: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Practical queries and examples — how to check your site

Below are concrete queries and commands to help you locate possible injected content quickly. Run these in your database and shell as appropriate, or ask your host/developer to run them:

WordPress database search examples (use phpMyAdmin or WP‑CLI):

• スクリプトを検索する投稿：

  SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%

• オプションと投稿メタを検索：

  SELECT option_name FROM wp_options WHERE option_value LIKE '%
  
  SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';

Linux grep examples (from the WordPress root):

• Find script tags in files (uploads often targeted):

  grep -RIn "<script" wp-content/uploads || true

• 最近変更されたファイルを見つけます:

  find . -type f -mtime -7 -print

Audit logs and WAF logs
Review WP‑Firewall or hosting WAF logs for requests containing <script, onerror=, 評価(, ベース64_デコード, or requests to plugin endpoints with suspicious payloads.

---

Recommended detection rules (examples for experienced admins)

Below are sample detection patterns (conceptual — adapt to your environment and test carefully):

1. Block POST requests to plugin admin/AJAX endpoints that contain <script:
   • 条件REQUEST_METHOD == POST AND REQUEST_URI が以下を含む。 /wp-admin/admin.php?page=progress-planner または含む progress-planner AND ARGS or ARGS_NAMES contain <script または onerror=
2. 含まれているリクエストにフラグを付けます ドキュメント.cookie, XMLHttpRequest、 または fetch( in parameters to admin endpoints.
3. Alert on new admin users created from IPs not in your known admin IP list.

注記： Avoid overly broad rules that break legitimate editors’ use. Scope rules to plugin endpoints and admin context where possible.

---

概要と最終的な推奨事項

• Immediate priority: If you run Progress Planner, update to version 1.9.1 now. This is the vendor fix and closes the reported XSS vulnerability (CVE‑2026‑28116).
• If you cannot update immediately, use a managed WAF (virtual patching), restrict Editor activity, and scan for injected scripts.
• Monitor for indicators of compromise listed above, preserve logs and backups, and follow the recovery checklist if you find evidence of exploitation.
• Adopt a layered security approach: least privilege, MFA for privileged accounts, automated scanning, managed WAF protections, and consistent patching cadence.

At WP‑Firewall we stand ready to help you reduce exposure and respond rapidly to incidents like this. Our Free plan provides immediate WAF coverage and scanning to catch the most common exploit attempts while you carry out vendor updates and forensic checks. Learn more and sign up here: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

安全にお過ごしください。
WP-Firewall セキュリティチーム

---

If you want, we can provide:

• A ready‑to‑apply WAF rule set tuned for this plugin (requires admin access to your WP‑Firewall console).
• A quick checklist tailored to your site’s user roles and publishing workflow.
• Assistance running database and file searches for injected content.