F5 breach shows how valid accounts and source code exposure raise risk

At a glance

What this is: This is FireCompass’s weekly intelligence report, and its central finding is that sophisticated attacks in mid-October 2025 combined valid accounts, supply chain exposure, and large-scale patch urgency.

Why it matters: It matters to IAM, PAM, and NHI teams because the incidents show how access governance gaps in development, vendor, and administrative pathways can turn trusted credentials into broad operational risk.

By the numbers:

• F5 disclosed 45 CVEs in Q3 2025, compared with 6 in Q2 2025, suggesting an accelerated patching timeline after the breach.
• F5 said its products are deployed by 48 of the world's top 50 corporations and the U.S. federal government.
• MANGO operates 2,800 locations across 120 countries and reported annual revenues of €3.3 billion.
• Microsoft disrupted a campaign that used over 200 fraudulent code-signing certificates to deliver malicious installers.

👉 Read FireCompass's weekly cybersecurity intelligence report for 14 Oct to 21 Oct 2025

Context

FireCompass’s weekly intelligence report highlights a broader governance problem: attackers are increasingly blending valid access, trusted relationships, and supply chain compromise to reach high-value environments. In identity terms, the common failure is not simply weak authentication but the absence of tight control over privileged access, third-party pathways, and developer trust boundaries.

The F5 incident is especially relevant to IAM and PAM practitioners because it shows how a long-lived account foothold inside a development environment can expose source code, vulnerability research, and customer configuration data at once. That is a typical pattern in modern enterprise risk, not an edge case.

Key questions

Q: What breaks when valid accounts are used to reach software development systems?

A: When valid accounts are used in development systems, the normal trust granted to engineers, service users, and automation can be turned into covert access to source code, vulnerability notes, and configuration data. That breaks the assumption that internal access is inherently safe and makes standing privilege the real weakness.

Q: Why do stolen source code and vulnerability details increase risk after a breach?

A: Stolen source code and vulnerability details give attackers design intelligence. Even without immediate exploitation, they can study implementation patterns, identify weak points, and plan follow-on attacks more precisely than they could from external scanning alone. That extends the breach’s value well beyond the initial intrusion.

Q: How do security teams know when trusted relationships are becoming a control gap?

A: Trusted relationships become a control gap when access flows between systems are broader than the business case and are not continuously revalidated. Warning signs include shared credentials, difficult-to-explain cross-system access, and engineering tools that can reach multiple sensitive repositories without tight scoping.

Q: Which frameworks apply when source code exposure and valid-account abuse overlap?

A: NIST CSF, MITRE ATT&CK, and NIST SP 800-53 all apply here because the incident combines access control, credential abuse, and data exfiltration. Teams should map repository access and privileged engineering workflows to those frameworks, then use the mapping to close trust-boundary and audit gaps.

Technical breakdown

Valid accounts and long-lived access in development environments

Valid accounts are especially dangerous when they exist inside engineering or product-development systems because they inherit trust from legitimate workflows. Once an attacker is inside, the same access that supports builds, documentation, or source control can be used to read sensitive code, vulnerability notes, and configuration data. The problem is not just credential theft. It is the combination of standing privilege, weak segmentation, and delayed detection in environments that are assumed to be internal and safe.

Practical implication: isolate development credentials, enforce least privilege, and treat source-code environments as high-value identity zones.

Supply chain exposure from stolen source code and vulnerability intelligence

Stolen source code changes the attacker’s options because it can reveal product logic, hidden flaws, and implementation details that make exploitation easier. Even when there is no evidence of immediate exploitation, the disclosure of vulnerability research can shorten defenders’ response window and increase the value of follow-on targeting. For vendors and customers alike, the risk is not limited to intellectual property loss. It includes downstream exposure if attackers use the material to plan more precise attacks.

Practical implication: assume exposed engineering data may accelerate future exploitation and prioritize containment, patch validation, and targeted threat hunting.

Why trusted relationships complicate detection and response

Trusted relationships are difficult to monitor because they often look like normal administration, support, or internal collaboration. Attackers abuse that familiarity to move between systems without triggering obvious alarms. In a breach like this, the governance gap is usually not the absence of logs but the absence of meaningfully restrictive trust policies around who can reach what, from where, and with which credentials. That is where identity controls and network controls need to reinforce each other.

Practical implication: review cross-system trust, admin pathways, and service credentials together instead of auditing them as separate control domains.

Threat narrative

Attacker objective: The objective was to obtain sensitive product intelligence and customer-related data that could be used to improve offensive capability and increase downstream targeting options.

1. Entry occurred through valid accounts and long-term access inside F5’s internal development environment, which gave the attacker a foothold in trusted systems.
2. Escalation and collection followed as the actor accessed source code repositories, engineering knowledge, and vulnerability information, then archived data for exfiltration.
3. Impact came from the exposure of proprietary code, undisclosed vulnerability details, and customer configuration information that could support future targeted attacks.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Valid-account abuse in development environments is an identity governance problem first. When attackers use legitimate credentials to reach source code and engineering knowledge, the failure is not only detection latency. The deeper issue is that development access often inherits trust without the same lifecycle rigor applied to production administration. This is exactly where IAM, PAM, and NHI governance converge: standing access in engineering systems becomes a supply chain risk when it is not continuously constrained.

Source-code exposure creates a governance debt that outlasts the incident window. Once code and vulnerability research leave the environment, defenders must assume attackers can work from a copy of the system’s own design intelligence. That means the breach is not contained by account revocation alone. Practitioners need incident response models that include patch acceleration, exposure reassessment, and reuse of stolen architectural knowledge as a threat factor.

Trusted relationships are the named concept this incident sharpens. The breach shows how internal trust boundaries can become an attack path when access between systems is broader than the business justification. In practice, trusted relationships should be treated as explicit governance objects with scoped authorization, logging, and periodic revalidation. Without that discipline, a legitimate session can become a bridge to multiple sensitive repositories and platforms.

Emergency patching only works when identity and change control move together. F5’s accelerated CVE disclosure highlights a recurring pattern in major incidents: technical remediation is only part of the response, because patching without access review leaves the same pathways open for repeat exploitation. Practitioners should align privileged access review, certificate rotation, and engineering environment hardening as one response motion, not separate workstreams.

This breach reinforces why NHI governance matters in software supply chains. Engineering platforms rely on service accounts, tokens, credentials, and automation paths that behave like non-human identities even when they sit behind human teams. If those identities are not governed with the same rigor as human admin access, attackers can use them to move quietly through development and release systems. Security teams should now treat software supply chain access as a lifecycle problem, not a point-in-time control issue.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, followed by 37% for inadequate monitoring and logging and 37% for over-privileged accounts.
• From our research: The 52 NHI Breaches Analysis shows how exposed credentials and weak lifecycle controls repeatedly turn access into breach impact, which is why trusted development paths need continuous identity review.

What this signals

Trusted development access is becoming a board-level exposure area. The practical lesson from this week’s incidents is that engineering systems, vendor workflows, and administrative pathways can no longer be treated as separate governance domains. As access becomes more interconnected, identity teams should expect pressure to prove who can reach source code, signing material, and release infrastructure at any given point.

Machine identity governance needs to extend into software delivery. Service accounts, build tokens, signing certificates, and automation credentials are effectively part of the release chain, so lifecycle discipline matters as much there as it does in production. Teams that align privileged access review with certificate rotation and repository governance will be better positioned to contain the next development-environment compromise.

For practitioners

• Harden engineering access paths Review which accounts can reach source control, documentation, and build systems, then remove any standing access that is not required for a current business task. Separate development admin paths from routine contributor access and require stronger authentication for repositories containing product code.
• Revalidate trusted relationships Inventory internal trust links between product teams, shared platforms, and external support connections. Reissue or revoke credentials where access is inherited rather than explicitly justified, and log cross-system use so unusual access paths are visible in the SIEM.
• Treat exposed code as future attack fuel Assume stolen source code and vulnerability notes can be weaponized later, even if there is no immediate exploitation. Prioritize threat hunting, patch verification, and targeted monitoring for systems that share the same architecture, libraries, or administrative patterns.
• Align certificate rotation with incident containment Rotate signing certificates, API keys, and administrative credentials together when a development environment is compromised. Partial rotation leaves residual trust in place and gives attackers another route back into engineering or release workflows.

Key takeaways

• The breach shows that valid-account abuse inside development environments can expose source code, vulnerability research, and customer data in one move.
• The scale of remediation, including 45 CVEs in a single quarter, suggests defenders must treat exposure as an ongoing governance problem rather than a one-time incident.
• Stronger segmentation, tighter trust relationships, and synchronized credential rotation are the controls most likely to reduce repeat impact.

Key terms

• Valid accounts: Legitimate credentials, tokens, or identities that an attacker uses to authenticate normally. The danger is not the login method itself, but that trusted access can be abused without triggering many traditional malware or perimeter alerts.
• Trust Relationship: A configured connection in which one identity, system, or vendor is allowed to rely on another without repeating full verification every time. Trust relationships are efficient, but they become risky when they outlive the business need or grant broader access than the original purpose justified.
• Source Code Exposure: Source code exposure is the unintended disclosure of application code to an attacker or unauthorised party. Even without full remote code execution, leaked source can reveal business logic, internal routes, and embedded secrets such as API keys, which can widen the impact of a vulnerability.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full article

FireCompass's full report covers the operational detail this post intentionally leaves for the source:

• Step-by-step incident summaries for each attack in the weekly timeline, including the F5 breach and the MANGO third-party compromise
• The full MITRE ATT&CK mappings and incident-specific technical notes that support deeper triage and detection tuning
• Remediation guidance by incident, including patching, credential rotation, and third-party risk actions for teams already in execution mode
• The broader weekly threat list, which helps teams compare this breach pattern against other active campaigns and sector targets

👉 The full FireCompass report includes the incident timelines, ATT&CK mappings, and remediation details for each case.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners building repeatable governance across engineering, operations, and security programmes.