On 20 July 2026, the Hong Kong Computer Emergency Response Team Coordination Centre (HKCERT) rated multiple WordPress vulnerabilities as extremely high risk. Two days later, it updated the bulletin to confirm that two of the vulnerabilities had been exploited in real-world attacks. In plain language, attackers may be able to read or alter website data, or even make a site execute malicious commands (HKCERT, 2026).
For NGOs, the bulletin matters because websites are often connected to event registration, service enquiries, donations, electronic receipts and contact details. A technical failure can stop someone from completing an application, misdirect a payment, or prevent a request for help from reaching frontline staff.
A WordPress vulnerability may begin as a website problem, but its impact can spread across accounts, vendors, trusted public channels and the continuity of essential services.
Lingxi Insight: One Vulnerability Reveals Five Everyday Risks
WordPress has released the 7.0.2 security update, together with updates 6.9.5 and 6.8.6 for earlier branches. The fixes are not identical across those branches, so organisations still need to check vendor guidance against the version they actually use (WordPress.org, 2026). The US Cybersecurity and Infrastructure Security Agency has also added two of the vulnerabilities to its Known Exploited Vulnerabilities Catalog. Its remediation deadlines, however, apply only to designated US federal agencies, not as compliance deadlines for Hong Kong NGOs (CISA, 2026).
Non-technical colleagues can begin with three questions: Which service would be affected? Can the public distinguish genuine channels from fraudulent ones? Who takes over when the usual channel fails? When an organisation reviews the path through which the public uses a service, the relationship among the five risks becomes clearer.
Risk One: Websites, Registration Forms and Donation Pages
Five Digital Service Risks
Follow the public's service path to identify where risks may emerge and what non-technical colleagues need to assess first.
Website and Transaction Channels
Confirm that the public can complete registrations, donations and enquiries and receive confirmations, rather than checking only whether the homepage looks normal.
Accounts and phishing
Requests involving logins, payments or sensitive data should be verified separately through official channels or a known contact method.
Vendors and cloud services
Know who processes which data, which subcontractors are involved, how quickly incidents must be reported, and who can provide operational records.
Fraudulent identities and links
Give the public reliable ways to verify official web addresses, payment methods and messages issued by the organisation.
Disruption and recovery
Beyond bringing systems back online, reconnect any missed applications, payments, enquiries and service needs.
A website is the organisation's digital front desk. People use it to check services, submit registrations, make donations or leave contact details. A normal-looking homepage does not prove that forms, payments and notifications are working correctly.
When a vulnerability is exploited, pages may be altered, data may be accessed, and registration or donation flows may fail. After applying a fix, non-technical colleagues should complete a real registration, donation or enquiry journey to confirm that the public can do what they came to do and that the information and funds reach the right destination. The public page is only the visible layer. Privileged accounts and communication channels determine who can change pages, reset access and send messages in the organisation's name.
Risk Two: Email, Administrator Accounts and Phishing Messages
Email and administrator accounts are the keys to a digital service. They can reset passwords, change pages, receive form notifications, and send messages on behalf of the organisation to donors or service users. Fraudsters do not necessarily need to breach the website first. They may impersonate a platform, vendor or colleague and use claims such as a failed payment, an account anomaly or an urgent deadline to lead recipients to a fraudulent login or payment page.
In an alert about phishing messages involving a travel platform, HKCERT warned that even a message containing a real name or transaction details cannot be trusted on content alone. Requests involving an account or payment should be verified separately through the official website, app or a known contact method (HKCERT, 2026). For NGO frontline teams, the rule can be clear: Do not use the link in the message; use a known channel to verify any request to change payment details, log in again or disclose sensitive information. Accounts and messages can be impersonated, and the services behind them often depend on several providers.
Risk Three: Outsourced Vendors, Cloud Platforms and Systems Integration
An online form often depends on a website maintenance vendor, cloud host, payment service and email platform. Systems integration simply means the connections through which these tools pass data to one another. A gap in configuration, updates or incident notification at any point can interrupt the entire service path.
Guidance from the Office of the Privacy Commissioner for Personal Data states that when an organisation engages a data processor, the contract should specify the required security measures and incident-notification arrangements. Its cloud guidance also stresses the shared responsibilities of data users and cloud providers, while making clear that the organisation remains primarily responsible for personal data entrusted to cloud services (PCPD, 2022, 2025). Management needs to know what each vendor handles, who it subcontracts to, how quickly it must report an incident, and who can provide operational and audit records. Even if a vendor has not suffered an incident, fraudsters can still reproduce an organisation's name, pages and payment links outside its systems.
Risk Four: Fraudulent Websites, Payment Links and Organisational Identity
Fraudsters do not always need to breach an organisation's systems. A convincing copy of its website, payment page or message may be enough to deceive the public. In October 2024, the Social Welfare Department warned the public about a fraudulent website impersonating the department. The site sought to obtain personal and credit card information from members of the public, and the department referred the case to the Police (HKSAR Government, 2024). The case shows that even when people see a familiar name, logo or message, they still need a reliable way to verify that it is genuine.
An organisation can list its official web addresses and donation methods in one place on its website, establish an approval process for new or changed payment links, and make sure frontline staff know where to send a suspicious link. When a fraudulent page appears, existing channels must also tell the public quickly how to verify it. Protecting an organisation's digital identity gives service users and supporters a reliable way to verify that a website, payment request or message is genuine. The first four risks ultimately lead to the same question: When the public can no longer use or trust the usual channel, how does the service continue?
Risk Five: Service Disruption, Incident Response and Recovery
An incident is like the lights going out halfway through a service journey. A website may go offline, a registration may not arrive, payment records may not reconcile, electronic receipts may fail, or a service user may be unable to find a contact channel. Each of these can directly interrupt a service. The Office of the Privacy Commissioner for Personal Data describes an incident-response plan as a set of response and recovery procedures intended to minimise harm when an incident occurs (PCPD, 2022).
Before an incident, the organisation should decide when to suspend a form or donation page, how to preserve records, which backup channel will continue to receive enquiries, who will assess the impact on personal data, and who will approve external messages. Recovery has to achieve two things at once: bring the system back online in a stable condition, and reconnect any missed applications, payments and service needs.
Start with One Digital Service
Start with One Service
Use a real service such as event registration or online donation to identify the public path, system dependencies, the impact of failure and who takes over.
Map the public path
List every step from seeing a link to receiving confirmation.
Mark the dependencies
List the accounts, platforms, vendors and internal owners involved.
Assume one point fails
Assess what the public would experience if a page, account or service failed.
Decide who takes over
Assign responsibility for verification, suspension, backup service, assessment and external communication.
The five risks can first be tested against one real service. An organisation can choose event registration or online donation and use one short meeting to complete four actions:
- Map the public path. List every step from seeing the link and entering information to making a payment and receiving confirmation.
- Mark the dependencies. List the accounts, platforms, vendors and internal owners involved; technical detail can come later.
- Assume one point fails. Ask what the public would experience, and how the organisation would notice, if a page were changed, an account impersonated or a service interrupted.
- Decide who takes over. Assign responsibility for verification, suspension, backup service, incident assessment and external communication.
The purpose of this review is to prevent a technical problem from taking away the public's channels for registration, payment, enquiries or requests for help. On the other side of the website may be a family waiting for a service, a supporter who has just made a donation, or someone who needs a response within a limited time. A mature approach to information security is measured by what happens after a failure: people can still find the service, receive a response, and trust that their information and support are being handled with care.