Notepad++ supply chain attack shows update trust is the weak link

At a glance

What this is: Anomali's weekly cyber watch highlights a Notepad++ supply chain compromise that abused update trust, hosting access, and stolen internal credentials to deliver malicious payloads.

Why it matters: It matters because software update paths, host credentials, and trusted binaries can become identity-adjacent attack surfaces that undermine both endpoint security and NHI governance.

By the numbers:

• Researchers identified three distinct infection chains deployed from July through October 2025, targeting approximately a dozen machines.
• The attackers retained stolen credentials to internal services enabling continued traffic manipulation until December 2, 2025.

👉 Read Anomali's cyber watch analysis of the Notepad++ supply chain attack

Context

Notepad++ supply chain attack risk is fundamentally about trust in the software delivery path. When an attacker can compromise hosting infrastructure, intercept update traffic, and reuse stolen credentials, patching alone no longer defines the defense.

This incident also has an identity angle because the campaign depended on credentialed access to internal services and on trusted execution paths that behaved like legitimate software updates. That intersection is where endpoint security, privileged access governance, and NHI controls meet.

The starting position is atypical in scale but typical in pattern: a small number of targets does not reduce the significance of a supply chain compromise when the delivery mechanism is broadly reusable.

Key questions

Q: What breaks when software update trust is compromised in a supply chain attack?

A: When update trust is compromised, normal patching workflows become a delivery mechanism for malicious code. Signed packages, automatic updaters, and routine maintenance channels all lose reliability if attackers can alter the path, the payload, or the validation step. Defenders then have to assume that the software source, not just the endpoint, is part of the incident.

Q: Why do stolen service credentials make supply chain incidents harder to contain?

A: Stolen service credentials let attackers keep manipulating infrastructure after the first compromise is found. That extends the incident beyond the original host and forces teams to revoke access, rotate secrets, and verify every dependent service. In practice, the credential layer can outlast the initial server compromise by days or weeks.

Q: What do security teams get wrong about malicious software updates?

A: Teams often focus on the payload and miss the trust path that delivered it. A malicious installer is only possible if hosting, routing, or validation controls fail first. The correct response is to monitor updater behaviour, enforce signature checks at execution, and treat update credentials as privileged access.

Q: Who is accountable when an update infrastructure breach exposes users to malicious code?

A: Accountability usually spans the software publisher, the hosting or distribution provider, and the internal teams that own update credentials and validation controls. NIST CSF and NIST 800-53 both point to clear asset ownership, access control, and monitoring responsibilities. If those lines are unclear, remediation slows and exposure lasts longer.

Technical breakdown

How compromised update infrastructure becomes a delivery channel

Software update ecosystems are trusted because they sit inside normal maintenance workflows. If attackers compromise a hosting provider, update server, or distribution path, they can redirect clients to malicious payloads while preserving the appearance of legitimacy. In this case, selective interception mattered more than broad malware volume. The campaign used a controlled delivery path, which reduces noise and improves operational stealth. Signed binaries and installers only help if validation is enforced at every stage, including download, signature checking, and downstream execution. Without that chain of trust, update mechanisms become an attack surface rather than a defense.

Practical implication: verify update authenticity at download and execution time, not just at publish time.

Why stolen internal credentials extend supply chain compromise

Once attackers lose direct access to compromised infrastructure, internal credentials can preserve the operation. That is especially dangerous when those credentials reach administrative or service interfaces that were never intended for broad external use. In this incident, stolen credentials allowed continued manipulation after the host changed, showing how access persistence can outlast the original foothold. This is a classic identity problem hidden inside a software compromise: the malicious payload is only one phase, while credential reuse keeps the channel open. For defenders, host hardening is incomplete if internal service credentials remain valid and unmonitored.

Practical implication: rotate and revoke service credentials tied to build, hosting, and update workflows immediately after infrastructure compromise.

What malware packing choices reveal about detection gaps

Attackers frequently wrap payloads inside legitimate installers, sideload trusted binaries, or rotate command-and-control endpoints to evade static detection. Here, the use of NSIS installers, legitimate updater execution, and changing infrastructure reduced the value of simple hash and domain blocking. The technical lesson is that detection must follow behaviour, not file reputation alone. When the same delivery chain can swap payloads, downloaders, and infrastructure, defenders need layered telemetry from endpoint, network, and update verification logs. Otherwise, the malicious update looks too much like normal administration.

Practical implication: build behavioural detections around updater abuse, not just signatures for known payloads.

Threat narrative

Attacker objective: The objective was to deliver trusted-looking malicious updates that establish persistent access on selected victims without triggering broad detection.

1. Entry occurred through compromise of Notepad++'s shared hosting provider and interception of update traffic destined for users.
2. Escalation was sustained by stolen credentials to internal services, which allowed the attackers to continue manipulating delivery after direct host changes.
3. Impact came from selectively delivered malicious installers and backdoors that infected targeted systems while preserving operational stealth.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Update trust is now an identity and access problem, not just a software integrity problem. The Notepad++ case shows that compromise did not depend on a single exploit path. It depended on trusted infrastructure, stolen internal credentials, and execution through legitimate update tooling. That combination exposes a governance gap that sits between endpoint security and identity control. Practitioners should treat software delivery credentials, hosting access, and updater trust as part of the access model.

Standing credentials in update ecosystems create a long exposure window. Once attackers retain internal credentials, the original infrastructure event stops being the end of the incident. The relevant failure mode is credential persistence after infrastructure compromise, which keeps update traffic vulnerable even after visible remediation. That is why NHI governance must cover build systems, hosting services, and distribution accounts, not only application-facing secrets. Teams should assume persistence unless credentials are explicitly rotated and access paths revalidated.

Selective targeting lowers noise but increases confidence in attacker tradecraft. The campaign hit a small number of systems, but that does not reduce its significance. Selective filtering, rotating infrastructure, and multiple infection chains indicate a mature operator that can adjust delivery to avoid broad telemetry. For defenders, that means telemetry correlation across update validation, endpoint execution, and identity events matters more than raw alert volume. The practitioner conclusion is simple: low-volume supply chain abuse still warrants high-priority governance.

Trust-boundary collapse is the right named concept for this incident. The attack worked because the boundary between legitimate update trust and attacker-controlled delivery had already collapsed. Once that boundary fails, signature checks, hosting reputation, and normal patch workflows all become unreliable indicators. This is precisely where OWASP Non-Human Identity Top 10 concerns intersect with software supply chain governance, because service credentials and machine identities often guard the update path. Teams should govern the trust boundary as a security control in its own right.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 52 NHI Breaches Analysis shows how identity and secret exposure repeatedly become the entry point for wider compromise.

What this signals

The operational signal for practitioners is that update trust, secret handling, and privileged automation should now be reviewed as one control surface. When a supply chain incident can continue through stolen internal credentials, the programme gap is not just patch speed, but the absence of a disciplined credential lifecycle for release and hosting systems.

Trust-boundary collapse: this is the pattern teams should watch for when a legitimate delivery mechanism becomes attacker-controlled. The most useful response is to pair endpoint telemetry with identity and access monitoring so that unusual updater behaviour, service account reuse, and redirect traffic can be correlated before the compromise spreads.

The broader lesson is that supply chain defence depends on more than vendor assurance. Teams that can inventory update credentials, verify execution-time signatures, and isolate release pathways will be better positioned to contain the next low-volume, high-trust compromise.

For practitioners

• Inventory update-path credentials Map every credential, token, and internal account that can publish, host, or redirect software updates. Include shared hosting, internal service accounts, and automation identities used by release tooling. Flag any credential that can change delivery content or routing as high risk.
• Enforce signature validation at execution time Require downloaded installers and packages to be validated on the endpoint before first execution, not only at source publication. Validate certificate chains, signature status, and package metadata in the same workflow that launches the software.
• Rotate internal service credentials after infrastructure compromise If a hosting provider or update server is breached, treat all related internal service credentials as potentially exposed. Revoke tokens, rotate secrets, and reissue service access before returning the update path to production.
• Detect updater abuse through behaviour telemetry Create detections for unusual updater parent-child processes, unexpected installer execution, and redirects to non-standard infrastructure. Combine endpoint, DNS, and proxy logs so malicious update traffic can be distinguished from legitimate maintenance activity.

Key takeaways

• This supply chain attack succeeded because trusted update infrastructure and internal credentials were both exposed.
• The campaign demonstrates how a small number of targeted infections can still indicate a high-confidence compromise of the delivery path.
• Practitioners should treat update credentials, signature validation, and behaviour-based detection as a single governance problem.

Key terms

• Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
• Update Path Trust: Update path trust is the assumption that software downloads, installers, and auto-updaters are legitimate because they come from an expected source. In practice, this trust must be continuously verified through signatures, routing integrity, and access control over release infrastructure.
• Service Credential Persistence: Service credential persistence happens when stolen tokens, keys, or accounts remain valid after an infrastructure compromise is discovered. It extends attacker access beyond the initial breach point and often keeps management or delivery channels open until every credential is rotated.
• Trusted Binary Abuse: Trusted binary abuse is the use of legitimate software, installers, or system utilities to execute malicious activity. Because the file or process looks normal, detection is harder and defenders must rely on behavioural signals instead of reputation alone.

What's in the full analysis

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

• Timeline detail on the hosting compromise, credential theft, and the dates on which the attackers lost and retained access.
• The three infection chains and the specific payload-delivery mechanisms used in each chain.
• The version and verification changes Notepad++ applied after the incident, including certificate and signature validation.
• The published indicators of compromise that security teams can use for endpoint and traffic review.

👉 The full Anomali post covers the attack timeline, infection chains, and detection details.

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 gives security practitioners a practical foundation for governing privileged access paths that support software delivery and automation.