What Do My Grandma and Denmark Have in Common? Apparently, a Password.

An alleged '123456' password, 8.8 million people's records, and 14 million database queries that reportedly went unnoticed until someone checked the bill.

My grandma and Denmark's national identity infrastructure apparently have something in common.

A password that consists of six consecutive numbers.

Except my grandma is protecting her Facebook account, and Denmark was supposed to be protecting the personal information of millions of people.

On October 15, a post by Kalshi went viral claiming that a hacker had accessed Denmark's national ID database using the password 123456, exposing information belonging to 8.8 million people. I initially assumed the password was an exaggeration. Surely, in 2026, nobody with access to a national identity database is using the digital equivalent of leaving their house key under the doormat.

Well, apparently, someone might have been.

The password claim comes from the alleged attacker, who reportedly told Danish newspaper Politiken that several accounts belonging to a private company with access to Denmark's Central Register of Persons (CPR) used 123456. One was allegedly an administrator account. Danish authorities haven't independently confirmed that detail, so we're still dealing with an attacker's account of how they got in.

The unauthorized access itself, however, is real.And the password isn't even the most embarrassing allegation in the reporting.

Apparently, the incident was discovered because someone noticed an unusually large invoice.

8.8 million records and a very expensive month

On October 5, 2026, Danish authorities disclosed unauthorized access to the country's Central Register of Persons, commonly known as the CPR.

For anyone unfamiliar with Denmark's system, the CPR is essentially the backbone of the country's population registration infrastructure. It contains personal identification numbers and associated information used across public administration and essential services.

The register includes roughly 11 million historical and current records, including those of deceased individuals and people who have emigrated.

According to the official disclosure, an unauthorized party used access granted to a private Danish company to retrieve information relating to approximately 8.8 million registered individuals.

The company was subsequently identified in reporting as Pays ApS.

The alleged attacker didn't necessarily break directly into a government server. They reportedly exploited credentials associated with an organization that already had legitimate access to the registry.

Between September 10 and September 20, approximately 14 million automated searches were reportedly performed against the system.

Fourteen million.

Over ten days.

That's an average of 1.4 million queries per day, or roughly 16 every second if distributed evenly. The incident was reportedly discovered on October 2, after an employee noticed an unusually high invoice associated with the company's usage.

I'm trying to imagine the conversation.

"Hey, why is this month's bill so high?"

"Someone's been querying the national population database millions of times."

"Oh."

Of all the detection mechanisms one might expect to catch large-scale access to a national identity registry, accounting wasn't particularly high on my list.

To be fair, the public reporting doesn't establish whether internal security systems generated alerts that were missed, ignored, or never escalated. We don't have enough information to reconstruct the entire detection failure.

But the reported discovery through a billing anomaly is remarkable.

The attacker didn't need to break the system. They needed the system to trust them.

A lot of security conversations still revolve around the moment an attacker gains access. Was there a zero-day? A phishing campaign? Credential stuffing? An unpatched vulnerability?

In this case, the reported entry point was much less exotic.

Accounts belonging to a company that already had permission to access the CPR system. Once an attacker possesses valid credentials, the security problem changes. They're no longer necessarily trying to get past authentication. They're operating within an access pathway the system already recognizes.

That doesn't automatically make their actions legitimate, but systems aren't always particularly good at distinguishing between an authorized user doing their job and an attacker using that user's credentials to extract information.

Especially when third-party integrations are involved.

An organization may legitimately need to verify customer information against a national registry. That doesn't mean its accounts should be able to perform unlimited searches or retrieve records unrelated to the purpose of that access.

This is where authorization design, least-privilege access, and behavioral monitoring become critical.

An authenticated request can still be malicious.

And if the system treats every request from a trusted account as routine, an attacker can accomplish quite a lot without exploiting another technical vulnerability.

Fourteen million searches is a fairly enthusiastic amount of verification

Fourteen million searches in ten days. Even without knowing the precise distribution of requests, that's an extraordinary amount of activity to investigate.

Were there per-account rate limits? Did the system maintain behavioral baselines for third-party integrations? Could accounts retrieve information beyond their legitimate business requirements? Were automated enumeration patterns being monitored? And what would have happened if the invoice hadn't looked unusual?

These are the questions I'd want answered in a technical review.

Rate limiting wouldn't necessarily have prevented the entire incident. An attacker could distribute requests across accounts or stretch them over longer periods. But monitoring request frequency, unusual access patterns, query distribution, and deviations from established usage could have provided opportunities for earlier detection.

There's also the question of account privilege.

If the alleged administrator credentials were involved, what permissions did those accounts actually possess? Were they necessary for routine operations? Were privileged accounts subject to stronger authentication requirements?

The password allegation is almost comically bad, but weak credentials are only one possible failure in a much larger access-control problem.

A system designed to handle sensitive personal information should assume that credentials can eventually be compromised.

The security architecture has to account for what happens next.

Unfortunately, you can't reset your date of birth

There's another reason this kind of breach deserves attention beyond the initial headlines. Identity information has a considerably longer shelf life than most compromised credentials.

If my password leaks, I can change it.If my access token is stolen, I can revoke it.

If my name, address, date of birth, and national identification number are exposed, the recovery options are significantly less straightforward.

You can't exactly open your account settings and generate a new birthday. The concern isn't necessarily that someone can immediately impersonate every affected individual. We don't know the full extent of the information actually obtained or how it might be used.

But personal information can support convincing phishing, identity fraud, and social engineering. An attacker with accurate biographical details may find it easier to convince a victim that a fraudulent message is legitimate. And organizations that rely on personal details to verify identity may discover that those details are no longer particularly useful as secrets.

Following the incident, the Danish Immigration Service introduced additional identity verification procedures for telephone inquiries. It's a reminder that the consequences of a breach don't necessarily stay within the system that was compromised.

A database can be secured after an incident. The information already exposed may continue circulating.

We're building AI security systems while apparently still negotiating with '123456'

There's something absurd about the timing of all this.

The cybersecurity industry is currently fascinated by autonomous attack agents, AI-powered vulnerability discovery, advanced threat detection, and the possibility of increasingly sophisticated offensive operations.

We're discussing whether AI can discover vulnerabilities faster than humans can patch them. Meanwhile, an alleged six-digit password has become part of the story of one of Denmark's largest personal-data incidents.

I'm not suggesting we abandon advanced security research and return to lecturing everyone about password complexity.

The opposite, actually.

The most concerning part of this incident isn't that someone may have used a terrible password. It's that compromising an existing access pathway reportedly enabled millions of database searches.

Strong authentication would help prevent unauthorized use of credentials. But organizations also need controls that limit what authenticated identities can do.

This is particularly relevant to third-party integrations, where an organization may have limited visibility into how its partners manage credentials and internal access.

It's also why security testing needs to examine business logic, authorization boundaries, and the potential for automated data extraction.

A conventional vulnerability scan might find no critical software flaws in an application.

That doesn't tell us whether a legitimate account can enumerate thousands of records, retrieve data outside its intended scope, or automate requests at a scale nobody anticipated.

These are the kinds of behaviors that need to be tested deliberately. Because attackers don't care whether the weakness has a CVE assigned to it. If the system lets them retrieve the data, they'll retrieve the data.

The invoice deserves its own incident report

There's still plenty we don't know about the Denmark incident.

The 123456 allegation hasn't been independently verified by authorities. The exact authentication configuration, monitoring systems, and permissions associated with the compromised accounts haven't been fully established publicly.

And the investigation may eventually reveal controls or circumstances that weren't apparent in the initial reporting.

But the broader security problem is already recognizable.

A trusted third-party access pathway was abused. An enormous volume of personal-data queries reportedly followed. The incident was discovered after the suspicious activity had ended.

The password makes for a ridiculous headline, and deservedly so. But I'd be far more interested in the answers to two questions.

Why could the compromised access be used to retrieve so much information? And why wasn't the reported activity interrupted sooner?

My grandma might use 123456 because remembering twelve characters, a symbol, and the name of her first pet is an unreasonable demand before she's had her morning tea.

A company with access to a national identity registry has considerably fewer excuses.

And if the reporting about the invoice is accurate, Denmark owes someone in accounting a very awkward thank-you.