The Kido Nursery Breach - How a GitHub Repository Exposed 8,000 Children

Education Security

The Kido Nursery Breach - How a GitHub Repository Exposed 8,000 Children

This episode is sponsored by Authentrend, providers of security key solutions that help organisations implement robust multi-factor authentication. Learn more about their FIDO2-certified security keys at authentrend.com


When Security Through Obscurity Fails Spectacularly

The Kido nursery breach shocked the UK in September 2025, affecting approximately 8,000 children across 18 nurseries. But while most coverage focused on the ransomware gang’s demands and tactics, a critical detail emerged that every school and nursery needs to understand: the breach wasn’t just sophisticated hacking. It was the result of publicly accessible code containing sensitive credentials.

The GitHub Revelation

Security researcher VX Underground discovered a GitHub repository called “kido-kidssafe/myskio-api” that contained something alarming: API credentials visible in the code. According to cybersecurity experts discussing the breach, this repository had been publicly accessible on the internet with “keys to the kingdom visible in the clear.”

The repository showed two contributors, zero issues, and zero stars. It wasn’t a popular or well-maintained repository. Yet it contained the credentials that potentially enabled attackers to access Kido’s data through their third-party platform, Famly.

Why This Matters Beyond Kido

This wasn’t a zero-day exploit. This wasn’t sophisticated malware bypassing multiple security layers. This was what security professionals call “your code was accessible on the internet.”

As one expert noted: “From a parent perspective, the likely attack vector wasn’t sophisticated hacking or a zero-day exploit. It appears to have been ‘your code was on the internet with the keys to the kingdom visible in the clear.’”

The implications are staggering. If a developer was trying to automate something years ago and left credentials in a repository, those credentials might still be active. Many organizations don’t rotate credentials regularly. The code in this repository could have been written by someone who hasn’t worked at the company for years.

The Custom Code Problem

Schools and nurseries rarely have the resources to maintain custom code properly. When parents or former developers write code to automate tasks, it often exists without:

  • Regular security audits

  • Credential rotation

  • Proper access controls

  • Documentation of what exists

One expert in the discussion put it bluntly: “If the developer looks blank when you ask about secrets in the code, then you have a problem. Because that means they don’t understand secure development practices. And your systems might be exposed as Kido’s appeared to be.”

What Schools and Nurseries Should Do Now

Immediate Actions:

  • Audit all GitHub repositories - Use the GitHub search to look for any repositories associated with your organization. Check for both organizational and personal accounts of staff who may have created code.

  • Search for exposed credentials - Look for any custom software, even casual PowerShell scripts, that may exist. Check if they’ve been stored in public repositories.

  • Identify everything custom - Document any custom software you currently use. If two elements or applications seem to be talking to each other and the fact that they can is not a documented feature, you probably have custom code that needs auditing.

  • Consider third-party applications - Examine 3rd party applications you’re paying for. If they seem to be talking to each other in ways that aren’t standard features, investigate whether there’s a paper trail showing invoices or a documented feature. If not, there may be custom code enabling this.

Long-Term Solutions:

  • Implement proper code management - If you must use custom code, ensure it’s properly managed with access controls and regular audits.

  • Rotate all credentials - Most schools don’t know how to check if credentials have been exposed. A wholesale password rotation for the entire organization should be recommended regularly anyway.

  • Audit everyone who’s ever done anything - Consider that former developers or contractors may still have access or may have left credentials exposed somewhere. Conduct a thorough audit of everyone who’s ever had elevated access to your systems.

  • Revoke access where necessary - Audit everyone who’s ever done anything for you and revoke access where necessary. Most schools lack this conversation from an MFA perspective, how do schools track who currently has access?

The Broader Lesson

The Kido breach illustrates a critical truth: you don’t need sophisticated attack vectors when organizations leave their credentials publicly accessible. As governance experts note, it’s a considerable risk that remains unaddressed in many schools.

Update: On October 7, 2025, Metropolitan Police arrested two 17-year-old boys in Bishop’s Stortford, Hertfordshire, on suspicion of computer misuse and blackmail in connection with the Kido breach. The arrests demonstrate that law enforcement takes these crimes seriously, but prevention remains far better than prosecution after the fact.

Custom code written years ago might be the skeleton in your closet. Someone who installed it years ago may have left, and unless the code stored secrets properly in services like Azure Key Vault or AWS Secrets Manager, there may be exposed credentials floating in repositories somewhere.

For schools handling sensitive data about vulnerable children, the Kido breach should serve as a wake-up call. Check your GitHub. Audit your custom code. Rotate your credentials. Because if Kido’s experience teaches us anything, it’s that “security through obscurity” doesn’t work when your code is on the public internet.

Key Takeaways

  • The Kido breach potentially involved publicly accessible code with embedded credentials

  • Custom code created years ago may still pose security risks today

  • Schools need to audit all GitHub repositories and custom software

  • Credential rotation should be standard practice, not an afterthought

  • Former developers may have left security gaps that persist today

Title

Sources

SourceURL
Date AccessedMet Police Arrest Teenagers in Kido Nursery Ransomware Attack
eSecurity Planethttps://www.esecurityplanet.com/threats/met-police-arrest-teenagers-in-kido-nursery-ransomware-attack/
October 2025Teenagers arrested in England over cyberattack on nursery chain Kido
The Recordhttps://therecord.media/kido-nursery-school-chain-hack-arrests-britain
October 2025Nursery hackers leak families’ data on dark web
TechInformedhttps://techinformed.com/hackers-target-nursery-chain-leak-data-dark-web/
October 2025Kido Nursery Cyberattack: Radiant Hackers Threaten to Leak More Children’s Data
Gigadgetshttps://www.gigadgets.com/2025/09/27/kido-nursery-cyberattack-radiant-hackers-childrens-data/
September 2025GitHub Repository Analysis
VX-Underground (via podcast)Referenced in podcast episode
September 2025Cyber Assessment Framework
National Cyber Security Centrehttps://www.ncsc.gov.uk/collection/caf
October 2025This blog post is part of a series discussing the Kido nursery breach and its implications for school cybersecurity. Tomorrow: Understanding the 2025 Safeguarding Guidance and Why Cybersecurity is Now Statutory.

Filed under

  • Kido nursery breach
  • GitHub security vulnerability
  • UK school data breaches
  • safeguarding
  • exposed credentials
  • educational data breach