नेपाली
Nepal’s central bank is asking financial institutions to take precautionary measures against critical software vulnerabilities, but its own website remains inaccessible, raising questions about the regulator’s cyber preparedness and the timing of its response.
KATHMANDU, Nepal Rastra Bank (NRB) has issued a cybersecurity notice dated October 23, asking banks, financial institutions and payment service providers to strengthen security measures following the disclosure of two critical vulnerabilities in PHP on October 21.
The notice comes approximately two days after the vulnerabilities became public. Meanwhile, NRB’s own website remained inaccessible at the time of reporting, with the central bank circulating its notice through social media instead.
The situation raises an uncomfortable question for Nepal’s financial regulator: when banks are being told to strengthen their cybersecurity, how resilient is the central bank’s own digital infrastructure?
The website outage does not establish that NRB was affected by the PHP vulnerabilities, nor does it prove that the regulator delayed its response. However, the combination of a delayed public notice and an unavailable official website puts the focus on response readiness, communication continuity and transparency.
NRB has not established in the notice when it first alerted financial institutions, whether the temporary shutdowns were directed by the regulator or initiated by individual institutions, or whether the central bank’s own website outage is connected to the PHP vulnerabilities.
Two days after disclosure, questions remain
The PHP development team released security updates for the vulnerabilities on October 21. NRB’s notice is dated October 23, leaving an approximately two-day gap between the public disclosure and the regulator’s published warning.
That gap alone is not proof of negligence. NRB may have communicated with banks through private channels before publishing the notice. But without a clear timeline, the public cannot determine when institutions were alerted or how quickly the financial sector began taking protective action.
For a regulator overseeing critical financial infrastructure, timely threat communication is essential. Banks and payment providers need clear instructions to identify affected systems, apply patches and contain potential exposure before a vulnerability leads to disruption.
NRB should clarify when it first notified regulated institutions and what deadlines or immediate safeguards it required.
Critical vulnerabilities put exposed servers at risk
The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, were assigned a severity score of 9.2 under CVSS 4.0.
The flaws could allow unauthenticated attackers to execute malicious code remotely on vulnerable servers. Depending on the system and its configuration, successful exploitation could lead to system compromise and expose connected services to further attacks.
The PHP project released patched versions on October 21: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Organisations running affected versions need to apply the appropriate updates or isolate vulnerable services where immediate patching is not possible.
The vulnerabilities matter because PHP is widely used in websites and web applications. However, the existence of the flaws does not mean every website is affected; exposure depends on the software version, configuration and deployment.
NRB’s own website outage adds to the concern
The central bank’s website remaining inaccessible while its notice circulates through social media highlights a separate but important issue: the reliability of official communication during a cybersecurity event.
Social media can serve as a useful backup, but it should not become the only practical route for accessing time-sensitive regulatory notices. Banks, businesses, journalists and the public need dependable access to official circulars and updates.
NRB should explain why its website is unavailable, whether the outage is related to the PHP vulnerabilities and when normal access is expected to resume. Until that relationship is confirmed, the outage should not be presented as evidence that the central bank’s website was compromised.
The broader concern is whether critical institutions have tested arrangements to maintain services and communicate reliably when their primary digital systems become unavailable.
A shutdown is not the same as security
Temporarily taking websites offline can be a legitimate precaution when systems cannot be secured immediately. But shutting down a website is only a containment measure; it does not, by itself, demonstrate that the underlying systems are safe.
Affected institutions need to identify vulnerable components, apply patches, test systems and monitor for signs of exploitation before restoring services. NRB should also clarify what verification and reporting it expects from banks and payment providers before they resume normal operations.
The central bank’s notice does not establish whether any systems were exploited or whether customer data or financial assets were affected. Those questions require evidence, not assumptions.
The critical issue is whether Nepal’s financial sector received timely warnings and was prepared to act—not merely whether websites were taken offline after a serious vulnerability became public.
NRB’s response timeline, the unexplained unavailability of its own website and the lack of public detail about restoration arrangements make clear communication particularly important. The regulator needs to demonstrate that it can coordinate a rapid response, maintain access to official information and ensure that services return only when they are secure.
For a financial system increasingly dependent on digital infrastructure, cybersecurity preparedness cannot be measured by shutdowns alone. It must also be measured by the speed of response, the transparency of communication and the ability to restore services safely.
Sources: Nepal Rastra Bank notice dated October 23, 2026; PHP security releases; Google Cloud’s technical advisory; ENISA joint advisory.
NRB’s notice follows the disclosure of two critical PHP vulnerabilities by two days, while its own website remains inaccessible, raising questions about cybersecurity preparedness and regulatory response.
