Skip to content

Checking and responding to a critical vulnerability on your organisation's website

Websites run by civil society groups, associations and small media outlets are usually maintained by a hosting service, a hosting provider or an outside web studio. When a serious flaw turns up in some piece of software underneath the site, the person responsible for the website is often not an engineer, yet still has to decide whether the site is affected and whom to ask to deal with it.

This page is for that person: the administrator at an association, the programme officer at an NGO, the editor at a small outlet. It uses the October 2026 PHP vulnerabilities as its example. The dates and version numbers for that incident are gathered in the box below, and the approach applies to similar cases later on.

Example: the October 2026 PHP vulnerabilities

PHP is the software underneath site builders such as WordPress that runs the website's code. On 20 October, two vulnerability identifiers (CVE-2026-109618 and CVE-2026-109619; a CVE is the standard public identifier for a vulnerability) leaked before their planned disclosure. PHP released fixes in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. The two flaws could let an attacker who is not logged in run code on the server. WordPress.org's announcement explains that this is not a flaw in WordPress itself and that no WordPress update will be released for it; what needs updating is PHP on the server. A 22 October alert from the Taiwan Computer Emergency Response Team/Coordination Center (TWCERT/CC) says proof-of-concept code (code that demonstrates the flaw can be exploited) has appeared online, and Cloudflare has also observed attack traffic.

If you are short on time, do these three

  1. Find out where the site is hosted and who updates the software underneath it; the next section shows how
  2. Send the vulnerability identifiers to whoever is responsible and ask for a written answer on whether and when they have patched. If your contractor pays the hosting bill on your behalf, send it to the contractor
  3. Once they confirm the patch is in place, change the passwords on the site's admin accounts and turn on two-step verification

Where the site lives, and who is responsible for each layer

A website roughly divides into three layers. At the top is the site software, such as WordPress with its themes and plugins. In the middle is the software that runs the site software, such as PHP. At the bottom are the operating system and the server. Whichever layer the flaw is in, you need the person responsible for that layer.

The PHP flaws are in the middle layer. Automattic, the company that operates WordPress.com, explains that this is a fix to the runtime environment, which updating WordPress, themes or plugins does not reach. The "Update" button in the admin dashboard usually updates only the top layer.

Where the site lives Who updates the site software Who updates the runtime and operating system
A hosted service where you sign up for an account and build the site, such as WordPress.com The provider or you The provider
Rented hosting (virtual or shared hosting), usually with a control panel supplied by the hosting provider You or your contractor The hosting provider
A cloud server, your own server, or everything handed to a contractor You or your contractor You or your contractor

If you are not sure which applies, look at who the annual hosting fee is paid to, and whose account you log in with to reach the admin dashboard. The domain registrar and the hosting provider are not necessarily the same company. If the contractor pays for hosting on your behalf and the organisation holds no hosting account itself, go to the contractor and have them check with, or act through, the hosting provider.

For a site on a hosted service, the provider's announcement is enough. In the PHP case, Automattic says sites on WordPress.com and its other hosted services are already protected and administrators do not need to change any settings. Sites like these only need the three things at the end of "Checks after patching": change the admin passwords, review the list of administrators, and turn on two-step verification. If you rent hosting or rely on a contractor, carry on to the next section.

Questions for your host or contractor

Include the vulnerability identifiers in your message so they can look things up faster, and ask for a written reply. Five things you can ask:

  1. Which version of PHP the site runs, whether and when these two vulnerabilities were patched, and whether the PHP service was restarted after the update
  2. Whether the fix was an upgrade to the new official release or an update to the server operating system's packages (the two produce version numbers that look different; see the next section)
  3. Whether they saw any unusual access before the patch went in, and whether they can help check the logs from the day the vulnerability details leaked onward
  4. What the organisation needs to do on its side, such as which passwords to change
  5. Whether the version in use is still within PHP's official support period and, if not, the timeline and cost of upgrading

If the reply is "it's been taken care of", ask them to add the version number and the time of the patch, so you have something in writing to check against later. Once code that exploits the flaw has been published, the shorter the wait the better. If there is no reply that day or the next, or they cannot tell you the version number, this page recommends treating the site as not yet patchable and reading "Options when patching is not yet possible".

Reading version numbers

For a WordPress site, WordPress.org's announcement says the PHP version is shown in the English admin interface under "Tools > Site Health > Info > Server". This page has not checked the menu names in other interface languages. For a site that does not run WordPress, ask your host or contractor for the version number.

A PHP version number has three parts, and the first two identify the release series. Compare against the official fixed release in the same series: for example, 8.4.27 or later for the 8.4 series and 8.3.36 or later for the 8.3 series are the patched official releases.

Server operating systems often backport the fix into the version they already ship, keeping the old version number. For example, the patched PHP package on Ubuntu 24.04 is 8.3.6-0ubuntu0.24.04.13. The 8.3.6 in that string is a different version number and cannot be compared with the official 8.3.36. Comparing them directly would lead you to conclude, wrongly, that the site is unpatched. When you see a number lower than the official fixed release, go by the written reply from your host or contractor.

The most direct use of the version number is to check whether it is past its support period. According to the supported versions page on the PHP website, 8.1 and earlier have reached end of support and no longer receive official updates. 8.2 reaches end of support on 31 December 2026.

PHP's announcement also says that some operating systems and long-term-support vendors provide backported fixes for older versions. The PHP 8.1 package on Ubuntu 22.04, for example, has a patched build, so for older versions too, the written reply is what counts. The PHP team has separately provided source-code patches for 7.4, 8.0 and 8.1, intended for people who build PHP from source themselves; organisations on rented hosting cannot make use of them.

A site on a version past its support period belongs in an upgrade plan. Upgrading may affect compatibility with the site software, so ask your host or contractor to estimate the timeline and cost.

Options when patching is not yet possible

If the hosting provider has not patched yet, the version is past its support period and the provider has no backported fix, or the contractor cannot be reached, there are three options.

The first is to take the site offline temporarily. Any organisation can do this, but someone has to have the access to shut the site down. The Korea Internet & Security Agency (KISA) response guide for businesses, issued on 22 October, recommends considering cutting external access or suspending the service when you can neither update nor apply a temporary configuration change. WordPress.org's announcement also cites the UK National Cyber Security Centre (NCSC) in recommending that systems be taken offline when they cannot be patched immediately. The cost is that readers, members or donors cannot reach the site for a while. This page recommends that the head of the organisation make the call, and that the organisation explain on its social media accounts that this is a precaution and when the site is expected back.

The second is a protection service in front of the website, provided the site already sits behind a service such as Cloudflare; if you are not sure, ask your contractor. Cloudflare's blog post of 21 October says the corresponding web application firewall rules (WAF, rules that filter out attack traffic) were enabled by default for free and paying customers from that day. The same post also says that PHP still needs patching even with the firewall rules in place.

The third is changing the server's configuration. PHP's announcement lists several settings that can narrow some attack paths, but the announcement also says that only updating fully resolves the problem. Changing these settings requires server access, so it has to go to your host or contractor.

Sites that took any of these three routes still need the checks in the next section once the patch is in place.

Checks after patching

KISA's guide recommends that, after updating, you check the logs at least from the day the vulnerability details leaked onward. For the PHP flaws, that date is 20 October. For servers that were exposed to the internet the whole time before patching, the guide recommends changing the database passwords, the keys used to connect to outside services (API keys, the secrets the site uses to connect to other services) and the server's administrator passwords.

The guide also says that every website service running PHP has to be restarted after the update, otherwise the old version in memory keeps running. A 22 October press release from Taiwan's Administration for Cyber Security (ACS) under the Ministry of Digital Affairs likewise says that after updating you should review system logs and records of unusual access, and if you find suspicious activity, go on to confirm that accounts and credentials are secure. KISA's guide also says that finding nothing unusual in the logs does not mean the site is safe, and that updating and changing passwords go together.

Most of this has to be done by your host or contractor, which is what questions 1, 3 and 4 in "Questions for your host or contractor" are for. KISA's guide covers the server's administrator accounts, the database and the connection keys; it does not mention admin accounts for site software such as WordPress. What the person responsible for the website can do personally is change the passwords on the site's admin accounts, check the user list for administrators nobody recognises, and turn on two-step verification. These three are this page's recommendations. Wait until the patch is confirmed before changing passwords, since a password changed while the flaw is still open can be taken just the same (see Getting started with password managers).

When something looks wrong

The common signs this page has gathered: admin accounts or posts nobody recognises appear in the dashboard, the content of the home page has been replaced, visitors are redirected to another site, or the hosting provider tells you something is wrong with the site. When you see any of these, this page recommends taking screenshots and noting the time first, and asking the host or contractor to preserve the server logs. Do not delete suspicious files yourself; leave them for whoever handles the incident to assess.

For a server suspected of compromise, KISA's guide recommends cutting only the external connection first, without shutting down or restarting. A restart wipes traces of the attack held in memory, so preserve the evidence before you update and restart.

The ACS published the 資安事件應變處理行動指引 (Cybersecurity Incident Response Action Guidelines) in July 2026, written for non-technical staff at small and medium-sized businesses. Its six scenarios do not include a compromised website, but its handling of hijacked accounts, its checklists and its template public statements are useful references. The reporting channels the guidelines list are TWCERT/CC's online report form and, where a crime is involved, the local police. TWCERT/CC's general incident reporting page lists the accepted reporter type as "general businesses" (一般企業), and the page does not say whether civil society groups qualify.

If the site holds personal data about members, donors or petition signatories, Taiwan's Personal Data Protection Act also comes into play. Article 12, currently in force, requires that when personal data is stolen, leaked or altered as a result of a violation of the Act, the data subjects be notified by appropriate means once the facts have been established. The amendments promulgated on 11 November 2025 change this to notification as soon as a leak becomes known, and, where it meets certain criteria, a report to the Personal Data Protection Commission (the authority responsible for the Act after the amendments).

As of 22 October 2026, no commencement date has been set for the amendments. The text in the Laws & Regulations Database (in Chinese) is authoritative, and the background to the amendments is in Taiwan's 2025 data protection overhaul.

Preparing ahead

These five things can be done in ordinary times, and all are this page's recommendations:

  • Keep a list of the organisation's websites, noting where each is hosted, who is responsible, the contact named in the contract and where the admin account details are kept. Sites built for an event and old sites are the easiest to forget
  • Note which people's personal data each site stores, such as members, donors and petition signatories, so that if something happens you know whom to notify
  • Agree with your contractor how quickly they will reply and act when a critical vulnerability is disclosed
  • Make sure the site is backed up regularly and that the backups can actually be restored
  • Turn on two-step verification for the site's admin accounts, and do not reuse their passwords for other services

How this differs by situation

If someone in the organisation understands servers, the questions on this page can become an internal checklist, with that person checking directly against the operating system's security advisories. For an organisation that relies entirely on a contractor, what matters is "Questions for your host or contractor" and the written reply, and ideally the contract sets out a deadline for handling critical vulnerabilities in advance. For an organisation whose site is maintained by a single volunteer, the risk is that the volunteer cannot be reached, so at least one other person should know where the admin and hosting account details are kept. This section is this page's recommendation.

Taiwan in context

This section describes Taiwan's arrangements, where we are based; readers elsewhere should go by their own national authorities.

After the PHP flaws became public, TWCERT/CC issued a vulnerability alert on 22 October. The ACS press release of the same day says that government agencies and businesses were notified through security alerts, the National Information Sharing and Analysis Center (N-ISAC) and TWCERT/CC. N-ISAC's membership rules, revised in July 2026, list government agencies, the competent authorities for critical infrastructure, national computer emergency response teams and security vendors as members. Under those rules, civil society organisations are not among them.

The public channels open to civil society groups are TWCERT/CC's vulnerability alert page, its security news RSS feed and its monthly threat intelligence newsletter, and the newsletter cannot keep up with an urgent vulnerability. TWCERT/CC also runs a vetted membership scheme, 台灣資安聯盟 (the Taiwan cybersecurity alliance), whose rules list trade associations and incorporated bodies among its members. The page does not say whether small civil society groups qualify or whether there is a fee. An ACS press release from April 2026 mentions free registration as a TWCERT/CC member to receive threat alerts, and does not say whether that is the same alliance.

The ACS also publishes basic security guidelines and a self-assessment checklist for small and medium-sized businesses, and runs a security advice line at the 馬上辦服務中心 (SME service centre) in cooperation with the Small and Medium Enterprise and Startup Administration of the Ministry of Economic Affairs. All of these name small and medium-sized businesses as their audience, and the pages do not say whether non-profit organisations can use them.

Scope of this page

  • Only your own organisation's website. Checking or probing someone else's site requires their permission, and this page does not cover it
  • No exploitation methods or detection rules. For technical detail, go by the official advisories
  • No legal advice. For notification and reporting obligations when personal data leaks, consult a lawyer or the competent authority
  • The figures and version numbers in the example will go out of date. For a new vulnerability, go by the official advisories at the time

Where to get help

  • TWCERT/CC general incident reporting (in Chinese): an online form, or email [email protected]
  • Cybersecurity Incident Response Action Guidelines (in Chinese): the ACS's response steps for non-technical staff at small and medium-sized businesses. The six scenarios do not include a compromised website, but the checklists and template statements are useful references
  • 馬上辦服務中心 (SME service centre), 0800-280-280: security advice for small and medium-sized businesses, run by the ACS with the Small and Medium Enterprise and Startup Administration, toll-free
  • Access Now Digital Security Helpline: digital security help for civil society, media and human rights workers, free and around the clock, in ten languages (Chinese is not one of them); it verifies who you are before helping
  • Emergency help: step-by-step lists for hijacked accounts, devices and harassment