Nokia Data Breach: Exposed etcd Server Leaked Infrastructure Credentials

What Happened: An Unsecured etcd Server Exposed Nokia's Internal Credentials

On December 13th, 2018, the HackenProof team identified an unsecured etcd server during a routine Shodan security audit. Etcd is a distributed key-value store used to hold configuration data and coordinate state across clustered infrastructure—commonly deployed alongside Kubernetes—and this particular instance was reachable from the open internet with no authentication required.

The unauthenticated log server sitting on the same IP address was part of the same exposure—a Nokia Cluster Manager (NCM) installer interface, confirming exactly which infrastructure the leaked credentials belonged to.

What made this exposure serious wasn't a pile of customer records—it was a set of live infrastructure credentials sitting in plaintext, retrievable by anyone who found the server. The exposed data included administrator and user passwords for Heketi, Redis credentials, Weave authentication details, Kubernetes secret encryption keys, Gluster private keys, SSH and RSA private keys, cluster credentials, and AWS S3 secret access keys—a separate log server running on the same IP address operated with no authentication requirements at all.

Any one of these credential types, in the wrong hands, could grant an attacker a foothold into internal Nokia systems. Together, they represented the kind of exposure that skips past "data breach" and goes straight to "here are the keys to the building.”

What Data Was Exposed

The etcd instance and the unauthenticated log server on the same IP together exposed:

• Heketi administrator and user passwords
• Redis credentials
• Weave authentication details
• Kubernetes secret encryption keys
• Gluster private keys
• SSH and RSA private keys
• Cluster credentials
• AWS S3 secret access keys

Timeline: From Discovery to Shutdown

• December 13, 2018—HackenProof discovers the unsecured etcd server during a Shodan-based security audit and begins responsible disclosure outreach to Nokia.
• Days following—The initial report goes without timely acknowledgment. Bob Diachenko, Director of Cyber Risk Research at Hacken, pursues alternative contact channels to escalate the report directly.
• December 17, 2018—Nokia secures the exposed system, four days after the initial discovery.

As with several other cases in this series, the technical discovery itself took a single automated scan. Getting a large organization to act on it took days—and an escalation outside the normal reporting channel—even with working credentials sitting exposed the entire time.

Nokia's Response—and a Contradiction

After securing the server, Nokia characterized it as a system "created some time ago by one of our developers for testing purposes" and stated it contained no sensitive information. The company said it would conduct awareness training for its R&D staff going forward.

That characterization sat uneasily with what was actually found. Bob Diachenko, who discovered and reported the exposure, was on record as skeptical of the "just a test server" framing, noting that the range and nature of the exposed credentials—SSH keys, cluster secrets, cloud storage keys—didn't read like throwaway test data. As HackenProof put it at the time, "we cannot be 100% sure this was testing data," and the volume and sensitivity of what was exposed argued against taking Nokia's explanation at face value. It's a familiar pattern: a company minimizes an exposure as soon as it's fixed, while the technical details of what was actually found suggest otherwise. (See Hackread's coverage of the incident for Diachenko's fuller quote.)

This is the channel HackenProof used to report the exposure in the first place—and it's worth noting for context later in this piece, since Nokia's disclosure process has changed relatively little in the years since.

Why Exposed etcd Servers Are Dangerous

Etcd is not designed to be internet-facing, and its own documentation says so directly: authentication, role-based access control, and TLS encryption are all disabled by default, specifically to reduce friction for people getting started with it. That means an operator who spins up an etcd cluster without deliberately hardening it is exposed by design, not by accident of configuration. Once that's the case, etcd's own docs state plainly that all data in the cluster becomes accessible to any client with network access—exactly the failure mode that played out here.

Because etcd is frequently used to coordinate Kubernetes clusters and store cluster secrets, an exposed instance isn't just a leak of one system's password—it can be a map to an organization's broader infrastructure, including the credentials needed to move laterally into other systems.

Is This Still Happening? etcd Exposure in 2026

Unfortunately, yes—and at almost the same scale. Security research firm Rapid7 has tracked internet-exposed etcd nodes as part of its ongoing internet-scanning research, and its most recent published count sits at roughly 2,560 exposed instances globally, with concentrations in China, the United States, South Africa, and Germany, spread across major cloud providers including AWS, Google Cloud, and Alibaba. That's essentially the same order of magnitude as the ~2,519 exposed instances HackenProof identified back in December 2018—the misconfiguration hasn't gone away; it's just kept finding new servers to live on. Rapid7's own assessment is blunt: there is no legitimate reason for a Kubernetes deployment's etcd instance to be reachable from the public internet.

More recent offensive-security writeups back this up—a 2024 case study documented researchers pulling SSH credentials, database configuration, and even wildcard TLS certificates directly out of exposed etcd key stores found via simple Shodan searches, using essentially the same technique HackenProof used against Nokia in 2018.

Current guidance from etcd's own documentation for anyone running a cluster: enable TLS for both client and peer traffic using CA-signed certificates, turn on client certificate authentication, layer role-based access control on top of transport security, bind listening ports explicitly rather than to all interfaces, and restrict allowed cipher suites. None of this is enabled out of the box—it's each operator's responsibility to turn it on. See etcd's official security model documentation for the full current guidance.

Has Nokia Had Other Security Incidents Since 2018?

Two more recent incidents are worth noting, both involving third parties rather than a direct compromise of Nokia's own core infrastructure:

In November 2024, a threat actor going by "IntelBroker" claimed to have obtained SSH keys, source code, RSA keys, and various hardcoded credentials, reportedly via a poorly secured SonarQube server belonging to a third-party vendor. Nokia investigated and stated it found no evidence that its own systems or data were impacted, characterizing the leaked material as source code for a third-party application used within a single client's network rather than Nokia's own codebase.

In July 2025, a threat actor calling themselves "Tsar0Byte" claimed on a dark-web forum to have breached Nokia's internal network through a compromised third-party contractor, alleging exposure of data on roughly 94,500 employees—names, corporate emails, phone numbers, job titles, and internal documents. Nokia's preliminary findings reportedly found no evidence of direct compromise to its primary systems, with the investigation continuing.

Neither incident has been confirmed as a direct breach of Nokia's own infrastructure in the way the 2018 etcd exposure was—but the pattern of relying on third-party vendors and contractors as an attack surface is one worth watching regardless of which company's name ends up in the headline.

Does Nokia Run a Bug Bounty Program?

Not a paid one. Nokia currently operates a Coordinated Vulnerability Disclosure (CVD) program rather than a bug bounty: researchers can report findings to a dedicated security mailbox, with an optional PGP key available for sensitive submissions, and Nokia states outright that it does not currently offer monetary rewards. Researchers who report confirmed, in-scope issues can be credited in a public "Hall of Fame" and in Nokia's security advisories, with their consent—recognition, but not payment.

That's a meaningfully different setup from a managed bug bounty program, where researchers have both a clear incentive and a pre-approved legal channel to report exactly the kind of exposure found here—rather than, as happened in 2018, needing to escalate through personal contacts after an initial report went unanswered. HackenProof's own bug bounty platform exists to close that gap for organizations that want a faster, incentivized path from discovery to fix.

How to Secure etcd Deployments

If your organization runs etcd—on its own or as part of a Kubernetes deployment—a few baseline steps would have prevented this exact incident:

• Enable TLS for both client-to-server and peer (inter-node) traffic using CA-signed certificates before the cluster ever goes live.
• Turn on client certificate authentication (-client-cert-auth) so every incoming connection has to present a valid certificate.
• Layer role-based access control (RBAC) on top of transport security for fine-grained authorization, rather than relying on network security alone.
• Bind listening ports explicitly instead of to all interfaces, and keep etcd off any publicly routable IP address entirely.
• Regularly scan your own infrastructure with the same tools attackers use—Shodan, Censys, Binaryedge—to catch an exposed instance before someone else does.
• Follow etcd's official security documentation rather than default settings, and audit configuration every time a new cluster or environment is spun up.

Nokia Data Breach: FAQ