Pearson Breach 2025: How an Exposed GitLab Token Led to Cloud Credentials and Stolen Data

On 8 May 2025, BleepingComputer reported that Pearson, the UK-based education and assessment company, had suffered a cyberattack in which data was stolen. Pearson confirmed that "an unauthorized actor gained access to a portion of our systems" and said it believed the actor "downloaded largely legacy data". According to BleepingComputer's sources, the intrusion began in January 2025, when an attacker found a GitLab personal access token in a publicly exposed .git/config file. That token reportedly opened source code containing hardcoded credentials and cloud authentication tokens, which the attacker then used over several months to take data from AWS, Google Cloud, Snowflake and Salesforce CRM. Pearson has not confirmed this attack path, how many people were affected or what "legacy data" means, and it declined to say whether it paid a ransom. It says employee information was not taken and that it has added monitoring and authentication safeguards.

At a glance

What happened

Pearson is one of the largest education companies in the world, selling textbooks, digital learning platforms and assessment services to schools, universities and professional bodies. On 8 May 2025, BleepingComputer published a report saying Pearson had been hit by a cyberattack that exposed customer data. When contacted, a Pearson representative confirmed the incident. "We recently discovered that an unauthorized actor gained access to a portion of our systems," Pearson said, adding that it had stopped the activity, was investigating with forensics experts and was supporting law enforcement. Pearson also said that "at this time we believe the actor downloaded largely legacy data", a line TechRadar repeated when it reported the incident the next day.

The detail of how the attacker got in came not from Pearson but from sources who spoke to BleepingComputer. According to those sources, the attacker compromised Pearson's developer environment in January 2025 using a GitLab personal access token found in a public .git/config file. A .git/config file holds a repository's settings, and if a remote URL is written with a token embedded in it, anyone who can read the file can read the token. BleepingComputer's sources said the token gave access to Pearson's source code, and that the code contained hardcoded credentials and authentication tokens for cloud platforms. Over the following months, the attacker is said to have used those secrets to steal terabytes of data from internal networks and cloud services, including AWS, Google Cloud, Snowflake and Salesforce CRM. The data reportedly includes customer information, financial information, support tickets and source code, and allegedly affects millions of people.

BleepingComputer also noted that Pearson had disclosed in January that it was investigating a breach at one of its subsidiaries, PDRI, which the outlet said "is believed to be related to this attack". Pearson has not publicly connected the two. The outlet compared the technique to the 2024 Internet Archive breach, where attackers found an exposed Git configuration file containing a GitLab authentication token. TechRadar pointed to GreyNoise research showing a rise in internet scanning for exposed Git configuration files.

A good deal remains unconfirmed. Pearson declined to tell BleepingComputer what "legacy data" means, how many customers were affected, whether customers would be notified, or whether it had paid a ransom. It did say the stolen data did not include employee information, and that it had deployed further safeguards, including enhanced security monitoring and authentication. No threat actor had publicly claimed the attack when the story broke. This page treats the GitLab token path as reported, not proven.

Timeline

How it happened: the identity attack path

1. Token left in a public file. According to BleepingComputer's sources, a GitLab personal access token sat in a .git/config file that could be reached from the internet. Tokens often end up there when a remote URL is configured with the credential written into it.
2. Source control access. The token reportedly let the attacker read Pearson's source code repositories in GitLab, giving them the same view of the code as the account that owned the token.
3. Harvesting hardcoded secrets. The repositories reportedly contained hardcoded credentials and cloud authentication tokens. Each one was a separate non-human identity, and each one was now in the attacker's hands.
4. Pivot into cloud and SaaS. Using those secrets, the attacker is said to have reached AWS, Google Cloud, Snowflake and Salesforce CRM, services where the credentials were apparently still valid.
5. Slow, quiet exfiltration. Over several months, the attacker reportedly took terabytes of data. The long dwell time suggests the stolen credentials were not rotated, and that their use did not trigger an alert quickly.
6. Detection and containment. Pearson says it discovered the access, stopped it and added monitoring and authentication safeguards. It has not said when or how it detected the activity.

Impact

• Confirmed by Pearson: an unauthorised actor accessed a portion of its systems and, Pearson believes, downloaded "largely legacy data". Employee information was not included.
• Reported by sources, not confirmed: terabytes of data taken from internal networks and from AWS, Google Cloud, Snowflake and Salesforce CRM, including customer information, financials, support tickets and source code, allegedly affecting millions of people.
• Undisclosed: the number of affected customers, what "legacy data" covers, whether customers will be notified and whether a ransom was paid. Pearson declined to answer each of these questions.
• Potential: stolen source code can reveal further secrets and weaknesses, and customer and support data can be used for targeted phishing against students, teachers and institutions.
• Wider: the reported technique matches a known pattern, also seen in the Internet Archive breach, which makes exposed Git configuration files a live risk for any organisation that serves web content.

What this means for NHI governance

This incident belongs on an NHI list because, as reported, no human account was phished and no password was guessed. Every step ran on machine credentials. A personal access token is a long-lived secret that acts on behalf of a user without that user being present. The hardcoded cloud credentials and tokens in the code were non-human identities too, each with its own access to production data. Once the first token leaked, the rest followed, because they were stored where that token could read them.

The general lesson is about chains. Organisations tend to rate each secret on its own, but attackers see secrets as a path. A source control token with read access is often treated as low risk, yet if the repositories it can read contain cloud keys, its real reach is the reach of every one of those keys. Our Secrets Management Guide covers how to move secrets out of code into a vault, and the Exposed .git Directory Response guide explains what to do when a repository folder is found on a public server. For measuring how far secrets have spread across repositories, see our Secret Sprawl Measurement Guide.

The reported dwell time also matters. If attackers used the same cloud credentials for months, those credentials were long-lived, and their use from an unfamiliar place was not flagged early. Short-lived credentials, rotation and behaviour-based monitoring of machine identities each shorten that window. The same pattern of a single secret opening cloud storage appears in the Gravy Analytics breach, disclosed earlier in 2025.

Recommendations

• Block public access to version control folders. Make sure web servers never serve .git directories or .git/config files, and scan your own internet-facing estate for them. See our Exposed .git Directory Response guide.
• Keep tokens out of remote URLs. Use credential helpers, deploy keys or short-lived tokens rather than writing a personal access token into a repository's remote URL, and give tokens the narrowest scope and shortest expiry that work.
• Remove hardcoded secrets from source code. Scan repositories and their history for credentials, triage what you find and move live secrets into a secrets manager. See our Developer Secret Scanning Triage guide.
• Rotate every secret a leaked token could reach. When a source control token is exposed, treat every credential in every repository it could read as compromised, and rotate them all. See our Credential Rotation at Scale guide.
• Replace long-lived cloud keys. Prefer workload identity federation and short-lived role credentials over static access keys for AWS, Google Cloud and data platforms such as Snowflake. See our AWS Access Keys Security Guide.
• Monitor machine identities for unusual use. Alert when a token or cloud credential is used from a new network, at an unusual volume, or against data it does not normally touch, so months of quiet exfiltration become days or hours.

Frequently asked questions

How was Pearson hacked in 2025?

Pearson has only confirmed that an unauthorised actor gained access to part of its systems. According to sources who spoke to BleepingComputer, the attacker used a GitLab personal access token exposed in a public .git/config file in January 2025, then used hardcoded credentials found in Pearson's source code to reach AWS, Google Cloud, Snowflake and Salesforce CRM. Pearson has not confirmed that account.

What data was stolen in the Pearson breach?

Pearson says the attacker downloaded "largely legacy data" and that no employee information was taken, but it declined to explain what legacy data means. BleepingComputer's sources said the stolen data includes customer information, financial information, support tickets and source code, allegedly affecting millions of people. Those claims have not been independently verified.

Why is an exposed .git/config file dangerous?

A .git/config file stores a repository's settings, including remote URLs. If a token has been written into a remote URL and the file is reachable on a public web server, anyone can read the token and use it to access the repository. If the code inside holds further secrets, that one file can lead to much wider access, as reportedly happened at Pearson and at the Internet Archive.

Related NHI Mgmt Group resources

Internet Archive breach · Red Hat Consulting GitLab breach 2025 · Gravy Analytics breach 2025 · Secrets Management Guide · Exposed .git Directory Response

How NHI Mgmt Group can help

The Pearson case, as reported, shows how one forgotten token and a few hardcoded keys can add up to months of access across cloud and SaaS platforms. NHI Mgmt Group helps security and engineering teams find the machine identities in their code and pipelines, understand which secrets can reach which systems, and build the rotation, scoping and monitoring that break these chains early. Our training covers secrets sprawl, source control tokens and cloud credentials with real breach case studies. See our NHI and AI agent security training.

References

• BleepingComputer: Education giant Pearson hit by cyberattack exposing customer data (8 May 2025)
• TechRadar: Textbook and testing giant Pearson hit by cyberattack, customer data leaked (9 May 2025)
• BeyondMachines: Pearson Education hit by data breach following exposed GitLab token (9 May 2025)