Why WordPress is a risky choice for government websites

WordPress for government websites carries a security burden that belongs in the purchasing decision. For a small municipality without dedicated website security capacity, it is a poor default choice. A low setup price means little if the office cannot reliably handle urgent vulnerabilities, investigate suspicious activity or recover from a compromise.

WordPress is a content management system, or CMS, used to publish website content. Its risks extend beyond an inconvenient update. Government organizations have suffered actual WordPress exploitation, including theft of sensitive records and unauthorized changes to public websites. The cases below explain what the evidence establishes and what municipal leaders should demand before renewing a contract.

Which government WordPress attacks have been documented?

A government website became the entry point for stolen records

In September 2026, GreyNoise published an investigation (opens in a new tab) into a July attack on an unnamed Western government organization. The attacker exploited two WordPress core vulnerabilities, CVE-2026-63030 and CVE-2026-60137, known together as wp2shell.

The attacker obtained website access, found database credentials and reached an internal SQL database. GreyNoise documented the theft of at least 18,566 records, including accounts, plaintext passwords and personal information associated with government and law-enforcement agencies.

Exposed credentials and access to other systems helped the intrusion spread. GreyNoise reconstructed the timeline from file timestamps, rather than publishing an official victim forensic report.

Another state entity was compromised in the same campaign

GreyNoise also identified (opens in a new tab) a Russian state entity in occupied Ukraine as a WordPress victim, without naming it or establishing a comparable data-loss total.

U.S. federal, state and local government sites were defaced

An April 2015 FBI advisory (opens in a new tab) confirmed that WordPress plugin exploitation had affected government websites, including federal, state and local entities. Attackers altered websites and disrupted their communications.

The FBI described relatively unsophisticated attackers using widely available tools against shared plugin weaknesses. Victims were not necessarily selected by name or type of organization. That matters to a village whose board assumes it is too small to interest a hacker.

This advisory documents defacement and disruption. It does not establish that resident records were stolen from each affected government. Its value is the documented attack pattern, not a claim that those historical vulnerabilities remain unpatched today.

These are different consequences of compromise. A board needs to consider both the confidentiality of information and whether residents can trust what appears on an official website.

Why is the problem bigger than outdated plugins?

The WordPress core software can have serious vulnerabilities too. In September 2026, WordPress published a critical page-template security advisory (opens in a new tab). Under the conditions specified in that advisory, an unauthenticated attacker could cause code to run on an affected installation. It lists affected versions and available fixes.

That is a separate issue from the July vulnerabilities in the government theft case. A provider who installed one security release still needs to track subsequent advisories.

Plugins add further exposure. They are extensions that supply functions such as forms or calendars. CISA's Known Exploited Vulnerabilities catalog (opens in a new tab) includes CVE-2020-25213 in the WordPress File Manager plugin, which allowed unauthenticated code execution through malicious file uploads. Inclusion means exploitation has been observed, rather than merely proposed by a researcher.

The purchasing implication is straightforward: somebody must maintain the core software, every extension and any custom code for the entire life of the website. Removing a troublesome plugin does not end that obligation.

Why can this be a poor fit for a small municipal office?

A township clerk should be able to publish a meeting packet without becoming responsible for application security. Yet a website contract can leave that responsibility unassigned. Ask who receives vulnerability alerts on a Friday evening, who can deploy a fix and who checks whether an attacker got in before it was applied.

WordPress's own security guidance (opens in a new tab) calls for keeping core software, plugins and themes current and choosing actively maintained extensions. That work needs a budget and a capable owner. It should not depend on an employee finding spare time between elections, records requests and board meetings.

Automatic updates do not settle the question. WordPress's update documentation (opens in a new tab) describes settings and scheduling issues that can prevent updates from running. Someone must check the result and deal with failures.

If a provider cannot show who performs that work and what was completed recently, recommend a different arrangement to the board. An affordable proposal should include the cost of operating the website responsibly.

What could a compromised municipal website expose?

Start with what your actual installation stores and can reach. A public website may hold form submissions, uploaded documents or account information. A separate payment service may keep financial information elsewhere. Have the provider document those boundaries instead of assuming that everything is public or that everything is connected.

Request a review of these areas:

Treat this as a request for evidence. A diagram and a review of permissions are more useful than a general assurance that the host is secure.

Why aren't backups and a security plugin enough?

Backups support recovery. They cannot recall information an attacker has already copied. Restoring yesterday's website also does not explain how the attacker entered or establish that all unauthorized access has been removed.

Ask for a recovery test and an incident response procedure. WordPress's backup documentation (opens in a new tab) explains that a typical restoration requires both the database and the files. Test document downloads and forms after restoration, and record what recent information was lost.

A security plugin needs maintenance too. Ask who reviews its alerts, how quickly that person responds and what investigation is included in the contract. The provider should be able to explain how controls work together and what happens when one fails.

An office that has a backup subscription but no response contact still has an unresolved operational problem.

What should governments demand from a replacement?

For a small government that cannot support WordPress's maintenance demands, the sensible direction is a service with fewer components for staff to manage and clear responsibility for security. Compare the proposed architecture and contract before choosing a replacement.

Use these requests when comparing providers:

• Identify the platform, extensions and custom code, with an owner for updates.
• Use individual accounts, appropriate permissions and multifactor authentication for privileged access.
• Explain where submissions go and which connections the public website actually needs.
• Name the emergency contact and describe investigation, containment and recovery responsibilities.
• Show what can be restored and what the government can export when the contract ends.

Apply these questions to Muniway and every other provider. A sales label such as "government platform" does not demonstrate a security control.

Keep accessibility in the procurement review as well. The DOJ Title II web rule (opens in a new tab) generally requires covered state and local government web content to meet WCAG 2.1 AA, with limited exceptions. Muniway's guides to government PDF priorities and Title II compliance dates explain that work. Review government website usability problems so the replacement also helps residents find information.

What should your board do before the next renewal?

Request a written security and maintenance assessment before extending the current agreement. It should identify unsupported software, overdue fixes, unnecessary access and any connections to sensitive information. Obtain an estimate for addressing the findings, including ongoing work.

Where the current arrangement cannot meet those needs, plan a migration. Keep urgent security work moving during the transition; a replacement project scheduled for next year does not protect today's website.

The decision should reflect the office's actual capacity. If safe operation depends on technical work nobody has the time, budget or contractual responsibility to perform, that website is the wrong fit for your government.