Many many years ago, I did some work for the NHS. As part of that, I was given access to certain GitHub organisations so that I could contribute to various projects. Once I left that job my access was revoked.
Mostly.
A few weeks ago, I received this email from GitHub.
On the surface, this is a sensible email. They want all their members to only have strong 2FA and I still had SMS configured as a fallback method. Except, of course, I should not be a member. I should have been kicked out when I handed back my laptop and lanyard. There was still a bit of pandemic pandemonium about - but surely in the last few years someone should have audited the organisation's membership?
The JML process is critical to cybersecurity. There's no point having fancy controls if you don't revoke the permissions of people who are no longer entitled to access. On a fully integrated system this is (usually) easy - untick a box on Active Directory or whatever and *poof* the user is banned.
But with external systems the problem is harder. You now need to keep track of external usernames, synchronise them with internal names, periodically check them for updates, integrate with an API, and - in some cases - take manual action. It's clear that this particular bit of the NHS had slipped up. Looking through the private list of collaborators, there were many old accounts.
I was able to see all private collaborators:
I could see all private repositories:
I even had access to create new repositories - including special ones:
To be abundantly clear, there was no medical data on GitHub. There was no patient data available for me to view. Absolutely nothing medically sensitive was stored there. This isn't a GDPR or medical privacy issue. If I had made any changes to the code stored on there, it would never have made it to production. There were no API keys or sensitive data or passwords for me to exfiltrate. The NHS BSA is a business unit - not a medical unit.
Nevertheless, it is important that all parts of a large organisation are able to quickly and competently remove users once they have left.
Timeline
- 2025-10-17
- Received GitHub email.
- Visited https://www.nhs.uk/.well-known/security.txt to get details of how to raise security issues.
- Raised the issue on HackerOne
- 2025-10-21
- After triage, the issue was assigned directly to the BSA.
- 2025-10-31
- I was removed from the organisation.
-
- Requested permission to publish this post. No objection received.
- 2025-12-02
- Published
One thought on “Responsible Disclosure: Joiners, Movers, and Leavers in NHS BSA”
Adina Bogert-O'Brien
Yes yes and yes. And this stuff is so much more complicated than people assume! There are so many external systems that make this much harder than it should be, even if you have SSO turned on. In your case, if they did, users aren't forced to use it (and users outside the org get access.)
The fact that you were able to use your personal account illustrates the setup was likely too permissive - they need a special audit feature for any non internal accounts. Which they missed out on.
https://media.ccc.de/v/38c3-omg-wtf-sso-a-beginner-s-guide-to-sso-mis-configuration Is my talk about these kinds of issues, which you probably remember since you were the amazing herald for the stage where I gave it at emfcamp.
Audits are boring. People just don't do them unless the tech forces them.
More comments on Mastodon.