The Kudankulam Nuclear Power Plant in Tamil Nadu has not been hacked.
That sentence needs to be established first, clearly and without qualification, before anything else is discussed. The operational systems of India’s largest nuclear facility, including the reactor cores, the control systems, and the infrastructure supplied by Russia’s state-owned Rosatom, are isolated from the environment where this breach occurred. NPCIL, which operates India’s nuclear fleet, has not been breached. The plant is generating electricity and continues to do so.
That is the factual baseline. Now here is the part that still warrants serious national attention.
On July 15, 2026, Reuters reported that the ransomware group World Leaks had posted on its dark web site a large cache of files that it claimed belonged to Anil Ambani’s Reliance Group, specifically relating to the Kudankulam Nuclear Power Plant’s Units 3 and 4. The files, accessible only through a specialised browser, numbered 858,000 in total. Of these, approximately 19,000 were identified as potentially sensitive, containing what appeared to be engineering blueprints, supplier details, inspection records, equipment reviews, and insurance policies related to the nuclear facility’s construction project.
Reliance Group confirmed to Reuters that a partial breach of its data had taken place from a server hosted by Yotta, a third-party Indian data centre service provider. The government had been informed. Reliance did not disclose what specific data had been compromised.
Reuters reviewed the documents but could not verify their authenticity.
CERT-In is investigating. NPCIL is in communication with Reliance. The Department of Atomic Energy and the Prime Minister’s Office did not respond to media queries.
This is what we know with reasonable confidence as of the date of this blog. What follows is an analysis of how this happened, what it means, and what should change.
How the Data Left the Building
The breach did not begin at Kudankulam. It began at a commercial data centre in India.
Yotta Data Services, the third-party data centre provider hosting a server for Reliance Infrastructure, detected suspicious activity on May 29, 2026. Yotta says it immediately terminated the activity and prevented what it believed was a ransomware execution attempt.
The problem is that data exfiltration and ransomware execution are two different events. World Leaks, like every modern double-extortion ransomware group, exfiltrates data before encrypting anything. The data movement happened before the May 29 detection. By the time Yotta terminated the suspicious activity, the 858,000 files were already on World Leaks’ infrastructure.
Reliance Infrastructure was informed by Yotta in late June about claims of a data breach made by external threat actors. By that point, approximately six weeks had passed since the initial intrusion activity was detected, and the group had already completed its exfiltration and was holding the data as leverage.
The ransom demand was not met. World Leaks published the data.
World Leaks did not answer questions from Reuters about the Reliance incident. The group typically publishes stolen corporate files online when victims refuse to pay the ransom demanded. Business Standard
This is the same operational pattern World Leaks used in the Tata Electronics breach in June 2026, where the group demanded $1.5 million and published the data after Tata did not respond to the demand. The same group, the same method, the same outcome. India’s critical infrastructure supply chain has now been successfully targeted twice in the same month by the same ransomware group.
What Was on That Server
Reuters reviewed the leaked documents. Several critical clarifications are necessary.
The leaked data does not relate to the nuclear reactors’ core systems. The documents posted on World Leaks do not appear to relate to the nuclear reactors’ core systems, which are supplied by Russia’s state-owned Rosatom. The Express Tribune
What the documents reportedly do contain is this: Purported blueprints for the ventilation and cooling systems used in Unit 3 and Unit 4, as well as what appeared to be the complete floor layout of a common control room. The files also included what appeared to be vendor proposals, a list of approved suppliers, and a record of a 2024 meeting about a joint inspection by the Nuclear Power Corporation and Reliance, with photos of equipment. The Express Tribune
One document reportedly described an insurance policy providing up to $112 million in coverage if either Unit 3 or Unit 4 were affected by an act of terrorism, per The Week’s reporting on the incident.
The data breach could pose a serious risk to the safety of the plant, says Nickolas Roth, a senior director at the Nuclear Threat Initiative, which advises governments and monitors nuclear security in various countries. Outlook India
The significance of this assessment is specific. Supporting infrastructure documentation, while not providing access to operational systems, gives adversaries a detailed map of how a facility is built, what its dependencies are, and where its vulnerable points might be. This is information that should never have been on a commercial data centre server without the highest levels of access control, encryption, and monitoring.
This Is Not the First Time Kudankulam Has Been Here
The current incident is the second confirmed cybersecurity event linked to the Kudankulam Nuclear Power Plant. The first happened in 2019.
Malware tied to a North Korean hacker group was found on the plant’s administrative network in 2019. At the time, the Nuclear Power Corporation said the matter was investigated immediately, and plant systems were not affected. Republic World
The 2019 incident involved DTRACK malware linked to the Lazarus Group, a North Korean state-sponsored threat actor. The malware was found on the administrative network, not the operational network, and NPCIL maintained that critical systems remained unaffected.
The two incidents are structurally different. In 2019, the attack attempted to penetrate the administrative network of the nuclear facility itself. In 2026, the attack succeeded against a contractor’s commercial data server. But the common thread is that in both cases, supporting environments around the facility, not the core operational systems, were the point of exposure.
This pattern is documented across nuclear security incidents globally. Attackers who cannot reach the hardened core of a nuclear facility target the ecosystem surrounding it: contractors, suppliers, construction partners, administrative systems, data archives. The core is protected. The supply chain often is not.
The Three-Layer Failure This Incident Exposed
The Kudankulam supply chain breach represents three distinct failures that compounded each other.
- Layer 1: The facility’s own data governance for contractor relationships
When NPCIL awarded Reliance Infrastructure the contract to design and build infrastructure for Units 3 and 4 in 2018, what data security requirements came with that contract? Specifically, what requirements governed how Reliance stored, handled, and protected the nuclear construction documentation generated during the project? The fact that engineering blueprints for a nuclear facility’s ventilation, cooling systems, and control room layout ended up on a commercial third-party data centre server suggests those requirements were either absent, inadequate, or not enforced.
Nuclear project documentation is not generic commercial data. It is critical infrastructure information that, in the wrong hands, can be used to map facility weaknesses. The security classification of this data should have mandated storage, access, and handling requirements far beyond what a standard commercial data centre provides.
- Layer 2: The contractor’s own data environment
Reliance Infrastructure is a major Indian conglomerate. The decision to store nuclear construction project files on a server at Yotta, a commercial data centre provider, reflects a broader organisational judgment that this data did not require a more controlled environment. That judgment, whatever its logic, resulted in nuclear facility blueprints being co-located in an environment whose security posture was designed for commercial workloads, not critical national infrastructure documentation.
This is the same failure we documented in the Tata Electronics breach, where Apple and Tesla trade secrets ended up exposed through a contractor environment. The pattern is identical. High-value IP or sensitive national infrastructure data held on infrastructure designed for ordinary commercial workloads, without security controls proportionate to the sensitivity of the content.
- Layer 3: The data centre’s monitoring capability
Yotta detected suspicious activity on May 29. That detection is to their credit. But the critical question is what happened before May 29. World Leaks exfiltrates data before any encryption attempt. The detection of ransomware execution was not the detection of data theft. If the exfiltration completed before May 29, the detection of the encryption attempt was already too late to protect the data.
The monitoring capability needed to protect data of this sensitivity is not standard commercial data centre monitoring. It requires real-time detection of anomalous data transfer volumes, unusual access patterns, and movement of files across boundaries that should trigger alerts before any significant volume of data has left the environment.
What Should Have Been in Place
These are not abstract recommendations. They are the specific controls that, had they existed, would have materially changed the outcome.
- Mandatory data classification for all nuclear project documentation
Every document generated in the context of a nuclear facility construction project should have been classified at an appropriate sensitivity level. Documents describing ventilation systems, cooling infrastructure, and control room layouts of a nuclear facility are not commercial IP. They are critical infrastructure documentation. Classification is not optional for this category of content. It should trigger automatic requirements for how the data is stored, who can access it, and on what infrastructure it can reside.
- Dedicated secure environments for classified project data
Critical national infrastructure documentation should not reside on commercial cloud or data centre environments without explicit, audited security controls that match the classification level of the data. A secure project data environment for nuclear construction documentation would include: access controls limited to specific, named individuals with documented need; multi-factor authentication for every access event; full logging of every file access, download, and transfer; anomaly detection for bulk data movements; encryption at rest with keys managed separately from the data; and network isolation from general corporate IT environments.
The fact that this data was on a standard commercial server at Yotta means none of these controls were in place at the level the data sensitivity required.
- Exfiltration detection as a mandatory control for sensitive data environments
EasyNAC and similar network-level monitoring tools exist specifically to detect anomalous data movement patterns within an environment. An environment holding nuclear construction blueprints should have had real-time monitoring of data transfer volumes, destinations, and session behaviour. A bulk exfiltration of 858,000 files does not happen in a single small transaction. It generates a pattern of network activity that, with the right monitoring in place, is detectable before significant data volume has left.
- Security audit rights in contractor agreements for critical infrastructure projects
NPCIL’s contract with Reliance Infrastructure presumably included construction standards, quality requirements, and project governance obligations. Whether it included security audit rights for how Reliance handles project documentation is the question this breach raises. For any contractor working on critical national infrastructure, the owner entity should have the contractual right to audit the security posture of the contractor’s data environment. This is the equivalent of what RBI now requires for vendor management in financial services, applied to critical infrastructure contracts.
- Supply chain security requirements extended to sub-contractors and data centre partners
The breach occurred not at Reliance Infrastructure’s own facilities but at Yotta, which Reliance engaged as a data centre provider. This is the supply chain multiplication problem in its most consequential possible form. The security requirement flowing from NPCIL to Reliance must also flow from Reliance to every entity that touches the project data. A contractor that stores sensitive project files with a third party must impose on that third party the same security requirements the client has imposed on them. In this case, that chain appears to have been either absent or not enforced.
What Happens Next
Several processes are now running in parallel.
CERT-In is investigating the incident. NPCIL has been in communication with Reliance. The scope of their investigation will need to answer several questions: Was any additional data beyond the 19,000 sensitive files actually sensitive enough to create security risks? Were the documents accessed by external parties beyond the initial exfiltration by World Leaks? Are there other servers in the Reliance project environment that may have been accessed but not yet identified?
The Department of Atomic Energy and the regulatory bodies for nuclear security in India will need to assess whether the leaked infrastructure documentation creates any requirement for physical or operational security changes at the facility. Nuclear security experts have already described the exposure as potentially serious.
Internationally, India’s nuclear security partners, including Russia through Rosatom, will be watching this incident closely. The Kudankulam plant is a flagship Indo-Russian collaboration. The fact that Russian-supplied core systems were not involved in the breach is important context, but the broader question of whether the construction and infrastructure documentation environment surrounding a joint nuclear project met appropriate security standards is a question that partnership frameworks will need to address.
For World Leaks, the publication of the data without receiving a ransom from Reliance follows their established pattern. They have made no further public statement on the Reliance breach as of the date of this blog. The data, now publicly accessible through their dark web site, cannot be retracted.
The Pattern World Leaks Is Demonstrating
In the past 30 days, World Leaks has claimed breaches involving Tata Electronics (Apple and Tesla manufacturing secrets), and now a contractor to India’s largest nuclear facility.
This is not a coincidence, and it is not opportunistic targeting of random organisations. It reflects a deliberate strategic approach to supply chain multiplication. Breach one high-value contractor and the data you receive is more valuable, more sensitive, and more likely to generate a ransom payment than anything you would find in most commercial targets.
India’s status as a growing manufacturing and technology hub means its contractor ecosystem now holds some of the most strategically valuable data in the world. Apple manufacturing specifications. Tesla engineering drawings. Nuclear facility construction blueprints. All of this data migrated to India as the country won more of the world’s most consequential industrial work. And all of it is only as secure as the contractor environments that hold it.
The Kudankulam incident makes this concrete in a way that commercial IP theft does not. When nuclear construction documentation appears on a dark web site, the conversation about contractor security in critical infrastructure projects moves from recommended practice to urgent national necessity.
Final Thought
Somewhere in a data centre managed by Yotta, a server belonging to Reliance Infrastructure held the construction blueprints for India’s most important nuclear facility. The server was on a commercial infrastructure platform. The security controls around it were commensurate with commercial data, not nuclear infrastructure documentation.
Nobody made a decision to be careless. Someone made a decision to store project files on a data centre server, which is a normal and rational thing to do for most project documentation. The failure was not in that individual decision. It was in the absence of a security governance framework that would have intercepted that decision and said: this data category requires a different environment.
That framework, in the context of India’s critical infrastructure projects, does not yet exist in the way this incident has demonstrated it must.
The reactors are secure. The data around them is not governed to the standard that security requires. Those two facts now coexist in the public record, and addressing the second without waiting for another incident is the only appropriate response.
At Skeletos IT Services, we help Indian companies, contractors to critical infrastructure projects, and manufacturing organisations build the data governance and network security controls that match the sensitivity of what they hold. If your organisation is involved in government, defence, energy, or critical infrastructure projects and wants to understand whether your data environment meets appropriate security standards, we can help you assess it.
