Thousands of Vermont websites were exposed in mid-July to a newly disclosed WordPress security vulnerability that allows hackers to take complete control of an unpatched site without first obtaining a password.

WordPress has since pushed a forced security update to affected sites. But a forced update only reaches a site where the automatic update system is actually working — and on the sites least likely to be maintained, it often is not. Some Vermont sites are almost certainly still unpatched.

The problem is not confined to suspicious plugins, abandoned themes, or poorly designed websites. The vulnerabilities were found inside WordPress itself, the publishing software used by governments, nonprofits, schools, businesses, media organizations, political groups, churches, clubs, bloggers, and individuals throughout Vermont.

Full disclosure: FYIVT knows the territory firsthand — this site ran WordPress for years before moving to its own self-built publishing system earlier this month. Stories like this one are a large part of why.

WordPress released emergency security updates on July 17 after researchers disclosed two vulnerabilities that could be chained together to produce remote code execution. In practical terms, a successful attacker could create an administrator account, install malicious software, steal information, alter pages, redirect visitors, or use the server to attack other systems.

WordPress described the release as addressing "one critical and one high severity security issue" and activated forced automatic updates for affected installations, stating that "due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions."

More Than 8,000 Vermont Sites

There is no complete public registry of every Vermont website and the software it uses. However, technology-tracking company BuiltWith currently identifies 8,159 active WordPress customers associated with Vermont.

The results span colleges and universities, school districts, media outlets, utilities, banks and credit unions, museums, breweries and distilleries, nonprofits, state government subdomains, and thousands of small businesses and personal sites. This story does not name individual sites. Being built on WordPress is not itself a finding — a named site may well have been patched on July 17 — and a published list of specific sites serves no purpose for readers that the underlying source does not already serve better. Readers who want to know whether a particular Vermont organization appears can search BuiltWith's Vermont list directly, and site owners who recognize their own domain there should treat that as a prompt to verify their version rather than as a verdict.

The figure should be treated as an estimate rather than a precise count. Technology scanners count subdomains separately, include redirected domains, miss sites that conceal their software, and place a site in Vermont on the basis of a registered address that may have little to do with where the site is actually run. The reverse is also true: some of the largest entries on the Vermont list belong to multinational companies with real Vermont operations and Vermont mailing addresses, whose web properties may be administered from corporate offices in another state or another country. In those cases the exposure is genuine but the person who can patch it does not live here. The count also drifts week to week as scans refresh. Even allowing for all of that, it demonstrates that Vermont's potential exposure is measured in thousands of websites, not dozens.

The broad use of WordPress is unsurprising. As of late July, WordPress powered an estimated 41.2 percent of all websites worldwide and held approximately 59.1 percent of the content-management-system market.

Who Is Actually Vulnerable?

Not every WordPress site is affected.

The vulnerability at the center of the chain, identified as CVE-2026-63030, affects WordPress versions 6.9 through 6.9.4 and versions 7.0 through 7.0.1. Federal records describe it as "a REST API batch endpoint route confusion issue which, combined with the author__not_in WP_Query SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution." Chained, the two flaws let an unauthenticated attacker execute commands remotely and take control of the website.

WordPress versions before 6.8 are not affected by this particular vulnerability chain. Version 6.8 contained the SQL-injection issue but not the second flaw necessary for the complete remote takeover. Corrected versions are WordPress 6.8.6, 6.9.5, and 7.0.2.

That creates an unusual situation in which some very old installations may escape this specific attack while newer sites that were recently updated — but not updated again after July 17 — could remain vulnerable.

How many sites remain exposed is unknown. The cloud security firm Wiz measured 60 percent of organizations running WordPress with at least one vulnerable installation on the day of disclosure, and 25 percent with a vulnerable server reachable from the internet. Within 24 hours those figures had fallen to 50 percent and 10 percent as patches landed. No comparable measurement has been published since. What is clear is that the forced update cannot reach a site whose automatic updates were switched off, whose files are not writable by the web server, or whose owner has not logged in for years to notice that an update failed — which describes the neglected end of any list of 8,000 websites.

Security researchers have also reported active exploitation. The federal Cybersecurity and Infrastructure Security Agency added both vulnerabilities to its Known Exploited Vulnerabilities catalog on July 21, setting federal remediation deadlines of July 24 for the remote-code-execution flaw and August 4 for the SQL-injection flaw. Federal records characterize the attack as remotely accessible, automatable, requiring no user interaction, and capable of total technical impact.

The demonstration that launched wider public attention showed an attacker checking a WordPress site, uploading a web shell, and obtaining command-line access within seconds. The attack chained a route-confusion error in WordPress's batch-processing system with an SQL-injection flaw; it works against sites that do not run a persistent object cache, which describes a default WordPress installation. Analysts monitoring live attacks have observed intruders writing a PHP web shell into the WordPress cache directory and adding new administrator accounts to the database for continued access.

The Vermont Risk

For a personal blog, a takeover could mean deleted content, stolen passwords, malicious advertising, or visitors being redirected to scam sites.

For a business, the consequences could include interrupted sales, exposed customer information, damaged search rankings, fraudulent payment pages, ransomware, and loss of public trust. Vermont businesses also face legal obligations if customer data is exposed: the state's Security Breach Notice Act requires notice to affected consumers and to the Vermont Attorney General's office within specified deadlines.

For a nonprofit, school, municipality, or government-related organization, the danger may be greater. Such sites may contain donation systems, public notices, email lists, employee accounts, forms, meeting documents, application portals, or links that residents reasonably assume are trustworthy. Vermont municipalities and public entities can get help through the state's cybersecurity resource hub and no-cost MS-ISAC membership.

A compromised website can also serve as an entry point into a larger network if passwords are reused, outdated administrative tools are exposed, or the web server has access to internal databases and file systems.

What Site Owners Should Do

Every WordPress administrator should immediately check the version displayed under Dashboard, Updates.

Sites running WordPress 7 should be updated to at least 7.0.2. Sites remaining on the 6.9 branch should be running at least 6.9.5, and sites on 6.8 should be running at least 6.8.6. Administrators should confirm that the update actually completed rather than assuming automatic updates worked.

Owners should also review administrator accounts for unfamiliar users, inspect recently installed plugins, change hosting and WordPress passwords, enable multifactor authentication, update plugins and themes, and maintain an offline backup created before any suspected compromise.

Server access logs should be reviewed for unexpected requests to the WordPress REST batch endpoint (/wp-json/batch/v1), unexplained administrator creation, plugin uploads, or unfamiliar PHP files — particularly inside wp-content/cache.

If evidence shows that attackers obtained command execution, merely changing a password or deleting one suspicious plugin may not be enough. The safer response is often to preserve logs, rebuild the server from a known-clean installation, restore verified content, rotate all credentials, and patch the replacement system before returning it to service.

One more thing worth doing, and it costs nothing. If you recognize an organization on that BuiltWith list — the brewery, the school district, the town office, the museum, the credit union — or you happen to know whoever built its website, just tell them. A word from someone they know will land where a cold email from a stranger cannot: an unsolicited message warning that your site may be hacked and urging you to go check it immediately is, word for word, what an actual attacker sends, and anyone properly trained will delete it. Which leaves people who already trust each other as the only channel still working.

For thousands of Vermont site owners, the immediate question is simple: not whether they use WordPress, but whether somebody has verified that it is actually patched.