The Breach Pattern That Boards Need to Understand
In October 2025, a threat group called FulcrumSec began demonstrating a repeatable attack chain that intelligence analysts have since described as the most operationally efficient data extortion method currently in active use. The pattern is straightforward: locate a GitHub personal access token (PAT) exposed in client-side JavaScript or a public repository, use it to clone private repositories at scale, search those repositories for additional credentials, and repeat until enough data has been accumulated to sustain an extortion demand.
FulcrumSec’s known victims include Avnet (1.3 terabytes exfiltrated), youX (300 gigabytes), and Novo Nordisk (1.3 terabytes, with a reported $25 million extortion demand). None of these breaches required a zero-day exploit, a phishing campaign, or an insider. The initial access in each case was a credential that should not have existed in the first place — or should have been detected and rotated before an adversary could act on it.
This is not a new category of vulnerability. Exposed credentials in source code repositories and deployed web applications have been a documented risk for over a decade. What is new is the industrialisation of exploitation. Automated scanning tools continuously monitor public repositories and deployed web assets for credential patterns. The time from a credential being exposed to it being discovered by a threat actor has compressed from weeks to hours.
Why Developer Credentials Are High-Value Targets
GitHub personal access tokens, when over-privileged — as they typically are — provide an attacker with read access to all repositories the developer can access. In most enterprises, a senior developer’s PAT provides access not just to their own code, but to shared platform repositories, infrastructure-as-code defining cloud environments, CI/CD pipeline configuration, and, critically, other credentials stored in those repositories.
The escalation path from a single PAT to broad enterprise access is well-documented:
- Initial PAT used to clone all accessible repositories
- Repository content searched for additional secrets: AWS IAM keys, database connection strings, service account passwords, Kubernetes kubeconfig files, additional API tokens
- Cloud credentials used to enumerate cloud environments, access S3 buckets, enumerate RDS instances
- Data staged in the victim’s own cloud storage before exfiltration (reduces network anomaly signals)
- Extortion demand issued, optionally with a threat to publish data on a leak site
The FulcrumSec pattern specifically targeted subdomains — development environments, staging instances, internal tooling portals — where authentication libraries or configuration files are sometimes served as static assets without the same security review applied to production systems.
The Governance Gap
The technical controls that prevent credential exposure are well-understood: secret scanning in CI/CD pipelines, pre-commit hooks that block commits containing credential patterns, repository access controls, PAT rotation policies, and deployment processes that use short-lived credentials rather than static tokens. The governance gap is that these controls are inconsistently applied across the software development lifecycle, and responsibility for them often falls in an ambiguous zone between the security team and engineering.
Several structural factors contribute to the exposure rate:
Developer autonomy over credential management. In most organisations, individual developers generate and manage their own PATs without centralised audit or rotation enforcement. A PAT generated in 2023 for a now-deprecated integration may still be active, still have repository access, and still exist in a configuration file that was deployed somewhere and forgotten.
Staging and development environment oversight gaps. Production deployments receive security review. Staging environments, internal dashboards, and developer tooling often do not. These environments frequently contain real credentials with real access — and they are indexed by search engines or exposed via subdomains that threat actors enumerate.
Third-party integration proliferation. OAuth apps, GitHub Apps, and CI/CD integrations each create additional token surface. Many organisations cannot enumerate how many active OAuth authorizations exist on their GitHub organisation, or which of those authorizations have write access to production repositories.
Legacy secrets accumulation. Enterprise environments accumulate secrets over years of development. Rotating actively used credentials requires coordination across teams and can break deployments. The result is that rotation policies that exist on paper are often not enforced in practice.
What the FulcrumSec Pattern Implies for Risk Posture
The FulcrumSec breach pattern implies that credential sprawl has become a source of material financial risk, not just a compliance gap. The operational impact follows a predictable structure:
Breach notification and regulatory cost. Multi-terabyte exfiltrations of the type FulcrumSec conducts typically include employee data, customer data, and internal business information — all potentially triggering notification obligations under GDPR, CCPA, and sector-specific regulations. Novo Nordisk’s breach reportedly included data across multiple European jurisdictions.
Extortion decision. Organisations face a binary choice: pay a demand they cannot validate will result in data deletion, or accept that exfiltrated data will be published. Neither option eliminates reputational or regulatory exposure.
Business disruption from repository access. If the attacker has read access to infrastructure-as-code and CI/CD configuration, they may understand the victim’s environment better than the victim does during the response window. This complicates containment.
Remediation cost. Rotating credentials across an enterprise following a confirmed PAT compromise requires identifying every system that uses the compromised credential — often an unknown list — and coordinating rotation without breaking deployments.
Board Reporting Framework
CISOs briefing boards on developer credential risk should frame it around three questions:
1. Do we know what secrets we have and where they are?
This is a fundamental inventory question. An organisation that cannot enumerate its active PATs, service account keys, API tokens, and deployment credentials cannot assess its exposure. Secret scanning platforms (GitHub Advanced Security, GitLeaks, TruffleHog Enterprise, Nightfall) provide discovery capability. The first step is running discovery in audit mode to understand the current state before attempting remediation.
2. Do we have detection capability for credential misuse?
Even with rotation policies in place, secrets will be exposed. Detection of anomalous credential usage — a PAT used from an unrecognised IP, a service account accessing repositories outside its normal pattern, an IAM key calling APIs it has never called before — provides a response window before data can be fully exfiltrated. This requires SIEM integration for GitHub audit logs, AWS CloudTrail, and equivalent cloud provider audit trails.
3. Have we applied least-privilege to developer credentials?
PATs with full repository read access across an entire GitHub organisation are unnecessary for most use cases. Fine-grained PATs, introduced by GitHub in 2022, allow scoping to specific repositories and permission types. Requiring fine-grained PATs for all new integrations and progressively migrating existing integrations reduces the blast radius when a token is compromised.
Recommended Actions
Immediate: Run secret scanning across all repositories and deployed web assets. Treat any identified live credential as compromised and rotate before investigating further.
Short-term: Enforce PAT expiry policies. GitHub organisation administrators can require that all PATs expire within a maximum period (typically 90 days). Implement branch protection and CI checks that fail builds containing credential patterns.
Medium-term: Move from static PATs to short-lived tokens for CI/CD integrations. GitHub Actions OIDC, for example, allows workflows to authenticate to cloud providers using ephemeral credentials that expire with the workflow run, eliminating the need for long-lived secrets in repository settings.
Governance: Define ownership for credential lifecycle management — this falls between security and engineering and typically belongs to neither without an explicit assignment. Create a secrets inventory as an auditable artefact with defined review cycles.
The FulcrumSec breach pattern is not a sophisticated attack. It is an automated scan followed by a predictable escalation chain. The controls that prevent it are available to every organisation that runs software development. The gap is adoption, not capability.