The one-paragraph brief for a Hawaii business owner or web admin
On July 17, 2026, WordPress core shipped emergency releases 6.8.6, 6.9.5, and 7.0.2 to fix a critical SQL injection in the WP_Query class (CVE-2026-60137) and a REST API batch-route authentication bypass (CVE-2026-63030). Chained together, the two flaws are known publicly as wp2shell and give an unauthenticated remote attacker full remote code execution on any WordPress 6.9.x or 7.0.x site. Exploitation has been observed in the wild since the same day and CISA added both CVEs to the Known Exploited Vulnerabilities catalog during the week of July 21. WordPress.org has enabled forced automatic security updates, but a meaningful share of Hawaii SMB sites have auto-updates disabled at the host or plugin level and will not receive the patch without manual action.
Why this one matters for Hawaii businesses specifically
WordPress runs a large share of the Hawaii SMB web footprint — restaurant sites, hotel and vacation rental sites, nonprofit sites, professional services sites, and a long tail of small e-commerce operators on WooCommerce. Any site holding a customer email list, a lead form, a membership database, or WooCommerce order history is inside the wp2shell blast radius, and inside Hawaii Chapter 487N notification scope if customer personal data touches it. The uncomfortable part: the exploit path requires no authentication, no user interaction, no phishing lure. An attacker with a target list and a proof-of-concept can move through hundreds of unpatched Hawaii sites in an afternoon.
WordPress auto-updates cover the majority of small self-hosted sites, but three common Hawaii patterns silently break the pipeline. First, managed hosting plans on WP Engine, Kinsta, Pantheon, and SiteGround stage updates through their own release process rather than WordPress.org — that process is usually fast but not instantaneous. Second, security or performance plugins that disable file writes to wp-includes will block a core auto-update entirely. Third, sites with a customized WordPress deploy pipeline (Bedrock, Trellis, or a bespoke Composer setup) do not receive WordPress.org auto-updates at all. This weekend is the deadline to confirm which bucket each Hawaii site sits in.
Affected versions and fixed builds
Per the WordPress security advisory:
- CVE-2026-60137: WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2.
- CVE-2026-63030: WordPress 6.9.x and 7.0.x.
- The full unauthenticated wp2shell chain affects 6.9.x before 6.9.5 and 7.0.x before 7.0.2.
- Fixed builds: 6.8.6, 6.9.5, 7.0.2, and any newer minor release.
Sites still on WordPress 6.7 or older have a different problem — they are missing months of unrelated security patches and need a version upgrade, not a hotfix. That project starts today, not next sprint.
The Hawaii SMB weekend response, ordered by hour
Hours 0-1: inventory the WordPress footprint
List every WordPress site the business owns or operates: the primary marketing site, any subdomain sites, any staging or dev sites reachable from the public internet, any vacation-rental or event microsites, any WooCommerce store, any client-portal or membership site. For each site, record the current WordPress version and the hosting environment. If you do not know how many WordPress sites you own, start with DNS records and any hosting invoices. Unowned or abandoned sites are the most common breach path.
Hours 1-3: confirm the patch or apply it
For each site: log in to WordPress admin and confirm the version is 6.8.6, 6.9.5, 7.0.2, or newer. If not, run the update from Dashboard → Updates. On managed hosting, verify the host applied the patch through the host's dashboard rather than through WordPress admin. If auto-updates failed silently because a plugin blocks file writes, resolve the plugin conflict and run the update manually. Site on Bedrock or a bespoke deploy pipeline: run the update through Composer, commit, deploy.
Hours 3-6: hunt for compromise indicators
Any site that was on 6.9.x or 7.0.x and unpatched between July 17 and this morning needs a compromise review, not just a patch. Check for: new administrator accounts in wp_users created in the last 14 days you did not create; unfamiliar plugins in wp-content/plugins, especially plugins with no readme or a random name; PHP files anywhere under wp-content/uploads (uploads should never contain PHP); modifications to wp-config.php, .htaccess, or index.php in the last 14 days; unfamiliar cron entries under wp-cron; outbound connections from the web server to unfamiliar IPs; changed permissions on core files.
Hours 6-24: WAF, hardening, and cleanup
Enable a WAF with virtual patching for CVE-2026-60137 and CVE-2026-63030 if you do not already have one — Wordfence, Sucuri, Cloudflare WAF, and StackPath all shipped rules the week of July 17. Restrict access to /wp-json and /wp-admin to known IP ranges where feasible. Rotate all WordPress administrator passwords. Rotate WordPress salts in wp-config.php to invalidate any stolen sessions. Force logout of all users. If you found any indicator of compromise in the previous step, engage an incident-response firm; do not attempt to clean a compromised WordPress site by deleting files and hoping.
What this looked like at a Kailua vacation-rental operator this week
A Kailua-based short-term rental operator running 34 vacation rental listing sites on a single WordPress multisite install, hosted on a Honolulu VPS provider, WooCommerce for booking deposits, roughly 8,400 past guest records in the WordPress database including guest names, email, phone, and last-four card. Sites were on WordPress 7.0.1 when the July 17 advisory landed. Auto-updates were disabled at the host level because a caching plugin had corrupted an earlier update; the disable had been in place since May 2026.
The MSP found this on the Saturday-morning weekly patch review, six days after the advisory. Actions across a four-hour Saturday window:
- Full multisite backup captured before any change. Backup validated against a restore test on a staging environment.
- WordPress core updated from 7.0.1 to 7.0.2 on the multisite; auto-update pipeline restored after resolving the caching plugin conflict.
- Compromise indicator hunt: two new administrator accounts (created July 19 and July 21) that the owner did not create. One PHP file dropped into wp-content/uploads on July 19. Modified .htaccess on July 20 adding a redirect rule.
- Incident declared. Sites taken offline. Panel forensic firm engaged through the operator's cyber insurance carrier. Restored from a July 16 backup captured before the exploit window opened. Full malware scan on the restored image before bringing the sites back.
- Guest data confirmed exfiltrated for one of the 34 sites based on server access logs matching the SQL injection pattern. Chapter 487N notification prepared for approximately 1,120 Hawaii residents in that site's guest table. Notification prepared for 4,890 non-Hawaii residents in parallel per applicable state laws.
- All WordPress passwords rotated, salts rotated, WAF (Wordfence Premium) enabled with virtual patching, admin access restricted to two office IPs plus the MSP jump host.
Total forensic and notification cost estimated at $58,000 across insurance-covered forensic labor, outside counsel review, and required notification mailings. The disabled auto-update decision, made in May over a caching plugin conflict, was the single decision that turned a 30-second patch into a $58,000 event.
How this fits the Hawaii CVE cadence this week
Yesterday's advisory covered the Check Point SmartConsole CVE-2026-16232 authentication bypass. wp2shell is the second high-priority chain to land inside the same 96 hours, and the second to hit a very different customer base — where SmartConsole is a management-plane problem for mid-market Hawaii firms, wp2shell is a content-management-system problem for the long tail of small Hawaii businesses running a website they built or inherited. Related Hawaii advisories from the past 30 days: SharePoint on-premises exploitation, the SonicWall SMA1000 double CVE, and the Ubiquiti UniFi OS triple CVE. All followed the same disclosure-to-mass-exploitation pattern.
Why HI Tech Hui is publishing the wp2shell weekend brief
HI Tech Hui has been the managed IT and cybersecurity provider for Hawaii businesses since 2014, operating from 401 Kamakee Street in Kakaako with a Cyberuptive-run security operations capability. We publish a Saturday cybersecurity advisory every week to keep Hawaii business owners and IT leads ahead of the weekend exploitation window. If you take one thing from this post: verify every WordPress site your business owns runs 6.8.6, 6.9.5, 7.0.2, or newer before Monday morning, and hunt for compromise on any site that ran 6.9.x or 7.0.x unpatched between July 17 and now.
Frequently asked questions about wp2shell CVE-2026-60137 and CVE-2026-63030
What is WordPress wp2shell CVE-2026-60137 and CVE-2026-63030 and what should a Hawaii business do this weekend?
wp2shell is an unauthenticated remote code execution chain combining CVE-2026-60137 (SQL injection in WP_Query author__not_in) with CVE-2026-63030 (REST API batch-route authentication bypass) in WordPress core. Actively exploited since July 17, 2026 and added to the CISA KEV catalog. A Hawaii business running WordPress 6.9.x or 7.0.x should confirm auto-updates applied 6.9.5 or 7.0.2 this weekend, hunt for compromise indicators, and patch any manually managed site same-day.
Which WordPress versions are affected by CVE-2026-60137 and CVE-2026-63030?
CVE-2026-60137 affects WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2. CVE-2026-63030 affects 6.9.x and 7.0.x. The full unauthenticated wp2shell chain requires both CVEs, so it hits 6.9.x before 6.9.5 and 7.0.x before 7.0.2. WordPress.org has enabled forced automatic security updates on affected installations.
How is the wp2shell chain being exploited in the wild?
An unauthenticated attacker sends a crafted REST API batch request that abuses CVE-2026-63030 to bypass the authentication blocklist, then reaches the vulnerable WP_Query author__not_in parameter to inject SQL under CVE-2026-60137. From there the attacker can exfiltrate the database, create a rogue administrator, upload a malicious plugin, and achieve full server-level remote code execution.
How does a Hawaii business quickly confirm its WordPress site is patched?
Log in to WordPress admin. Confirm the version shown at the bottom right of the dashboard is 6.8.6, 6.9.5, 7.0.2, or newer. If your site is on managed hosting like WP Engine, Kinsta, Pantheon, or SiteGround, check the host's dashboard for the applied version. If the site is self-hosted on a VPS or shared hosting, run wp core version at the CLI. Anything older than 6.8.6 needs same-day action.
What indicators of compromise should a Hawaii business hunt for on WordPress?
New administrator accounts created in the last 14 days that you did not create, unfamiliar plugins in wp-content/plugins including plugins with no readme, files modified in wp-content/uploads that are not media, PHP files in wp-content/uploads at all, unfamiliar cron entries under wp-cron, unfamiliar users in wp_users with the administrator role, and outbound connections from the web server to unfamiliar IPs. Any single indicator opens an incident.
What compensating controls should a Hawaii business apply if it cannot patch immediately?
Put the site behind a web application firewall with virtual patching rules for CVE-2026-60137 and CVE-2026-63030 — Wordfence, Sucuri, Cloudflare WAF, and StackPath all shipped rules the week of July 17. Restrict access to /wp-json and /wp-admin to known IP ranges where feasible. Disable the REST API for unauthenticated users through a hardening plugin if the site does not need it. Backup fully before making changes.
Does a Hawaii business have to report a WordPress compromise under state law?
If the compromised WordPress site holds customer personal information — Social Security numbers, driver's license numbers, or financial account numbers — Hawaii Chapter 487N requires notification to affected residents without unreasonable delay and notice to the Office of Consumer Protection when 1,000 or more Hawaii residents are involved. E-commerce, membership, and lead-form sites are commonly in scope. Consult counsel early.
How can a Hawaii business tell whether WordPress auto-updates actually applied 6.9.5 or 7.0.2?
Check the WordPress dashboard version display first. Confirm the update log at Tools → Site Health → Info → WordPress or in wp-admin update history. On the server, verify the WordPress version constant in wp-includes/version.php matches 6.8.6, 6.9.5, or 7.0.2. If a hardening plugin blocks the WordPress.org update pipeline, forced updates may have failed silently — those sites need manual intervention this weekend.
Bottom line for Hawaii businesses running WordPress
Verify every WordPress site the business owns is on 6.8.6, 6.9.5, 7.0.2, or newer before Monday morning. On sites that ran 6.9.x or 7.0.x unpatched between July 17 and now, run the compromise-indicator hunt above and treat any hit as an incident. Add a WAF with virtual patching if the site is not already behind one. Rotate administrator passwords and WordPress salts across every site. wp2shell is on the CISA KEV catalog and moving fast — this is a weekend action, not a next-sprint ticket.