Sweden's E-Government Source Code Is Circulating Online. The Entry Point Was a Jenkins Server.

Commissioned, Curated and Published by Russ. Researched and written with AI.

What’s New: 13 March 2026

CGI Sverige has confirmed the incident, stating that “an older application version and its source code were accessible” on internal test servers not used in production. Sweden’s minister of civil defense, Carl-Oskar Bohlin, has confirmed the breach publicly. CERT-SE and the National Cyber Security Center are actively investigating. The actor behind this – ByteToBreach – posted a Viking Line breach the day prior, suggesting this is an ongoing campaign against Swedish and European infrastructure via CGI’s managed services footprint.

Changelog

Source code for Sweden’s E-plattform – the digital identity system running across multiple Swedish government authorities – is now circulating freely on the open web. The actor published it for free. Citizen PII and electronic signing documents are being sold separately.

The entry point was a Jenkins server. The chain from there took less than four steps to reach production secrets and the government codebase. None of those steps required a zero-day.

What Was Compromised

CGI Sverige AB is the Swedish subsidiary of CGI Group, one of the largest IT consulting and outsourcing firms in the world. In Sweden, CGI operates as a primary contractor for government digital services – the kind of organisation that holds the keys to infrastructure it doesn’t technically own.

The target was Sweden’s E-plattform: a digital identity management system used across multiple Swedish government authorities. According to reporting by Aftonbladet and SVT, the platform underpins electronic signing and identity verification for public services used by approximately 95% of Sweden’s population of 10.7 million.

The threat actor, operating under the handle ByteToBreach, published the following to the open web:

• Full E-plattform source code
• Internal staff database
• API document signing systems
• Jenkins SSH pivot credentials
• RCE test endpoints
• Initial foothold and jailbreak artefacts

Citizen PII databases and electronic signing documents were withheld from the free release and are being sold separately.

CGI’s response: the company told Aftonbladet that “an older application version and its source code were accessible” on two internal test servers not used in production, and that “there was no indication that customer production data or operational services were affected.” IT security expert Anders Nilsson reviewed the leak and concluded the hack “looks genuine.”

Sweden’s minister of civil defense confirmed the incident. CERT-SE and the National Cyber Security Center are investigating.

The Attack Chain

ByteToBreach was explicit about the methods used. The disclosed attack path, as reported by Dark Web Informer and Threat Landscape, runs as follows:

Step 1: Jenkins server compromise. Jenkins was the initial foothold – the CI/CD system was reachable and exploitable. From here, everything else becomes possible.

Step 2: Docker escape via the Docker socket. The Jenkins service account was a member of the Docker group. That’s a misconfiguration that grants root-equivalent access to the host. Any user in the Docker group can mount the host filesystem directly: docker run -v /:/host. The container boundary ceases to exist. The attacker moved from the Jenkins container to the underlying host.

Step 3: SSH private key pivots. With host access established, the attacker harvested SSH private keys – the kind that accumulate in CI environments because pipelines need them to deploy. Those keys were used to move laterally across the infrastructure.

Step 4: .hprof file reconnaissance. Java heap dump files on the system were analysed for credentials, tokens, and internal state. Heap dumps capture the complete memory of a running JVM – they routinely contain database connection strings, decrypted secrets, and authentication material.

Step 5: SQL COPY TO PROGRAM. PostgreSQL’s COPY TO PROGRAM command executes arbitrary shell commands with the privilege of the database server process. With database superuser credentials – which CI/CD pipelines frequently hold – this is a straightforward OS command execution path.

Five steps. No novel exploitation. Every technique in this chain has its own CVE history, advisory, and documented mitigation.

Jenkins and the Docker Socket: An Old Problem That Persists

The Jenkins/Docker socket misconfiguration is not new. It appears in security advisories. It gets conference talks. It has its own dedicated documentation in hardening guides.

It persists because it’s convenient. Jenkins needs to build Docker images. The easiest way to make that work is to give the Jenkins user access to the Docker socket on the host. One line in a group membership config, and the pipeline can build images. Problem solved – until it isn’t.

The Docker socket grants control of the Docker daemon. Control of the Docker daemon on Linux is functionally equivalent to root on the host. You can launch a privileged container, mount the host filesystem, read /etc/shadow, write to /etc/cron.d, or simply exfiltrate whatever is in /home, /var, or wherever secrets happen to live.

The mitigations are well-established: run Docker-in-Docker (DinD) in a properly isolated environment, use rootless Docker, use Podman, use BuildKit with a dedicated socket, or use a container-native build system that doesn’t require socket access at all. Any of these prevents the Docker escape. CGI’s environment used none of them.

This is not a criticism that requires hindsight. The risk was documented before this breach occurred.

CI/CD Is the Credential Store You’re Actually Protecting

A Jenkins server – or any CI/CD system – is not just a build tool. It’s the highest-privilege credential aggregation point in most engineering environments.

Consider what a typical pipeline holds: cloud provider credentials (AWS, Azure, GCP) with deployment permissions, SSH keys for production servers, API tokens for third-party services, database passwords for migration scripts, container registry credentials, signing certificates, and secrets management tokens.

The pipeline needs all of these to do its job. Build, test, deploy: each phase touches a different slice of the credential surface. An attacker who compromises the CI/CD system doesn’t need to attack each downstream system individually. They’ve already got the keys.

This is the “CI/CD as crown jewel” problem. The pipeline is the most privileged system in your environment, and it’s also the system most likely to be operated with developer convenience in mind rather than security hardening. It has broad network access (it deploys everywhere), elevated credentials (it needs them), and is frequently exposed to untrusted code (it builds pull requests).

Previous posts on this site have covered CI/CD privilege separation and CI/CD as an attack surface in more detail. The CGI breach is a case study in what happens when those concerns are not operationalised.

.hprof Files: The Forgotten Reconnaissance Goldmine

ByteToBreach specifically listed .hprof file analysis as a step in the attack chain. This deserves attention because it’s an underreported attack vector.

.hprof files are Java heap dumps. They’re generated when a JVM crashes or when a developer triggers them manually to diagnose memory issues. They contain the complete in-memory state of the running process at the time of capture.

In production or CI environments, that means: database connection strings (as they exist in memory, after any decryption), authentication tokens and session cookies, any secrets loaded from an HSM or secrets manager that are now sitting decrypted in heap, and internal state that reveals architecture, API structure, and data models.

Heap dumps get generated during incidents, left in /tmp or wherever the JVM was configured to write them, and forgotten. Nobody thinks of them as credentials. Nobody rotates them. Nobody applies the same access controls to .hprof files that they’d apply to a secrets vault.

If your services run on the JVM, audit where heap dumps are written, who can read them, and whether they’re being cleaned up. If a production process crashes and writes a heap dump, treat that file with the same sensitivity as a credential store – because that’s effectively what it is.

The Contractor as Supply Chain Vector

CGI Sverige is not a Swedish government agency. It’s a contractor. The E-plattform is not CGI’s platform – it’s deployed at Swedish authorities, used by Swedish citizens, operated as Swedish government infrastructure. CGI builds and maintains it on behalf of those authorities.

This distinction matters for understanding what an attacker gains from compromising the contractor rather than the government directly.

Source code gives an attacker a complete understanding of the system without requiring access to the system. From the leaked E-plattform code, a capable actor can identify: authentication flows and where they might be bypassed, cryptographic implementations and whether they’re sound, API endpoints and their expected inputs, hardcoded credentials or configuration values that survived code review, and integration points with other government systems.

This is architectural intelligence. A nation-state actor with this source code now has a detailed map of Sweden’s digital identity infrastructure – the system that 10.7 million people depend on for government services. They can take their time finding weaknesses in the deployed production system, guided by the source code, without ever triggering the kind of access patterns that detection systems watch for.

The blast radius of privileged identity compromise – and how far lateral movement can reach from a single misconfigured system – is a pattern this site has covered in other contexts, including the Stryker/Handala wiper incident and identity-origin attacks in cloud environments. The CGI case is a supply chain variant of the same problem: you don’t need to attack the target directly if you can attack the organisation that built and maintains it.

What to Fix

If you’re running similar infrastructure, the mitigations are not exotic:

Docker socket access. Audit which service accounts have access to /var/run/docker.sock. Jenkins, in particular, should not be in the Docker group on the host. Use rootless Docker, Podman, or a dedicated DinD setup with proper isolation. If you’re building images in CI, there are now multiple well-supported approaches that don’t require host socket access.

Jenkins least privilege. Jenkins should run with the minimum permissions needed for its actual workload. That means no Docker group membership unless explicitly justified and mitigated, no broad filesystem access, and network egress limited to what deployment actually requires. Treat the Jenkins node as a high-value target and harden accordingly.

Heap dump cleanup. Add .hprof cleanup to your incident response and deployment procedures. Know where your JVMs are configured to write heap dumps (-XX:HeapDumpPath). Apply appropriate file permissions. Consider whether heap dumps should ever be written to shared or network-accessible paths.

PostgreSQL COPY TO PROGRAM. If your application doesn’t use COPY TO PROGRAM or COPY FROM PROGRAM, disable them. You can restrict the COPY command to specific roles, and you can remove superuser grants from application database users. The principle of least privilege applies to database users as much as it applies to operating system accounts.

Credential rotation post-compromise. If a CI/CD system is compromised, every credential that has ever passed through it should be considered exposed. That’s not a conservative posture – it’s the accurate one. Rotate cloud provider credentials, SSH keys, API tokens, database passwords, signing certificates. The scope is usually larger than it feels, because pipelines accumulate credential access over time.

Closing

The attack chain that compromised CGI Sverige AB is composed entirely of known misconfigurations and well-documented techniques. Jenkins and Docker socket misconfiguration. CI/CD as an unprotected credential aggregation point. Forgotten heap dump files as a reconnaissance resource. PostgreSQL superuser privileges used for OS command execution. SSH key harvesting for lateral movement.

None of this required novel exploitation. None of it required a zero-day. The barrier to a breach of this magnitude – a contractor compromise that exposed the source code of a national government identity platform – was a series of configuration decisions that the security community has been flagging for years.

The question worth sitting with is not whether CGI’s environment was uniquely careless. It’s how many organisations have the same configuration running today, in environments with similar blast radius, waiting for someone to walk the same chain.