Black October exposed hidden dependency reach across systems

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: Black October exposed how dependency failures can cascade into credential exposure, trust withdrawal, and cross-system investigation burdens.

Why it matters: IAM, PAM, and NHI teams need to know which dependencies carry credentials, privileges, and trust relationships so incident response can contain blast radius instead of discovering it live.

👉 Read Unosecur's analysis of Black October and hidden dependency exposure

Context

October’s incidents show a governance gap, not just a patching problem: organizations often do not know which identities, secrets, and trust relationships are reachable until an investigation is already underway. That makes dependency failure an access-governance issue as much as a software issue, because the blast radius is determined by what the dependency could reach, not only by the flaw that triggered the review.

In practical terms, teams need evidence that a dependency’s failure can be contained before they trust it in production. A Non-Human Identities lens is useful here because the same investigation that identifies vulnerable software also has to trace exposed service accounts, API keys, and platform-held credentials.

Key questions

Q: What breaks when a dependency failure exposes credentials and trust relationships?

A: Containment breaks first. A dependency may appear like a software issue, but if it can reach secrets, cloud roles, or certificate trust, incident response has to treat it as an identity and access event too. Teams then need to identify what the dependency could access before deciding what to revoke, rotate, or isolate.

Q: Why do dependency incidents create so much investigation pressure for IAM teams?

A: Because the real question is often not whether the flaw existed, but what identities and resources were reachable while it did. IAM teams have to determine whether service accounts, API keys, or platform-held secrets were exposed, then decide which relationships can be withdrawn without causing wider outages.

Q: How should teams contain access when a supplier or platform is under investigation?

A: Start with scope, not assumption. Identify the specific identities, trust relationships, and secrets that dependency could reach, then isolate or revoke only the paths that create unacceptable exposure. Containment that is too broad causes avoidable disruption; containment that is too narrow leaves the same exposure in place.

Q: What is the difference between patching a dependency and removing its access risk?

A: Patching fixes the flaw that triggered the incident, but access risk may persist if the dependency already saw credentials, tokens, or trust anchors. Removing access risk requires rotation, revocation, or isolation of what was exposed. The two actions are related, but they are not interchangeable.

Technical breakdown

Why dependency failures become access failures

A dependency is not just code or infrastructure. It is any external component whose failure can change what an application, platform, or agent can access. When that component holds secrets, certificates, or delegated trust, the failure becomes an access event, not only an availability event. The critical question is not whether the supplier can patch quickly, but whether the customer can prove what the dependency could read, change, or authenticate to before the flaw was fixed. That is why incident response often has to map execution paths, credential exposure, and trust relationships together. See the [[L2|Ultimate Guide to NHIs]] for the identity types that make this problem persistent. Read the Ultimate Guide to NHIs: What are Non-Human Identities.

Practical implication: build dependency inventories that include reachable credentials, trust links, and execution scope, not just software versions.

Why shared credentials make containment ambiguous

Shared credentials and broad roles reduce operational friction, but they also blur ownership and make withdrawal difficult during an incident. If multiple workloads, environments, or operators rely on the same access path, responders cannot confidently revoke it without breaking unrelated services. That is the architectural defect exposed in October: a dependency can be repaired while the access it used remains live. In identity terms, the failure is lifecycle opacity. You cannot contain what you cannot attribute, and you cannot safely attribute what has been reused across too many systems. The result is investigative drag and delayed containment.

Practical implication: replace shared access paths with identities that can be isolated, named, and revoked without collateral impact.

Why agent purpose does not define agent permissions

The agent disclosures in the source underline a deeper point: intended purpose is not the same as permitted reach. A support agent, coding agent, or other AI system may be assigned a narrow goal while operating with tools that can access far more data or actions than the task requires. That is an assumption failure in the governance model, because approval based on workflow intent does not constrain runtime use of credentials. Once the environment supplies broad access, the agent can act within the full limits of that access even if the task was innocuous. The control question is therefore about deployment boundaries, not intent statements.

Practical implication: scope agent credentials to the smallest verifiable execution boundary and review the tools they can actually invoke.

Threat narrative

Attacker objective: The objective is to reach, copy, or retain access to credentials and trust paths that allow broader system reach than the original dependency should have had.

1. Entry begins through vulnerable dependencies, malicious package releases, exposed platforms, or weak certificate trust rather than a single uniform intrusion path.
2. Credential access follows when affected environments, customer variables, or retained secrets are reachable by the compromised component or platform.
3. Escalation occurs when those credentials, roles, or trust relationships let the attacker or incident response path move beyond the original failure boundary.
4. Impact is the need to rotate secrets, revoke trust, and investigate systems that may have been reachable even when no direct breach is yet confirmed.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dependency reach is now an access-governance problem, not a software-only problem. Black October shows that organizations do not fail only because a dependency breaks; they fail because the dependency’s failure can reach secrets, trust links, and operational accounts that were never meant to be exposed together. The implication is that dependency management and identity governance can no longer be treated as separate disciplines.

Uncertainty about reachable access is itself a control failure. If an organisation cannot state which credentials, roles, and trust relationships a dependency could access before containment, then the programme has no usable boundary model. That is why incident pressure reveals the weakness late: the governance assumption was that dependency failure would remain local, and October disproved that assumption in practice.

Shared privilege creates an identity blast radius that investigations cannot easily unwind. When a platform, package, or agent inherits access across systems, the response team has to choose between over-revocation and under-containment. That is not simply awkward operations; it is evidence that privilege design failed to respect separation of duties and recoverability.

Purpose-based approval is insufficient when the runtime path can widen. The article’s agent examples show that an assigned task does not define the boundary of access if the environment, tools, or credentials permit more. For autonomous or semi-autonomous systems, the central issue is not whether the purpose was legitimate, but whether the access model can constrain what the system is actually able to do.

What this signals

Identity blast radius should become a standard design term for dependency governance. If a supplier issue can force teams to discover reachable credentials under incident pressure, then the programme has already accepted a boundary problem that patching alone will not solve.

Enterprises should watch for the point where operational convenience turns into recoverability debt. Shared identities, broad trust, and inherited permissions make it harder to know what can be withdrawn cleanly when a dependency is compromised or simply behaves unpredictably.

For practitioners

• Map dependency reach before incidents force the issue Inventory which workloads, secrets, roles, certificate relationships, and external trust paths each critical dependency can reach in production.
• Separate identities by recoverability Replace shared or broad access with distinct service accounts and scoped credentials that can be revoked without interrupting unrelated services.
• Test containment, not just patch status Run incident exercises that ask what a compromised package, platform, or trust anchor could access before and after remediation.
• Restrict agent runtime permissions to task scope Limit tools, data sources, and credential exposure to the minimum access needed for the specific session or workflow.
• Tie ownership to every critical dependency Require an accountable owner for each dependency whose failure could expose identities, secrets, or trust relationships.

Key takeaways

• Black October shows that dependency failures can turn into access and trust problems, not just software defects.
• The evidence spans malicious package activity, stored environment variables, leaked internal credentials, and certificate trust issues.
• Teams need dependency inventories and containment models that show which identities and secrets can be withdrawn before an incident, not during one.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: What are Non-Human Identities · T1190 Exploit Public-Facing Application Defensive Guide · CISA Binding Operational Directives Guide · LiteLLM PyPI package breach

Key terms

• Dependency Reach: The set of systems, identities, data stores, and trust relationships a dependency can access while it is running. In incident response, this matters because a broken package, platform, or service can expose more than its own code path if its permissions were never tightly bounded.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• 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.
• Shared Credential Risk: Shared credential risk is the exposure created when multiple people or devices rely on the same login path. It increases the blast radius of compromise and makes ownership, revocation, and auditability harder. In mature identity programmes, shared access is managed as an entitlement, not an informal convenience.

What's in the full article

Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:

• Incident-by-incident breakdown of PHP2Shell, LiteLLM, Railway, Zeabur, and eMudhra
• Operational remediation guidance for exposed credentials, certificate trust, and platform-held secrets
• Additional context on how Unosecur links permissions, resources, risks, and historical events
• Product-specific details on guided remediation, agent sessions, and MCP access controls

👉 The full Unosecur post covers the incident breakdowns, dependency reach analysis, and remediation context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.