Weak passwords and delayed detection in Danish CPR register breach

Hackers exploited weak credentials at a small Danish IT company to access the national Civil Registration System (CPR) for over three weeks in September 2026. The breach exposed personal data linked to approximately 8.8 million citizens, highlighting critical failures in basic access control and monitoring.

What happened

The intrusion targeted Pays ApS, a two-employee IT company based in Odense that held legitimate access rights to query the CPR database. According to reports from Politiken and TV 2, attackers gained entry using the password "123456" on at least three accounts, including an administrator account. Jens Myrup Pedersen, a professor at Aarhus University, described this security posture as "hopeless," noting that such common passwords are among the first guesses in any automated attack.

Once inside, the attacker deployed custom scripts to extract data and store it externally. The unauthorized access began on 10 September and continued until 2 October, lasting 21 days and 17 hours. Preliminary investigations suggest the active data exfiltration may have ceased around 20 September, but the connection remained open for another ten days. The breach was only discovered when authorities noticed an anomalously large invoice for search queries, totaling around 14 million lookups, which far exceeded the company’s normal operational volume.

Key details

• Compromised entity: Pays ApS, a small IT firm with two employees, confirmed it was the vector for the attack.
• Weak credentials: At least three accounts, including an admin account, used the password "123456".
• Scale of exposure: Data linked to roughly 8.8 million CPR numbers was accessed.
• Duration: The attacker had access for 21 days and 17 hours, from 10 September to 2 October 2026.
• Detection method: The breach was identified via billing anomalies rather than security alerts, with 14 million searches flagged.
• Attacker claim: An anonymous hacker stated they used a leaked password from a former employee and had no plans to publish the data.

Background

The CPR register is Denmark’s central civil registration database, containing essential personal information such as names, addresses, and identification numbers for residents. Private companies can apply for access to this system if they demonstrate a legitimate need, such as verifying customer addresses or managing member lists. This access is typically governed by strict usage policies and auditing mechanisms to prevent abuse.

In this case, the security failure was not a complex technical exploit but a fundamental lapse in identity management. Using easily guessable passwords like "123456" bypasses the need for sophisticated hacking tools. Furthermore, the delay in detection underscores a common issue in third-party access models: without real-time monitoring of query volumes or behavioral anomalies, breaches can persist undetected until financial or administrative discrepancies arise.

Why it matters

For teams managing self-hosted software or integrating with external APIs, this incident serves as a stark reminder that human factors often outweigh technical defenses. Even if your infrastructure is hardened against network attacks, weak credentials on privileged accounts create an open door. Small teams, like the two-person company involved here, may lack dedicated security staff, making them vulnerable to simple oversights that have massive downstream consequences.

The reliance on billing audits for detection is particularly concerning for DevOps and IT leads. Waiting for an unusual invoice means the damage is already done. In a self-hosted environment, you must assume that standard logging is insufficient for security monitoring. You need proactive alerts for abnormal behavior, such as sudden spikes in API calls or login attempts from unusual locations, to reduce the window of exposure.

Additionally, the use of third-party vendors with access to sensitive data expands your attack surface. If you grant external partners or internal services access to critical databases, you are responsible for ensuring they adhere to robust security standards. A breach in a small vendor can compromise your entire ecosystem, leading to regulatory scrutiny and loss of trust.

What you can do

• Enforce strong password policies: Mandate complex passwords and use a password manager to avoid reuse. Never allow default or common passwords like "123456".
• Implement Multi-Factor Authentication (MFA): Require MFA for all administrative accounts and any service with access to sensitive data.
• Monitor API usage actively: Set up alerts for unusual spikes in query volumes or data exports, rather than relying on monthly billing reviews.
• Audit third-party access: Regularly review who has access to your systems and revoke permissions for former employees or unused accounts immediately.
• Rotate credentials regularly: Change passwords and API keys periodically, especially after staff changes or when a vendor’s security posture is questioned.
• Conduct penetration testing: Simulate attacks to identify weak points in your authentication and monitoring setup before real attackers do.