The Nepal Stock Exchange (NEPSE) has confirmed that the full day trading suspension it initially described to the public as a "technical problem" was caused by a ransomware attack, one that hit not NEPSE itself but Data Hub Pvt Ltd, the third party data centre hosting the Trade Management System (TMS) servers for 72 brokerage firms. The attack was detected in the early hours of Sunday, 20 September 2026, forced the closure of the secondary market on Monday, 21 September, and was resolved sufficiently for regular trading to resume at 11am on Tuesday, 22 September. The Securities Board of Nepal (SEBON) has since formed a five member inspection committee and ordered a full incident report. As of publication no threat actor has been named, no ransom demand has been publicly confirmed, and whether any data was exfiltrated remains unestablished.
A sourcing note: every account below comes from Nepali news outlets rather than from a CERT advisory, a regulator filing published in English, or a direct statement posted by Data Hub. The operative documents (Data Hub's letter to YCO Pvt Ltd, NEPSE's public notice, SEBON's press statement) are quoted second hand across those outlets. Details are attributed accordingly.
What Happened
Data Hub Pvt Ltd operates the data centre that hosts the trading infrastructure used by the majority of Nepal's brokerage community. The TMS itself was developed by YCO Pvt Ltd, which manages the trading systems on behalf of brokers; Data Hub provides the hosting and backup infrastructure. That split matters, because it is the chain along which the incident was communicated: Data Hub notified YCO, YCO notified the brokers and NEPSE, and NEPSE then acted.
On detection, Data Hub isolated and took offline the affected infrastructure, citing the risk that the ransomware had propagated to other connected networks. Because the TMS is interconnected with downstream systems, that isolation cascaded. YCO told the Stock Brokers Association of Nepal that multiple systems and services were affected, reportedly including trading management systems, CDS and Clearing (CDSC) related services, payment gateways and other linked platforms.
The Stock Brokers Association of Nepal then formally requested that NEPSE halt the market. NEPSE suspended secondary market transactions for the whole of Monday under Rule 21(1) of the Securities Listing and Trading Regulations, 2075, as reported by ICT Frame. NEPSE spokesperson Murahari Parajuli framed the decision as containment plus fairness: "We isolated the affected infrastructure to prevent the ransomware attack from reaching NEPSE's system after the problem occurred within Data Hub's infrastructure," he said, per OnlineKhabar. Peoples' Review adds a second rationale, that brokers hosted at other data centres could technically have traded, and NEPSE shut the entire market rather than allow unequal treatment of investors.
On the timing, accounts differ slightly and the discrepancy is worth stating plainly. Most reporting, including Republica, Farsight Nepal, ICT Frame and Peoples' Review, puts detection at approximately 5:30am on Sunday, 20 September, citing Data Hub directly. HamroBichar, relaying brokers quoted by The Kathmandu Post, places the hit at around 4am. OnlineKhabar splits the difference, describing detection "early Sunday morning, around 4am to 5:30am." The 4am figure may be a conflation with the backup snapshot, which Data Hub says was taken at approximately 4am, roughly ninety minutes before detection. Treat 5:30am as the detection time on Data Hub's own account and 4am as the last known good backup point.
The broker denominator also varies. Every source agrees 72 brokerage firms were hosted at Data Hub and affected. ICT Frame puts Nepal's total registered brokerages at 92; Peoples' Review says 90. Either way, roughly four fifths of the country's brokers were concentrated on a single data centre.
Recovery came from backup. Peoples' Review reports the pre attack backup was verified safe and usable and used to restore service. OnlineKhabar reports that systems were restored using backup data from Data Hub's disaster recovery centre in Butwal. Those accounts are compatible but not identical in detail, and no source specifies whether production was rebuilt in Kathmandu from DR data or failed over to Butwal.
What Was Taken
Nothing has been confirmed as stolen. This is an availability incident as publicly characterised, not a confirmed data breach, and the distinction should be held until evidence changes it.
Farsight Nepal states directly that the identity of the ransomware group has not been disclosed and that it is unclear whether attackers demanded a ransom or whether any data was taken. Peoples' Review, reporting after restoration, says further examination is still needed to determine how far the attack spread and whether any data was affected. Data Hub itself has said only that it is conducting investigation and forensic analysis to determine the full impact.
The exposure surface, however, is not trivial. The systems in scope hold brokerage account data for a retail investor base that Republica characterises as roughly 8 million investors whose holdings depend on the platform. Connected systems reportedly include CDSC depository services and payment gateways, which is where personally identifiable information, bank linkage and holding records would live. Investor data protection has been raised as a concern by HamroBichar and Farsight Nepal, but concern is not confirmation and no source reports evidence of exfiltration.
There is also an unresolved conflict over the ransom note itself, which bears on attribution. BugV founder Naresh Lamgade told OnlineKhabar that this "was not a normal hack" and that it "appears to have been a systematic and planned ransomware attack," noting that ransom notes are standard in such intrusions and that "it is possible that such a message exists within Data Hub but has not been made public." In the same piece, a senior Data Hub official is quoted saying the incident appeared to differ from the conventional pattern with respect to ransom messaging. Both positions are single source and in tension. Until SEBON's committee reports, the honest read is that the public does not know whether a ransom note was left, found, or paid.
Why It Matters
This is a textbook concentration risk failure at national scale, and the target selection is the point. The attackers did not need to breach an exchange with a regulator, a security budget and a compliance perimeter. They breached the hosting provider sitting underneath 72 of its members, and the exchange closed anyway.
Three things generalise beyond Nepal:
The blast radius was set by architecture, not by the attacker. NEPSE's own systems were reportedly never compromised. Trading stopped because roughly 80 percent of market participants shared one hosting dependency, and because the TMS was interconnected with clearing and payment systems such that isolating one meant isolating several. The attacker got a national market outage from a single mid tier vendor.
Isolation was fast and correct, and still cost a trading day. Data Hub pulled affected systems offline rather than risk lateral spread into NEPSE, and NEPSE declined a partial market rather than run an inequitable one. Both calls look defensible. The lesson is not that the response was slow; it is that when recovery requires forensic clearance before restoration, a clean backup buys you a day, not an hour.
The "technical glitch" framing did real damage. NEPSE's public notice described an unresolved technical problem at Data Hub without a detailed account of the cyber incident, per HamroBichar; it took investigative reporting, notably by The Kathmandu Post, plus Data Hub's own letter to YCO, to establish ransomware publicly. For an exchange whose product is orderly price formation, a one day gap between what operators knew and what investors were told is a credibility cost that outlasts the outage.
The regulatory response has been comparatively quick. SEBON formed a five member technical inspection committee led by an Executive Director, tasked with inspecting the affected data centre, assessing network vulnerabilities and recommending preventative measures, per ICT Frame. SEBON directed NEPSE and market authorities to submit a comprehensive report by Ashwin 12 (28 September), covering the exact cause and vector of the breach, systemic vulnerabilities in the Data Hub server architecture, and the cybersecurity frameworks needed going forward. That deadline is the next thing worth watching.
The Attack Technique
The initial access vector is not publicly known. No source in this reporting set identifies the ransomware family, the affiliate, the exploited vulnerability, or the intrusion path, and none claims to. SEBON's committee has been explicitly tasked with determining the vector, which is itself confirmation that it had not been established as of 22 September.
What can be observed from the incident shape:
- Timing consistent with deliberate operational selection. Detection between 4am and 5:30am local on a Sunday, ahead of the Monday session, is the pattern of an actor executing outside staffed hours rather than an opportunistic detonation. Lamgade's assessment of a "systematic and planned" operation rests on this kind of reasoning rather than on forensic artefacts.
- Hypervisor or shared infrastructure impact rather than single tenant. 72 tenants degrading together points at the hosting layer, not at 72 separate broker endpoints. That pattern is the signature of virtualisation or management plane compromise, which is how most large scale hosting provider ransomware plays out, though no source confirms it here.
- Lateral movement genuinely uncertain, not rhetorically uncertain. Data Hub kept systems offline specifically because propagation to connected networks was suspected but unproven, and Peoples' Review confirms the spread question was still open after restoration.
- A backup that survived. The 4am snapshot was held isolated from the main network and was intact post incident. Whether that isolation was designed segmentation or the attacker simply did not reach it before detection is not stated anywhere in the reporting.
Anyone assigning attribution to a named group at this stage is ahead of the evidence.
What Organizations Should Do
Map your single provider chokepoints and price the outage. The question is not whether your hosting provider is competent; it is how many of your peers and counterparties share it. If a single data centre outage takes down 80 percent of your market's participants, you have a systemic dependency that no individual firm's security programme addresses. Exchanges, clearing houses and regulators should be maintaining a concentration register of where members actually host.
Test restoration under forensic hold, not just backup integrity. Data Hub's backup was clean and isolated, and the market still lost a day, because systems could not be restored until forensic analysis cleared them. Run the drill that assumes you cannot trust production until it is examined: how long does a clean room rebuild from your DR site actually take, and who signs off that it is safe to reconnect?
Segment the interconnections before you need to. The cascade here ran from TMS into CDS and Clearing services and payment gateways. Inventory every system that trusts your trading platform's network position, and verify that isolating one does not force you to isolate all of them. Treat that map as an operational artefact reviewed quarterly, not an architecture diagram from procurement.
Put security terms in the vendor contract with teeth. Require your hosting and platform vendors to contractually commit to incident notification timelines, forensic evidence preservation, independent post incident reporting, and your right to audit. ICT Frame's recommendations for Nepal's market specifically call for regular third party security assessments and investment in cybersecurity staffing at the provider level. The customer is the only party with leverage to demand it.
Fix disclosure before the incident, not during it. Decide now who authorises the word "ransomware" in a public statement, and what the threshold is. NEPSE went from "technical problem" to confirmed ransomware in roughly 24 hours under press pressure. A pre agreed holding statement that says "a security incident at a third party provider" is both truthful and fast, and it does not require retraction.
Verify the ransom note question in your own IR playbook. The conflicting accounts here, one expert saying a note likely exists and has not been made public, a Data Hub official saying the pattern was unconventional, illustrate how quickly attribution narratives fill an evidence vacuum. Ensure your responders know to preserve, document and escalate ransom artefacts as evidence, and that legal and comms agree in advance on what gets disclosed.
For firms with exposure to Nepal's capital markets: the SEBON report due 28 September is the next substantive disclosure point. Until then, treat any account of the attacker's identity, the ransom, or data theft as unverified.
Sources: NEPSE’s ‘technical glitch’ was a ransomware attack. What happened?... | Data Hub Ransomware Attack NEPSE Trading Halted Backup | SEBON Investigates Suspension of Share Trading Ransomware | Ransomware attack on Data Hub forces stock market to halt trading... | Glitches on stock trading platform risk investments of 8 million in... | Ransomware attack shuts stock market as investors raise security co... | Why Nepal’s Stock Market Was Shut on Monday: Ransomware Attack Disr... | NEPSE trading resumes after ransomware attack - Peoples' Review