Threat intel

The University of Copenhagen (UCPH) says attackers got into one of its test environments and reached personal data on about 525,000 people. The intrusion was detected on Tuesday, October 20, 2026, and disclosed on Friday, October 23. The data includes full names, CPR numbers (the Danish personal ID number), work and private phone numbers and private email addresses. On October 25 the university added that the access card PIN codes of about 20,000 staff and students were also compromised.

Anyone who has studied or worked at UCPH, or been registered with it in another role, should assume they may be in the set until the university's letter says otherwise. For everyone else the lesson is about where real data lives: the system that leaked was built for testing, yet it held a copy of production records on current and former members of the university. The attacker has not been identified and no group has claimed the attack.

How it works

Development and test environments are where new versions of an application are built and checked before release. To test realistically, teams often load them with a copy of the production database, because synthetic data takes effort to build and real data finds real bugs. The copy then lives on with weaker controls than the original: broader developer access, test accounts with simple passwords, fewer patches, less logging, and sometimes a direct route from the internet so outside contractors can reach it.

UCPH's own notice adds a detail that turns a bad leak into a worse one. It says the CPR numbers in the database were encrypted, but that the information needed to decrypt them was also compromised, so the university considers there to be a significant risk that the numbers can be read. Encryption at rest only protects data when the key is held somewhere the attacker cannot reach, such as a key management service with its own access policy. A key stored in a config file, environment variable or table in the same environment protects nothing once that environment is breached. This detail comes from the university's notice; the news coverage so far has not reported it.

The PIN codes raise a similar question. UCPH has not said how they were stored. Short numeric PINs are hard to protect even when hashed: a four-digit PIN has only 10,000 possible values, and an attacker with the hashes can try every one offline in seconds. The university treated them as exposed, restricted physical access to selected critical locations on campus on the evening of October 23, and reopened them once new PINs were issued.

What attackers are doing

There is no public claim of responsibility and no published technical account of how the attacker reached the test environment. UCPH says it brought the attack under control after detection, blocked access to the affected systems and found no sign that the systems behind day-to-day operations were reached.

On Monday, October 26, the university reported a new attack and ran what it called "a preventive and controlled shutdown" of several administrative systems, including the WorkZone document management system and the Nimbus budgeting tool. A day later it corrected itself: the activity was linked to the original breach, not a second attack, but the shutdown stayed in place. Some systems were still disrupted days later. UCPH has reported the breach to the Danish Data Protection Agency (Datatilsynet).

One account conflicts with the rest. TechRadar's report describes access to an "Advancement" database holding alumni and donor records. The university's own statements, BleepingComputer, Infosecurity Magazine and Help Net Security all describe a test environment, so treat the TechRadar version as unconfirmed.

What affected people should do

UCPH started sending letters through Digital Post, Denmark's official digital mailbox, on October 27, followed by direct emails on October 28 to people it has an email address for. The university's advice, with one addition:

• Be suspicious of any call, text or email that asks for a password, MitID details or other confidential information, even when the sender already knows your name, CPR number and phone number. That combination is exactly what the attacker now holds.
• If you used your UCPH access card PIN anywhere else, such as a phone, a bank card or a door code, change it there now.
• Consider a credit alert on your CPR number. We described how that works in our post on the DTU breach, which hit the same kind of data a month earlier.

For organisations in Denmark, this breach adds to the stock of CPR numbers already in criminal hands after the CPR register lookups in September. Any helpdesk or phone flow that still accepts a CPR number as proof of identity needs to stop doing so.

What to check in your own test environments

1. Build a list of every non-production environment, including old staging servers, contractor sandboxes, cloud accounts used for proof-of-concept work and database snapshots shared for debugging. Then scan their databases and file stores for real personal data. For Danish national IDs, a pattern of six digits for a valid date, an optional hyphen and four more digits finds CPR numbers in exports and columns that are not labelled as such; most data discovery tools ship equivalents for other countries.
2. Where real data is found, replace it. Mask or tokenise identifiers before the copy leaves production, generate synthetic records for load tests, and keep a short, documented exception list for the few cases that truly need live data, each with an owner and an end date. GDPR Article 25, data protection by design and by default, already expects this.
3. Move encryption keys out of the environment they protect. Keys belong in a key management service or hardware security module with its own access policy, and test environments should use test keys that cannot decrypt production data.
4. Check how each environment can be reached. Look for public IP addresses, open database ports and admin panels in your external scans, remove shared test accounts and default passwords, and require the same single sign-on and multi-factor authentication (a second check beyond the password) as production.
5. Log and alert as you would in production: sign-ins, bulk queries and large exports. An environment no one watches is where an intruder can work for days.

The wider lesson

Data protection reviews, access reviews and monitoring are usually scoped to production. A test environment loaded with a production copy holds the same records, so it needs the same scope, or it needs to stop holding them. Add every non-production environment to the asset register that drives those reviews, with a named owner.

Our attack surface management work finds forgotten test and staging systems that can be reached from the internet, and our security operations team extends sign-in and export alerting to the environments that usually go unwatched. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: University of Copenhagen breach notice (English), University of Copenhagen breach notice (Danish), University of Copenhagen operational updates, BleepingComputer, Infosecurity Magazine, Help Net Security, ITdaily, TV 2 Kosmopol, TechRadar.