CyberSip™ — Issue 89 — July 20, 2026

Weekend picture

WordPress shipped emergency patches Friday for wp2shell, a two-CVE chain that lets an anonymous HTTP request run code on a default WordPress install with no plugins and no special configuration, covering an estimated 500 million websites. EY notified clients this week that attackers spent 15 days inside a third-party IT support ticket platform used by the firm's tax practice, downloading documents containing Social Security numbers, financial account codes, and tax return data from multiple clients. And Volexity traced the SonicWall SMA1000 zero-days, added to CISA KEV last Tuesday, to active exploitation beginning June 22 by a threat actor it calls UTA0533, three weeks before the vulnerabilities were publicly disclosed.

Weekend intelligence

3 items

01 CriticalPatchedWordPress Core

WordPress patches wp2shell, an unauthenticated remote code execution chain in core that works on a bare site with no plugins

Two CVEs. One REST API batch-route confusion, one SQL injection. Chained, an anonymous HTTP request reaches code execution. A working public exploit exists. WordPress pushed automatic updates. If your site has not auto-updated, update it now.

CVEsCVE-2026-63030
CVE-2026-60137

AffectsWordPress 6.9.x
and 7.0.x

Fixed in6.9.5 and 7.0.2
July 17, 2026

ExploitationNo confirmed
attacks yet

Sources BleepingComputer The Hacker News

What happened

Adam Kues of Searchlight Cyber discovered a two-vulnerability chain in WordPress core and disclosed it to the WordPress Security Team under coordinated disclosure. WordPress shipped versions 6.9.5 and 7.0.2 on July 17 and enabled forced automatic updates for supported installations. The first flaw, CVE-2026-63030, is a REST API batch-route confusion bug introduced in WordPress 6.9. The /wp-json/batch/v1 endpoint is on by default, requires no authentication, and a validation and dispatch desynchronization in the route handler allows attacker-controlled requests to bypass intended restrictions. The second flaw, CVE-2026-60137, is a SQL injection in the author__not_in parameter of WordPress core's WP_Query class. Chained, the two flaws give an anonymous HTTP request a path to remote code execution on the server. No plugins, no themes, no special configuration are required. A site running stock WordPress 6.9 or 7.0 was in range. On July 18, CVE identifiers were assigned, Searchlight Cyber published the full technical mechanism, a working proof-of-concept became public, and Rapid7 announced that authenticated vulnerability checks for InsightVM and Nexpose would be available July 20. No confirmed in-the-wild exploitation has been reported.

Why it matters

WordPress runs roughly 43 percent of all websites. A unauthenticated RCE in core with no preconditions has the broadest possible reach of any web vulnerability class. The patch is available and WordPress pushed automatic updates, but auto-update coverage is not universal. Hosting environments with auto-update disabled, manually managed installations, and sites running staging or development instances on older versions are all still exposed. The working public exploit is in circulation. Automated scanning is the expected next step.

Don't miss

A persistent object cache, Redis or Memcached sitting in front of the batch endpoint, can break the specific attack path for wp2shell as a side effect of how it intercepts requests. This is not a mitigation. It is an incidental condition that may or may not apply to any given deployment. Do not treat "we run Redis" as a reason to delay patching. The WAF interim control is blocking requests to /wp-json/batch/v1 and rest_route=/batch/v1, but this can break legitimate REST API integrations. Verify whether any plugins or custom code in your environment use the batch endpoint before enabling that block.

Potential actions

Confirm every WordPress site in your environment is running 6.9.5 or 7.0.2. Check version numbers directly rather than assuming auto-update completed. Staging and development instances need the same update as production.
If immediate patching is not possible, block requests to /wp-json/batch/v1 and rest_route=/batch/v1 at your WAF as an interim measure. Verify this does not break any REST API-dependent functionality before enforcing it in production.
Check each site at wp2shell.com, Searchlight Cyber's free public checker, using only your domain. The checker confirms whether a site is still on a vulnerable version without requiring technical access.

The Sip

An anonymous HTTP request, no credentials, no plugins, no special setup, and code runs on the server. WordPress pushed auto-updates. That helps. It does not cover every deployment. Check your sites before automated scanners do it for you.

02 HighEYSupply Chain Breach

EY confirms attackers spent 15 days inside a third-party IT support platform, taking client tax documents including Social Security numbers

The breach was in a support ticket system, not EY's core tax platform. Employees attached client tax documents to IT support tickets. Attackers accessed those attachments for two weeks before anyone noticed.

Access windowMar 28 to
Apr 12, 2026

DetectedApril 23, 2026

NotifiedJuly 13–16, 2026

Data stolenTax docs, SSNs,
financial account
codes, credit data

Sources Cyber Insider Cybersecurity News

What happened

EY filed breach notifications with California and Vermont regulators on July 15 and 16, 2026, and sent notification letters to affected clients dated July 13. The breach was not in EY's tax software. It was in a third-party IT service management platform used by EY's internal technology personnel to handle support requests from teams working on client tax engagements. Support tickets submitted through this platform routinely included attachments containing client tax documents, a common practice in enterprise IT support that creates concentrated data exposure in systems that do not normally receive the same security scrutiny as primary application infrastructure. An unauthorized third party accessed the platform between March 28 and April 12, downloading documents from multiple client accounts. EY's security team detected anomalous activity on April 23, eleven days after the breach window closed, and engaged an independent cybersecurity firm to investigate. Stolen documents may include Social Security numbers, financial account codes, credit and debit account information, and material used to prepare tax filings. EY has not disclosed how many clients are affected, which third-party vendor was involved, or whether the incident extends beyond its U.S. operations. This is EY's third significant data security incident in three years: the MOVEit breach in 2023 exposed Bank of America customer data, and a cloud misconfiguration in 2025 left a four-terabyte database backup publicly accessible on Azure.

Why it matters

Tax documents concentrate identity data in a way that most breach categories do not. Social Security numbers, financial account codes, and income data are long-lived and difficult to change. An attacker with this information can file fraudulent tax returns, open financial accounts, or sell the data to actors who specialize in either. The EY incident also illustrates a consistent pattern: sensitive client data migrates into IT support systems through normal workflow, and those systems do not receive the same access controls and monitoring as the primary application. The support ticket platform is the weak link, not because it is unusual, but because this configuration is widespread.

Don't miss

EY's notification letters were dated July 13, roughly 90 days after the breach window closed on April 12. The timeline from detection to notification, April 23 to July 13, is 81 days. This brief noted the same pattern with TRICARE West in Issue 87, where notifications arrived 77 days after the breach date. Both fell within or near the applicable legal notification windows, but both left affected individuals without information for months during which the stolen data could be used. The EY breach is this firm's third in three years, each involving a different third-party or vendor-managed platform. The pattern is not coincidence. It reflects the structural reality that client data routinely moves through platforms outside the primary organization's direct control.

Potential actions

EY clients who received a notification letter should place credit freezes with all three major bureaus immediately and monitor for fraudulent tax filings. A freeze prevents new credit accounts from being opened regardless of what data the attacker holds.
Organizations that use EY for tax services should request confirmation from their EY account team about whether their specific engagement data was included in the incident scope, since EY has not publicly disclosed the full client list.
Security and IT teams should audit whether sensitive client data is being attached to support tickets in any IT service management platforms used by the organization. Where it is, enforce data classification policies that restrict attachment of tax or financial documents in ticketing systems.

The Sip

Fifteen days. That is how long an attacker had access to a platform carrying client tax documents at one of the world's largest professional services firms before anyone noticed. The sensitive data was not in the tax platform. It was in the help desk. That is where it got taken.

03 CriticalSonicWall SMA1000UTA0533

SonicWall's SMA1000 zero-days were being exploited since June 22, three weeks before they appeared on CISA KEV

Volexity tracked the exploitation to a threat actor it calls UTA0533, confirmed active since at least June 22. SonicWall and CISA added the vulnerabilities to KEV on July 15. Organizations that patched this week may have had a three-week exposure window before a patch was even available.

CVEsCVE-2026-15409
CVE-2026-15410

First exploitedJune 22, 2026
(Volexity IR)

KEV addedJuly 15, 2026

ActorUTA0533

Sources The Hacker News SecurityWeek

What happened

Volexity disclosed Sunday that it had traced the exploitation of CVE-2026-15409 and CVE-2026-15410, the SonicWall SMA1000 unauthenticated remote code execution and server-side request forgery zero-days, to an incident response investigation in which active exploitation was confirmed as early as June 22, 2026. Volexity is tracking the responsible threat actor as UTA0533. SonicWall published its advisory and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on July 15, more than three weeks after Volexity's first confirmed exploitation date. The SMA1000 is SonicWall's enterprise SSL VPN gateway, designed to sit at the internet perimeter and authenticate users before granting access to internal networks. CVE-2026-15409 is an unauthenticated remote code execution flaw. CVE-2026-15410 is a server-side request forgery that allows an attacker to probe internal network services and route requests through the appliance. UTA0533's initial access method, post-compromise activity, and targets have not yet been fully detailed in public reporting.

Why it matters

A three-week exploitation window before public disclosure means organizations had no vendor advisory, no patch, and no CISA KEV notification to act on while attacks were already underway. Any SMA1000 appliance accessible from the internet during June and July should be treated as potentially compromised regardless of when the patch was applied, because the patch only closes the door. It does not determine whether anyone walked through it in the weeks before it was available. Post-patch forensic review of the appliance and any systems it provided access to is not optional at this point.

Don't miss

This is the same pattern documented in this brief across Oracle EBS in Issue 76, Adobe ColdFusion in Issue 81, and now SonicWall. In each case, exploitation was confirmed by independent researchers or incident responders before the vendor's advisory publicly acknowledged it. The SonicWall case is notable because the gap between first confirmed exploitation and KEV addition is three weeks on an internet-perimeter device. An organization that uses independent threat intelligence feeds, honeypot data, or incident response partnerships as early-warning signals had a much narrower window of exposure than one relying solely on vendor advisories and CISA catalog additions.

Potential actions

Apply the SonicWall patch for CVE-2026-15409 and CVE-2026-15410 if not already done. Then conduct a forensic review of the SMA1000 appliance logs from June 22 onward for anomalous authentication attempts, unexpected outbound connections, configuration changes, and file system modifications.
Review access logs for internal systems that the SMA1000 provided entry to during the June 22 to July 15 window. A compromised VPN gateway gives an attacker a foothold on the internal network, and lateral movement may have occurred before the appliance was patched.
Contact Volexity or your incident response provider if you identify suspicious activity from this period. UTA0533's tactics, techniques, and indicators are likely to be more fully documented as Volexity's investigation continues.

The Sip

Three weeks of exploitation before a patch was available and before KEV carried the entry. That is three weeks of attackers using the front door while defenders had no way to know the door was open. Patch it. Then find out whether anyone came through while it was.

Cross-source standouts

Three stories, three different attack surfaces, one recurring problem: the gap between when exploitation begins and when defenders find out

WordPress auto-updates help when they land. They do not cover staging environments, manually managed installs, or the time between a working public exploit appearing and administrators checking version numbers. The EY breach ran for 15 days before detection, and notifications arrived 90 days after the window closed. The SonicWall zero-days were exploited for three weeks before the vendor advisory went public. Each of these stories has its own technical details, but the defensive failure point is the same: the person who needed to act did not know action was needed yet. The common thread across this brief's coverage of the vendor acknowledgment gap, from SharePoint in Issue 78 to ColdFusion in Issue 81 to SonicWall now, is that the signal defenders need arrives after the window attackers use. Organizations that monitor independent threat intelligence, honeypot feeds, and incident response partner advisories consistently have a shorter gap between exploitation and awareness than those that rely on vendor advisories as a primary signal.

The EY breach and the TRICARE breach from Issue 87 both point at the same structural problem in how sensitive data moves through enterprise IT

TRICARE beneficiary health records sat in TriWest's systems during a two-week attacker access window. EY client tax documents sat in a support ticket system during a 15-day attacker access window. Neither platform was the primary system of record for that data. In both cases, the data ended up there through routine workflow: employees attaching documents to support tickets, beneficiary data flowing through a managed care coordinator's operational systems. The security scrutiny those secondary platforms receive is generally lower than primary applications, their access controls are often broader, and their monitoring is less intensive. The implication is not that these breaches were avoidable through better patching. They were avoidable through a different understanding of where sensitive data actually lives in an organization's environment. Data classification programs that track where sensitive information flows, not just where it is stored, catch this category of risk. Auditing support ticket platforms, IT service management tools, and workflow systems for sensitive data attachments is not a routine security control in most organizations. It probably should be.

Still watching

Days 2–6

LegacyHive (Issue 88 · Nightmare Eclipse, unpatched) — Windows User Profile Service privilege escalation, working proof-of-concept confirmed on fully patched July 2026 systems. No CVE, no fix. Monitor User Profile Service for unexpected hive loads. Three prior Nightmare Eclipse disclosures were exploited before patches arrived.

Day 3

SharePoint three-CVE campaign (Issues 86 and 87 · CISA alert) — CVE-2026-45659, CVE-2026-32201, and CVE-2026-56164 all actively exploited, Storm-2603 ransomware named. Apply July patches, enable AMSI in full mode, remove from internet exposure where feasible.

Day 5

Zoom CVE-2026-53412 (Issue 87 · CVSS 9.8 account takeover) — no exploitation confirmed. Push Zoom Workplace for Windows 7.0.0 through endpoint management. Do not rely on self-update for a CVSS 9.8 flaw.

Day 4

CitrixBleed 2 CVE-2025-5777 (Issue 85 · DragonForce) — seven-step ransomware playbook confirmed by Huntress. Patch NetScaler, terminate all active sessions, review logs for binary-data login failures. Patching without session termination leaves stolen tokens active.

Day 6