uniVersa: OpenAI Crawler Grabs Customer Data via Open Server

Published on 28 July 2026

A single misconfigured server, just a few hours without access protection on the open internet – and an automated AI crawler harvests thousands of customer records. That is exactly what happened at uniVersa insurance in early July. Affected data includes names, addresses, policy numbers, tariff information and, for some customers, even bank details (IBAN and BIC). The case is a striking illustration of how quickly a routine IT change can turn into a reportable data breach – entirely without a hacker attack.

What happened?

On 7 July 2026, uniVersa insurance (consisting of uniVersa Lebensversicherung a. G., uniVersa Krankenversicherung a. G. and uniVersa Allgemeine Versicherung AG, based in Nuremberg) carried out an IT changeover. In the process, a server that was actually only intended for automated data exchange with distribution partners was accidentally exposed to the public internet without any access protection due to a configuration error.

During precisely this short window of just a few hours, the web crawler GPTBot operated by the US company OpenAI discovered the freely accessible server and retrieved the data stored on it. A web crawler is an automated program that searches the internet and collects content – GPTBot gathers publicly accessible web content for training AI models.

So this was not a targeted cyberattack, but a classic misconfiguration. The server was simply reachable without a password, without access restriction to specific IP addresses and without any firewall rule. GPTBot did not have to exploit any security vulnerability – the door was simply open.

The incident was discovered through uniVersa's own internal security checks. Public access was immediately blocked, external IT forensic experts (specialists in investigating IT security incidents) were called in, and uniVersa contacted OpenAI with the demand to delete the retrieved data and not use it.

Which data is affected?

According to uniVersa, the server held structured customer master data and contract data. Specifically affected were:

• General personal data: name, address, date of birth, gender, occupation, telephone number, email address
• Contract data: policy number, tariff, sum insured
• Bank details (for some customers): IBAN and BIC
• For motor insurance: vehicle data such as licence plate and manufacturer number
• For property insurance: claim number, cause of loss, amount of loss

A company spokesperson for uniVersa explained to heise online:

"The affected server held general personal data such as names and addresses as well as contract data such as policy numbers and tariff information. For some customers, bank details (IBAN and BIC) are also affected. Not affected were particularly sensitive information such as health, login or credit card data, nor the central administrative and data systems or the customer portal."

That is the good news: health data, login credentials and credit card data were not affected. The central administrative systems and the customer portal also remained untouched. uniVersa has so far not publicly stated the exact number of affected customers – the Bavarian Data Protection Authority (BayLDA) referred to ongoing investigations.

Did OpenAI use the data?

According to its own statement, no. On 25 July 2026, OpenAI confirmed to uniVersa that the data retrieved by the crawler was not used for training AI models. uniVersa informed the trade magazine AssCompact:

"Following our immediate contact, OpenAI has already confirmed that the data retrieved by their automated web crawler was not used for training their AI models, and ensures that this will not happen in the future either."

OpenAI itself stressed that it was not responsible for the security gap at uniVersa – the crawler had merely captured an openly accessible server. From a security perspective, however, a later, indirect use cannot be ruled out with absolute certainty, which is why affected customers should remain vigilant.

How to check whether you are affected

If you are a customer of one of the uniVersa companies, go through the following steps:

1. Check your mail. Since 20 July 2026, uniVersa has been sending written notification letters to affected customers. If you have received such a letter, your data is very likely affected.
2. Ask proactively. Contact uniVersa customer service and submit a request for information under Art. 15 GDPR – this article gives you the right to find out whether and which of your data is affected.
3. Monitor your account transactions. Check bank statements and direct debits for unusual withdrawals – especially if your IBAN/BIC could be affected.
4. Be vigilant about contact attempts. Watch out for unusual emails (phishing), calls (vishing) or letters that refer to your insurance policies.

What you as an affected person should do now

The President of the Bavarian Data Protection Authority, Michael Will, gives affected persons a clear recommendation:

"Potentially affected persons should, among other things, change passwords, monitor account and credit card transactions and be particularly cautious with unusual emails, calls or letters. In case of suspected fraud, the authority recommends filing a report."

Specifically:

1. Keep an eye on your bank statements over the coming months.
2. Be especially sceptical of messages that refer to your insurance and ask you to disclose further data or make payments. Attackers could use policy numbers and tariff data to construct very credible fraud scenarios.
3. If in doubt, inform your bank about the potential risk in connection with your IBAN.
4. In the event of concrete suspicion of misuse: file a report with the police.

The technical background – explained clearly

The core of the problem was a lack of access protection. Servers that exchange data with partners should never be directly reachable from the open internet. Usually, they are protected via a VPN (encrypted access, only for authorised users), via IP whitelisting (access only from previously defined addresses) or via a separate, isolated network zone (DMZ).

In the uniVersa case, these protective mechanisms were missing for several hours. GPTBot does in principle respect the robots.txt file – a text file with which website operators tell crawlers which areas they should not search – but here no such block existed. It is important to understand: robots.txt is a polite "no entry" sign, not a lock. The actual protection must take place at the network level.

Incidentally, no CVE number (a standardised identifier for software vulnerabilities) was assigned for this incident – simply because there was no software gap, but a human configuration error. According to the renowned Verizon Data Breach Investigations Report, such misconfigurations of servers and cloud storage are regularly among the top 5 causes of data breaches.

The GDPR classification: liability even without a hacker

The case is a textbook example in matters of the General Data Protection Regulation. Lawyer Nursel Orhan gets straight to the crucial point:

"A data leak regularly constitutes a breach of duty by the controller. Controllers must protect personal data through appropriate technical and organisational measures (Art. 32 GDPR). Fault or a targeted criminal attack is not relevant for a claim under Art. 82 GDPR: even an accidental disclosure can give rise to claims."

Specifically, several GDPR obligations apply here:

• Art. 33 – Notification obligation: A data breach must be reported to the supervisory authority within 72 hours where feasible. uniVersa has reported it, and the BayLDA confirmed receipt.
• Art. 34 – Notification of data subjects: In case of high risk (here: bank and contract data), the affected persons must be informed directly – this has been happening since 20 July 2026.
• Art. 32 – Technical and organisational measures: The missing server protection violates the obligation to take appropriate protective measures.
• Art. 82 – Compensation: Affected persons can claim non-material damages. In its ruling of 18 November 2024 (case no. VI ZR 10/24), the German Federal Court of Justice decided that even the mere loss of control over one's own data can constitute compensable non-material damage.

Interestingly, the European Data Protection Board (EDPB) published its "Guidelines 03/2026 on web scraping in the context of generative AI" on exactly the day of the incident, 7 July 2026 – the first binding requirements for operators of AI crawlers. With this in mind, BayLDA President Will stressed:

"Before retrieving data via web crawling, controllers must, among other things, implement technical and organisational filtering mechanisms to exclude unnecessary data categories from the outset and not to include structurally sensitive sources in the collection at all."

What SMEs and website operators must learn from this

This case concerns not only large insurance groups. Anyone who processes personal data is subject to the same obligations – and any misconfiguration can be reportable. You should implement these steps:

1. Establish change management: For every IT changeover or migration, carry out a mandatory security check that explicitly verifies the access rights and reachability of all servers – before and after the change.
2. Network segmentation: Servers for data exchange with partners must never be directly reachable from the internet. Secure them via VPN, IP whitelisting or a DMZ.
3. Enforce authentication: For every server holding personal data, strong authentication (API keys, OAuth 2.0, certificates) and role-based access controls (RBAC) are standard.
4. Block AI crawlers: Maintain an up-to-date robots.txt and block known AI crawlers (e.g. "User-agent: GPTBot / Disallow: /"). Keep in mind: this only protects public web servers, not internal systems.
5. Set up monitoring: Monitor unusual access volumes and unknown user agents in real time (e.g. via a web application firewall or a SIEM system that centrally evaluates security events).
6. Data protection impact assessment (DPIA): Carry out a DPIA under Art. 35 GDPR before IT changeovers involving personal data.
7. Incident response plan: Keep a documented response plan ready that takes the 72-hour notification deadline into account and clearly regulates responsibilities.
8. Regular scans: Check your own IP ranges with tools such as Shodan, Censys or nmap for accidentally exposed endpoints – especially after migrations.

The figures show the trend

Data breaches are on the rise. In 2025, 10,259 data breaches were reported to the German data protection authorities – a marked increase from 8,623 in 2024. Bavaria, home of uniVersa, recorded 1,500 reported breaches, the second-highest figure of all federal states.

That the GDPR has teeth is shown by the fine figures: in 2025, 249 fines totalling around €46.9 million were imposed in Germany. The highest single fine, €45 million, hit Vodafone – for inadequate authentication processes. And that late notifications are also sanctioned was already demonstrated in 2020 by a fine of €450,000 against Twitter/X. The theoretical scope is considerable: fines can be up to €20 million or 4% of global annual turnover.

Conclusion

The uniVersa incident is not a spectacular hacker attack, but the result of a human error during an IT changeover – and that is precisely what makes it so instructive. It required no criminal energy, just an open door and an automated crawler that happened to pass by.

For affected uniVersa customers, the message is: check your mail, monitor your account transactions and remain vigilant about suspicious contact attempts. No active misuse is known so far, and OpenAI has assured that the data will not be used – nevertheless, healthy scepticism is warranted.

For companies and website operators, the message is unmistakable: security is not a one-off project, but must be considered with every change. A clean change management process, consistent network segmentation and regular external scans would have prevented this incident. Anyone who processes personal data is liable – even without intent, even without an attack. The BayLDA investigation is not yet concluded; the final assessment is therefore still pending.