A UK company that pays patients to take part in health surveys left an Elasticsearch database open to anyone on the internet, exposing names, contact details and diagnoses going back to 2015. Researchers at UpGuard say more than a third of the affected records relate to people living in the UK.
What happened
Liberating Research is a UK medical market research business. It recruits patients, carers and clinicians to answer paid questionnaires about their conditions or specialties, and passes part of each payment to a charity the participant picks. According to a report UpGuard published on 12 October 2026, the company ran an Elasticsearch server that anyone could query without authentication.
UpGuard says its researchers found the server on 17 August (US Pacific time) and told the company the same day, though by then European offices had closed. By the next morning the database had been locked down. DataBreaches.net, which UpGuard’s Greg Pollock contacted on 31 August, held its own story back by agreement and published on 13 October.
The firm’s engagement since then appears limited. UpGuard says two weeks passed without a reply, followed by follow-up emails on 1 and 4 September, after which Liberating Research came back with clarifying questions about whether the data was still private. UpGuard says it answered those on 11 September. DataBreaches.net says it wrote to the company through its website on 8 October, asking whether individuals or regulators had been told, and received nothing back. UpGuard says it does not know whether anyone affected was ever notified. Liberating Research has made no public statement that I could find, and its privacy notice carries a “last updated” date of 2 October 2026.
The technical picture
This was not a break-in. There was no malware, no stolen password and no exploited flaw: the data store was simply reachable from the public internet with no login in front of it. UpGuard describes several indices on the server, most of them rotating logs and metadata, plus one called “lr_user” that held 662,365 objects.
UpGuard’s headline figures are personal details for 109,700 unique people, with health information (diagnoses and medications) attached for 73,944 of them. Records start on 21 September 2015, and UpGuard says new ones were still arriving when it found the server. The researchers counted 160,778 separate conditions. They name HIV and AIDS, drug and alcohol misuse, sickle cell disease, and bipolar and borderline personality disorders among the most sensitive.
The figures need a little care. UpGuard’s breakdown by account type comes to 93,033 accounts: 73,969 patients or carers, 16,664 contacts linked to charities, 1,765 healthcare professionals, 533 charity accounts and 102 incomplete sign-ups. That is well below the 109,700 unique people it cites elsewhere, and the report does not explain the gap. UpGuard also says carer accounts list 16,667 people who receive care but have no account of their own. Names are missing for these people, but dates of birth, gender, conditions and medications are included.
Every record in UpGuard’s table included an email address, a location and a phone number, and 99 per cent included full name and date of birth. UpGuard says the numeric codes for gender and ethnicity were easy to decode in practice.
Why it matters for UK organisations
According to UpGuard’s country breakdown, England accounts for 27,209 records, Scotland 4,322, Wales 1,330 and Northern Ireland 662. That is about 33,500 records, or roughly 36 per cent of the total. Health data is special category data under UK GDPR. Where an incident is likely to put people at risk, the controller has 72 hours to report it to the Information Commissioner’s Office, and where the risk to individuals is high it must also tell those people without undue delay. Whether that happened here has not been made public, and I am not going to guess.
The wider lesson is about where sensitive data ends up. Most UK health data protection effort goes on the NHS, private providers, insurers and their direct suppliers. UpGuard points out that this firm sits outside all of them. It gathers self-reported diagnoses through a commercial survey channel, yet the harm to someone whose HIV status or mental health history is exposed is just as great.
There is also an obvious fraud risk. A list linking named people to specific conditions, with phone numbers and email addresses, is exactly what you would want for convincing phishing, fake “trial recruitment” approaches or extortion. The 2020 Vastaamo breach in Finland, which UpGuard cites, showed how stolen therapy records can be turned against each patient individually. No evidence has been published that anyone other than UpGuard accessed this server, but nobody outside the company can say how long it was open before 17 August.
Expert view
Open Elasticsearch, MongoDB and similar data stores have been one of the most common findings in my work for the best part of a decade. The cause is almost always a development or analytics cluster bound to a public interface with security features left off.
What bothers me more than the misconfiguration is the scale and age of the dataset. Eleven years of records, still being added to, in a store that was readable from the internet suggests nobody had mapped where participant data lived or asked whether it all needed keeping. If records from 2015 had been deleted or properly pseudonymised, the exposure would have been far smaller.
The way the firm handled things afterwards matters too. Fixing the server overnight was the right technical response. But once a researcher has found that kind of data, the questions that count are whether logs show anyone else got to it, and whether the people affected have been told. Staying silent with researchers and journalists does not answer either.
What to do now
- Find your exposed data stores. Scan your own external IP ranges and cloud accounts for Elasticsearch, OpenSearch, MongoDB, Redis and similar services listening on the internet. This maps to the Cyber Essentials firewall and secure configuration controls.
- Turn on authentication and TLS everywhere. Make sure security features are enabled on every search and database cluster, bind services to private interfaces, and restrict access to known hosts or a VPN.
- Check access logs now. If a store has ever been public, keep and review its logs for unfamiliar IP addresses or bulk queries before deciding whether to report.
- Map special category data. Record where health, ethnicity and similar fields are held, including survey platforms, CRMs and research panels, and who owns each system.
- Enforce retention. Delete or pseudonymise participant records that no longer serve their purpose, especially in operational search indices.
- Rehearse the 72-hour decision. Make sure your incident plan covers researcher disclosures, including who assesses risk, who talks to the ICO and how affected individuals will be contacted.
Bottom line
No hacker was needed to expose diagnoses linked to tens of thousands of named people, many of them in the UK. The fix took one night. The open questions are why eleven years of sensitive data sat in a public index, and whether the people in it have been told.
Sources
- UpGuard: Clinical Oversight: Medical Survey Firm Exposes Diagnoses of Participants
- DataBreaches.net: UK: Commercial market research and data-gathering firm in the medical space leaked health data
- Mallory: Liberating Research Exposed Sensitive Medical Data on Nearly 100,000 People
- Liberating Research: Privacy Notice
