StubMaker and JupyterLab expose how package policy failures become compromise paths

At a glance

What this is: This weekly security briefing argues that package ecosystems and notebook platforms are turning normal installation workflows into compromise paths, with malicious gems, PyPI fallout, and JupyterLab policy gaps all showing how trust is abused.

Why it matters: IAM and security teams need to treat developer tooling, extension managers, and package install paths as governed access surfaces because they can execute code, expose secrets, and bypass intended controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

👉 Read Corgea's weekly security briefing on StubMaker, LiteLLM, and JupyterLab policy gaps

Context

Package ecosystems are not just software distribution channels. They are execution environments where install-time hooks, extension managers, and dependency trust can be used to run attacker-controlled code inside developer workflows before teams consider the system compromised. This briefing is grounded in that problem space, and it is also where identity governance begins to matter because secrets, tokens, and service credentials are often present in those same workflows.

The article combines two related governance failures. First, malicious packages can execute during installation in ways developers do not expect. Second, notebook and extension platforms can let policy controls lag behind operational reality, which creates a control gap between what teams believe is blocked and what can still run. That is a familiar pattern in software supply chain incidents, but the notebook and Python ecosystem angle makes it especially relevant to identity, secrets, and runtime access governance.

Key questions

Q: What breaks when package installation can execute code before review?

A: The control that breaks is the assumption that installation is a safe administrative step. If package hooks can run during build or setup, then malware can execute before static review, credential scanning, or policy checks finish. That creates a gap where the package name looks acceptable but the runtime behaviour is already hostile. Teams need to govern execution paths, not just dependency lists.

Q: Why do malicious package incidents so often become identity incidents?

A: Because the package rarely matters as much as the secrets it can reach. Developer workstations, build systems, and notebook environments often hold tokens, API keys, and service credentials that allow broader access than the package itself. Once those identities are exposed, the attacker can pivot into cloud, CI/CD, or internal tooling long after the package is removed.

Q: How do security teams know if extension governance is actually working?

A: Measure whether unapproved extensions can be installed, whether dormant packages are being reviewed after sudden updates, and whether malicious listings can be blocked before execution. If a dangerous package can still reach a live workspace, governance is failing at the point that matters most.

Q: Who is accountable when a compromised package exposes cloud or developer secrets?

A: Accountability sits with the teams that own maintainer credential governance, release controls, CI/CD hardening, and secret rotation. If a compromised dependency touched systems with sensitive credentials, the response must include revocation, reconstruction, and post-incident access review. Software supply chain incidents are identity incidents, not just build failures.

Technical breakdown

Why install-time execution is the real supply chain risk

Package managers often treat installation as a trusted administrative action, but many ecosystems allow code to run during that step through hooks such as extconf.rb, setup scripts, or build-time helpers. That means a malicious package does not need to wait for production runtime to execute. It can run as soon as a developer installs it, reach the local environment, and harvest credentials, tokens, or internal metadata before anyone notices. Empty build artifacts or normal-looking package names make the compromise harder to distinguish from legitimate dependency activity.

Practical implication: inventory and restrict install-time execution paths, not just known malicious packages.

How notebook extension controls fail in practice

Notebook platforms and extension managers often rely on blocklists, plugin locks, and allowlists to constrain what can be installed or enabled. The problem is that these controls can fail if names are compared non-canonically, if one API path skips policy checks, or if administrator intent is not enforced consistently across interfaces. In shared Jupyter deployments, that turns a governance model into a set of bypassable hints. The control failure is not only technical. It is also semantic, because the platform may appear compliant while still permitting unapproved extensions.

Practical implication: test every extension path for policy bypass, including API routes and non-canonical name handling.

Why credential exposure outlives the malicious package

The operational damage from a supply chain compromise often comes from stolen credentials rather than the package itself. Once secrets are captured, the attacker can pivot into CI/CD, cloud consoles, or developer tools long after the package has been removed. That is why package incidents create a long response tail. Short-lived malicious code can produce persistent identity risk if credentials are not rotated, scoped, and monitored as compromised the moment exposure is suspected.

Practical implication: treat package compromise as a credential incident and rotate affected secrets immediately.

Threat narrative

Attacker objective: The attacker aims to convert trusted package installation into credential theft and broader environment access that can survive package removal.

1. Entry occurs when a developer installs a typosquatted Ruby gem or a compromised PyPI release and the package executes during the normal install path.
2. Escalation follows when install-time code harvests credentials or launches a loader chain that survives the initial package action and reaches broader developer or CI/CD access.
3. Impact comes when stolen secrets or silently bypassed controls allow persistence, downstream compromise, or wider software supply chain exposure.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Install-time execution is now a governance problem, not just a malware problem. Ruby gems that run extconf.rb or Python packages that trigger build-time logic are effectively asking the runtime to trust code before the package is fully evaluated. That means software supply chain defence has to include execution policy, not only signature checks and vulnerability scanning. For practitioners, the key question is whether your package workflow assumes installation is inert when it is not.

Notebook extension governance is a close cousin of identity governance because it controls who and what is allowed to act inside the environment. JupyterLab blocklists and plugin locks are not just application hardening features. They are access controls over executable components, and bypasses in those controls should be treated like privilege defects. Where extension policy can be circumvented through canonicalisation issues or missing awaits, the governance model has already failed. Practitioners should test the control path, not just document it.

Credential exposure is the durable blast radius of package compromise. The immediate malware may be removed, but stolen secrets, API keys, and CI/CD tokens remain viable until rotated and invalidated. This is where the intersection with NHI governance becomes explicit: service tokens and pipeline credentials are identities, and they need lifecycle controls just like human accounts. For security teams, the breach is not over when the package disappears.

Install-time compromise creates what we call an execution-trust gap. The gap appears when teams trust the package manager or extension manager to separate approved software from active code, but the platform still executes attacker-controlled logic as part of the normal workflow. That concept matters because it explains why traditional blocklists and static review often lag the real attack surface. Practitioners should map every install path to the code it can execute, not the package name it appears to install.

From our research:

• The August LiteLLM follow-on reporting mapped the compromise to 434,000 CI/CD pipelines, showing how a short malicious package window can create a long response tail, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• A separate finding from our research shows attackers attempt access within 17 minutes on average after AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
• From our research: For the related governance problem of AI agent access, only 52% of companies can track and audit the data their AI agents access, according to AI Agents: The New Attack Surface report.

What this signals

Install-time compromise expands the identity perimeter. Developer tooling, package managers, and notebook platforms now need the same trust boundaries that identity teams apply to privileged access. The practical shift is toward ephemeral credentials, tighter secret scoping, and controls that assume code can execute before review.

Package governance and NHI governance are converging. Once a malicious dependency can reach tokens or service keys, the incident is no longer only about software integrity. It becomes a non-human identity lifecycle problem because those secrets should be discoverable, revocable, and auditable as identities, not just as configuration values.

When the operational stack includes Jupyter, CI/CD, and code install hooks, the fastest way to reduce exposure is to shrink the credential footprint available during build and extension management. That makes secret segmentation and short-lived access a first-order resilience control, not an afterthought.

For practitioners

• Block install-time execution paths Review Ruby and Python package workflows for hooks such as extconf.rb, setup-time logic, and build helpers, then disable or isolate them where the business model allows. Treat installation as code execution, not passive delivery, and record which developer groups still require those paths.
• Test notebook policy bypasses directly Validate JupyterLab and JupyterHub controls against canonical and non-canonical package names, alternate API routes, and lockfile edge cases. Confirm that blocklists and plugin locks enforce the same result across the UI and backend APIs.
• Rotate exposed credentials as a supply chain response When a malicious package or extension is suspected, rotate CI/CD tokens, cloud keys, and developer secrets immediately rather than waiting for confirmation of use. Tie that rotation to a documented incident workflow so compromised identities are invalidated before reuse.
• Separate build trust from runtime trust Reduce the number of environments that can both install dependencies and access privileged secrets. Use scoped credentials, ephemeral build access, and strict environment segmentation so a package incident does not automatically become a production identity incident.

Key takeaways

• StubMaker shows that package installation can be an execution channel, not just a delivery mechanism.
• The measurable blast radius comes from secret exposure and pipeline reach, not only from the malicious package itself.
• Teams should treat install-time hooks, notebook policy bypasses, and credential rotation as a single governance problem.

Key terms

• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Extension-Manager Bypass: A failure in policy enforcement where a platform’s controls can be avoided through alternate paths, non-canonical naming, or inconsistent API handling. In practice, the system appears to block unapproved software while still allowing it to be installed or activated.
• Parser-Execution Trust Gap: A mismatch between how software interprets text and how it authorizes runtime actions. Security teams should care about this gap because formatting, encoding, or parsing behaviour can change the effective policy decision and allow dangerous commands to slip past intended guardrails.
• Credential Response Tail: The period after an initial compromise during which exposed secrets, tokens, and keys remain usable and drive continued risk. Even if the malware is removed quickly, the incident can continue until every affected identity is rotated, revoked, and verified as inactive.

What's in the full report

Corgea's full briefing covers the operational detail this post intentionally leaves for the source:

• Line-by-line breakdown of the StubMaker extconf.rb execution chain and the Windows infostealer loader path.
• CVE context for the JupyterLab extension-manager bypasses and the specific API paths involved.
• The follow-on LiteLLM exposure analysis behind the 434,000 CI/CD pipeline estimate and related credential-response implications.
• Weekly briefing context for the excluded stories, including how the team distinguishes direct compromise from downstream exposure.

👉 The full Corgea briefing covers the attack mechanics, affected surfaces, and remediation context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to operational security across modern environments.