Discover Faithlab and quickly learn who we are

Clients

Contact Us

Is Our Church Website Safe? An Honest Risk Check for 2026

Oct 22, 2026 | Article, Tools

If you’re a pastor, church administrator, or board member who saw this week’s headlines about a “critical PHP flaw” and wondered whether your church website is in danger, this post is for you. Several congregations we work with have asked us some version of the same question: Is Faithlab doing everything it can to protect our site?

It’s a fair question, and you deserve a straight answer rather than either reassurance or alarm. Here’s what is actually happening, where the real risk is, and how much of it applies to a church site on managed hosting.

The short version

  • This week’s PHP vulnerability is serious, but it lives at the server level, the layer managed hosts patch for you, usually within hours.
  • Most WordPress danger doesn’t come from PHP or WordPress itself. In 2025, 91% of newly reported WordPress vulnerabilities were in plugins and 9% in themes.
  • Attacks now move fast. For heavily targeted flaws, the typical time from public disclosure to mass exploitation is about five hours.
  • For a church site on Faithlab’s managed hosting with a lean, maintained set of plugins, overall risk is low to moderate. What remains sits mostly in plugins, passwords, and who has admin access.

What happened this week

On October 21, 2026, the PHP project released emergency fixes for two critical flaws (CVE-2026-109618 and CVE-2026-109619), each rated 9.2 out of 10. PHP is the programming language WordPress runs on; think of it as the engine under the hood. The flaws could let an attacker run code on a web server without logging in. Details leaked a day before the fix, and reports of attacks followed quickly.

Because the problem is in PHP itself, no WordPress update or plugin can fix it. WordPress.org said plainly that no WordPress update is required. The fix has to be applied on the server.

That is exactly where Faithlab’s managed hosting earns its keep. On managed WordPress hosting, the hosting company, not your church office, owns the server and updates PHP across its whole platform. Several managed hosts, such as what Faithlab provides, reported their customers were protected the same day. A church running its site on a do-it-yourself server, or on a bargain plan stuck on an outdated version of PHP, is in a very different position.

It isn’t only this week

2026 has been a busier year than usual. In July and again in September, WordPress released urgent security updates to its core software. In July, Patchstack saw attackers probing sites about 90 minutes after the fix went public. WordPress installs these security releases automatically on most sites, and managed hosts generally make sure they land.

The pattern matters: the gap between “a fix exists” and “attackers are using the flaw” has shrunk to hours. Good security now depends less on heroic effort and more on whether updates happen automatically and quickly.

Where the risk really lives

Headlines focus on big flaws in PHP or WordPress core, but the everyday risk to a church site is more ordinary. Patchstack’s State of WordPress Security in 2026 report found:

  • 11,334 new vulnerabilities in the WordPress ecosystem in 2025, up 42% from the year before.
  • 91% were in plugins and 9% in themes. Only six were in WordPress core, all rated low priority.
  • 46% had no fix available from the developer when they were made public.
  • In Patchstack’s tests, typical hosting-level defenses blocked only 12% to 26% of attacks aimed at these kinds of flaws.

That last point is the honest part. Managed hosting does an excellent job at the server layer. It can’t fully protect a website from a vulnerable contact form plugin, an abandoned event calendar, or a volunteer whose password is “Grace2019.”

In plain terms, the main exposures for a church site are:

  1. Plugins and themes, especially ones that are outdated, abandoned, or were installed for a one-time event and never removed.
  2. Passwords and logins: reused or weak passwords, and no two-factor authentication.
  3. Too many administrators: former staff, past volunteers, or a youth minister who left three years ago and still has full admin rights.

So, how risky is a church site?

Here is our assessment, layer by layer, for a typical church site on managed hosting:

  • Server and PHP: Low. Patched by the host, usually within hours of a release, including this week’s critical fix.
  • WordPress core: Low. Core vulnerabilities are rare, and security releases install automatically.
  • Plugins and themes: Moderate. This is where nine out of ten vulnerabilities live. The risk drops sharply when the plugin list is short, well maintained, and kept up to date.
  • Accounts and passwords: Moderate, and largely in your hands. No host can stop someone from logging in with a valid, stolen password.

Overall: low to moderate. That is a meaningfully safer position than most small-organization websites, but it isn’t zero, because nothing online is zero.

It also helps to keep in perspective what’s at stake. Most church sites don’t store credit card numbers or sensitive pastoral records; online giving usually runs through a separate, dedicated platform. The realistic harms are a defaced homepage, spam links injected for search engines, or a site that quietly redirects visitors somewhere unpleasant. Those are embarrassing and disruptive and worth preventing, but they are recoverable when good backups exist.

What’s handled for you, and what’s shared

Managed hosting covers the server: PHP patching, server-level firewalls, and the infrastructure underneath your site. Faithlab’s hosting includes automated PHP updates and patches and automated daily backups that we keep for up to a month.

The rest is a partnership. Here is where church leadership makes the biggest difference:

  • Turn on two-factor authentication for every account that can edit the site.
  • Update your plugins. It’s a simple click in the Dashboard to go to Updates and then run the updates. Just be sure to leave the window open until the updates complete.
  • Prune your user list. Anyone who no longer serves in that role should be removed or downgraded. Most people who post announcements need “Editor” or “Author,” not “Administrator.”
  • Use a password manager, and stop sharing one login among several people.
  • Ask before adding plugins. Every new plugin is new code on your site. If you need a feature, ask first whether something already installed can do it.

A small next step

This week, take ten minutes. Log in to your church website, go to Users, and look at who has Administrator access. If there’s a name you don’t recognize, or someone who no longer serves in that role, that is your first fix. While you’re there, make sure your own account has two-factor authentication turned on.

Caring for the tools of ministry is part of good stewardship. For many visitors, your website is the first door they walk through, and keeping it safe is a quiet way of keeping the welcome open.

If posts like this are useful, you can get them in your inbox — subscribe to the Faithlab blog. No sales pitches, just practical help for church and nonprofit communicators.

Sources