# VS Code Implements Two-Hour Extension Auto-Update Delay to Combat Supply Chain Threats


Microsoft brings ecosystem-wide defense pattern to developer IDEs as supply chain attacks accelerate across package registries


Microsoft has announced a significant security enhancement to Visual Studio Code (VS Code), introducing a mandatory two-hour delay before extensions automatically update to newer versions. The measure, available starting in VS Code 1.123, represents a critical shift in how development environments approach the growing threat of compromised or malicious package releases.


The change reflects an industry-wide recognition that the window between a malicious package's publication and its removal by registry maintainers is a dangerous liability — one that attackers actively exploit to inject malware into developer workflows.


## The Threat: A Widening Attack Surface


Supply chain attacks targeting developers have evolved into one of the most effective and profitable attack vectors in cybersecurity. Unlike end-user malware, which requires broad distribution and often triggers user suspicion, compromised developer tools move silently through enterprise networks, often automatically executed by CI/CD pipelines.


VS Code extensions exemplify this risk. Extensions run with elevated privileges within the IDE itself, granting them access to:


  • Source code being edited
  • Environment variables and secrets
  • SSH keys and authentication tokens
  • File system traversal
  • Network access to transmit stolen data

    • When an attacker gains control of an extension — either through account compromise, social engineering, or outright supply chain takeover — the blast radius extends immediately to every developer using that extension. The attack happens before most organizations are even aware the extension has been compromised.


    Previous incidents underscore the severity:


  • OpenAI Codex tokens stolen via a malicious codexui-android npm package that automatically harvested authentication credentials
  • Marimo CVE exploitation used for post-exploitation attacks against developers
  • GlassWorm takedown disrupted an entire developer-focused supply chain attack infrastructure
  • Miasma campaign compromised Red Hat npm packages with credential-stealing worms

    • Each of these incidents followed the same pattern: publish → auto-update → exploit → detect → remove. The delay between steps one and four is the kill zone attackers exploit.


    ## Background and Context: An Ecosystem-Wide Movement


    Microsoft's decision to implement this delay doesn't exist in isolation. Over the past 12 months, package managers across multiple ecosystems have adopted similar defensive postures:


    | Ecosystem | Tool | Feature | Available Since |

    |-----------|------|---------|-----------------|

    | Ruby | Bundler | Configurable opt-in cooldown | 4.0.13 (June 2026) |

    | JavaScript | npm | min-release-age flag | v11.10.0+ |

    | JavaScript | pnpm | minimumReleaseAge | 10.16+ |

    | JavaScript | Bun | minimumReleaseAge | 1.3+ |

    | JavaScript | Yarn | npmMinimalAgeGate | Berry 4.10.0+ |

    | IDEs | VS Code | Mandatory 2-hour delay | 1.123 |


    RubyGems just added this feature to Bundler 4.0.13, mere days before Microsoft's announcement. The timing is not coincidental — it reflects consensus among major stakeholders that installation delays are now essential security infrastructure.


    ## Technical Details: How the Delay Works


    VS Code's implementation is straightforward but effective:


    The Mechanism:

  • When automatic updates are enabled (the default for most users), new extension versions are no longer installed immediately upon publication
  • A two-hour window begins when an extension version is published to the VS Code Marketplace
  • After two hours elapse, the extension automatically updates unless the user has manually updated it
  • Users can still force immediate updates via the "Update" button in the Extensions panel at any time

    • Visual Feedback:

  • When extensions have pending updates, the details view displays the reason for the delay
  • The expected automatic update time is shown to the user
  • Transparency about *why* an update hasn't occurred reduces user confusion and support burden

    • Trusted Publisher Exemption:

    Microsoft, GitHub, and OpenAI extensions bypass the two-hour delay entirely, receiving immediate updates. This reflects a risk-based approach: while no organization is immune to compromise, Microsoft's internal security controls and OpenAI's development practices represent a different threat profile than community-maintained extensions. This exemption also prevents delays from impacting critical tooling that Microsoft itself relies upon.


    ## How This Defends Against Supply Chain Attacks


    The two-hour delay operates on a simple but powerful principle: minimize the window during which malicious code can spread before detection and removal.


    Consider the attack timeline:


    1. Hour 0: Attacker publishes malicious version (e.g., version 2.5.1) after compromising extension author account

    2. Hours 0-2: The malicious version is available and could be installed, but automatic updates haven't fired yet

    3. Hour 0.5-1: First suspicious activity detected (telemetry, user reports, automated analysis)

    4. Hour 1-2: Extension is flagged, reviewed, pulled from marketplace

    5. Hour 2+: Automatic updates trigger, but the malicious version is already gone


    Critically, human defenders typically need 30-90 minutes to detect and respond to a supply chain incident. The two-hour delay aligns with human detection latency. It transforms the attack timeline from "publish → spread for days → detect → respond" into "publish → detect → remove → (update to safe version)."


    This is not perfect defense, but it substantially raises the cost and risk for attackers.


    ## Implications for Developers and Organizations


    For Individual Developers:

  • Extensions will update with a slight but noticeable delay (two hours)
  • The ability to force immediate updates remains for security patches or critical features
  • The trade-off is favorable: a two-hour delay on minor updates is preferable to installing credential-stealing malware

    • For Organizations:

  • IT teams should understand that VS Code extensions now have built-in delay protection
  • Organizations using trusted publishers (Microsoft, GitHub) will not see delays
  • Enterprises running custom or internal extensions should implement similar delays in their internal distribution mechanisms
  • Security teams should document this feature and ensure developers understand *why* updates are delayed

    • For Extension Developers:

  • Community extension developers will see a delay between publishing new versions and automatic deployment to users
  • Rapid iteration cycles may require user communication about phased rollouts
  • The transparency benefits security: if an extension author detects a vulnerability before the two-hour window closes, they can immediately communicate with users who can force an immediate update

    • ## The Broader Pattern: Minimum Age Gates Across All Ecosystems


    What's remarkable about the simultaneous adoption across RubyGems, npm, pnpm, Bun, and Yarn is that it reflects a fundamental shift in how the software industry views supply chain risk.


    For decades, the assumption was "newest = safest." Rapid automatic updates were treated as unambiguous security wins. But experience with supply chain attacks has inverted that logic: the newest version can be the most dangerous version.


    Minimum age gates work because:

  • They're asymmetric: If a package is legitimately updated, the two-hour delay is a minor inconvenience. If it's malicious, two hours is often enough time for defenders to detect and remove it.
  • They're low-friction: Unlike manual approval workflows, which add friction but often become rubber stamps, automatic updates with a delay require no human action in the normal case.
  • They're universal: They apply to all packages equally, preventing attackers from gaming exceptions or targeting under-monitored packages.

    • The cost of this defense — slight latency in critical security patches — is manageable because developers can still force immediate updates when they're aware of a genuine issue.


    ## Recommendations for Defenders


    Organizations serious about supply chain security should:


    1. Document and communicate the change to development teams, explaining the two-hour delay as a security feature, not a bug

    2. Consider extending delays to internal extension distribution if you maintain custom tooling

    3. Audit installed extensions to understand what extensions are in use and whether they come from trusted publishers

    4. Enable automatic updates if not already enabled — the two-hour delay only protects users with this setting active

    5. Establish an incident response process for extension compromise, recognizing that VS Code provides a limited time window to detect and warn users

    6. Monitor extension publishing activity in your organization if you develop extensions internally — detect unauthorized publishes immediately

    7. Review the settings in user VS Code instances to ensure automatic updates are enabled and configured appropriately


    ---


    ## HackWire Analysis


    The VS Code announcement represents a maturation of supply chain defense thinking. For years, "ship faster" and "always update" were treated as unconditional goods. But attackers have weaponized speed. The fastest delivery wins only if you're the attacker — for defenders, a brief pause is a lifeline.


    What's particularly notable is the cross-ecosystem coordination implicit in this timing. When npm, Bun, Yarn, pnpm, *and* VS Code all announce minimum age features within weeks of each other, it signals that major stakeholders have reached consensus: the attack surface has become unacceptable.


    The trusted publisher exemption reveals an important nuance in risk assessment. Microsoft, GitHub, and OpenAI face different internal scrutiny than community maintainers. While this creates a two-tier system, it reflects reality: not all package sources have equivalent defensive infrastructure. The decision to exempt trusted publishers while protecting users from unknown sources is pragmatic, not a security hole.


    What defenders should watch: this only works if adoption is universal. If half of developers or organizations opt for immediate updates to maintain developer experience, the two-hour window collapses. The true test will be whether this becomes transparent enough that developers don't feel the friction and become tempted to disable it.


    The implicit question behind this change is darker: we're now assuming that published packages *might be malicious by default,* and we're designing accordingly. That assumption should worry anyone building or depending on open-source tools. But VS Code's answer — trust but verify with a slight delay — may be the most pragmatic approach available.


    — *HackWire Editorial*


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)