Microsoft is adding a mandatory two-hour buffer to its Visual Studio Code auto-update mechanism, a move designed to give security teams and automated scanning tools a critical window to catch malicious code before it reaches millions of developer machines.
A Pause Before Deployment
The change, introduced in VS Code 1.123 and reported by The Hacker News on 8 June 2026, means that when a new version of a VS Code extension is published to the marketplace, it will not be automatically pushed to users for at least two hours. Previously, extensions with auto-update enabled would begin propagating to users almost immediately after publication.
"When automatic updates are enabled, new versions are auto-updated two hours after they are published, adding an extra layer of protection," Microsoft stated in its announcement.
The delay specifically targets the threat of compromised or weaponised extensions reaching developers en masse through the marketplace's auto-update pipeline — a form of software supply chain attack that has grown increasingly common across open-source ecosystems.
Why It Matters
VS Code has become one of the most widely used code editors in the world, powering development workflows across organisations of every size. Its extension marketplace hosts tens of thousands of add-ons that extend the editor's capabilities, from language support to cloud integration. That popularity also makes it a high-value target for attackers seeking to compromise developer environments at scale.
The danger is well documented. The 2025 xz-utils backdoor incident, in which a malicious actor embedded a supply chain compromise deep within a widely trusted open-source library, demonstrated how a single tainted update can cascade across the software ecosystem. By introducing a two-hour delay, Microsoft is effectively creating a detection window — a period during which security vendors, automated analysis tools, and community reviewers can scrutinise newly published extension code before it is silently installed on developer systems.
The approach represents a philosophical shift. Rather than treating update speed as a feature to maximise, Microsoft is now treating a brief pause as a security mechanism in its own right.
A Foundational Step, Not a Complete Solution
Security researchers have generally welcomed the move but note that a two-hour delay alone cannot address every supply chain threat scenario. A determined attacker could, for instance, publish a benign version and introduce a time-delayed payload in a later update, or craft code designed to evade automated scanning during the buffer window.
The effectiveness of the delay will ultimately depend on what happens during those two hours. If security vendors and community monitoring efforts coordinate to actively analyse new extensions within that window, the buffer becomes a meaningful defence layer. If the time passes without scrutiny, the delay becomes little more than a speed bump.
Several open questions remain. Microsoft has not yet detailed how emergency security patches for extensions will be handled — whether a verified bypass mechanism will exist for critical updates. Enterprise development teams, which often maintain internal vetting processes and CI/CD pipelines that depend on predictable update timing, may also need configurable policies to manage the delay according to their own security workflows.
The Broader Trend
The decision reflects a growing recognition among platform providers that distribution channels carry inherent security responsibilities. As developer tools become increasingly central to software production, the marketplaces and registries that serve them are becoming critical infrastructure demanding active defence measures.
For VS Code's vast user base — spanning individual developers, open-source contributors, and enterprise teams — the practical impact should be minimal. A two-hour delay on automatic updates is unlikely to disrupt development workflows, but it could make a meaningful difference in catching compromised extensions before they cause widespread harm.
The move is likely to prompt similar discussions across other developer tool ecosystems, where the balance between update convenience and supply chain security remains an active area of debate.
微軟正為其 Visual Studio Code 自動更新機制增加一個強制性的兩小時緩衝期，此舉旨在為安全團隊和自動化掃描工具提供一個關鍵時間窗口，以便在惡意程式碼到達數百萬開發者機器之前將其截獲。
部署前的暫停
此項變更隨 VS Code 1.123 版本引入，根據 The Hacker News 於 2026 年 6 月 8 日的報導，這意味著當新的 VS Code 擴充功能版本發佈到應用程式商店時，它至少在兩個小時內不會自動推送給使用者。此前，啟用了自動更新的擴充功能在發佈後幾乎會立即開始向使用者傳播。
「當啟用自動更新時，新版本會在發佈兩小時後自動更新，增加額外一層保護，」微軟在其公告中表示。
此次延遲專門針對被入侵或武器化的擴充功能通過應用程式商店的自動更新 pipeline 大規模傳播給開發者的威脅——這是一種在開源生態系統中日益普遍的軟體供應鏈攻擊形式。
為何重要
VS Code 已成為世界上最廣泛使用的程式碼編輯器之一，為各種規模組織的開發工作流程提供動力。其擴充功能應用程式商店擁有數萬個附加元件，用於擴展編輯器的功能，從語言支援到雲端整合。這種普及性也使其成為攻擊者尋求大規模入侵開發者環境的高價值目標。
其危險性已有充分記錄。2025 年的 xz-utils 後門事件，其中一個惡意行為者在一個廣受信賴的開源函式庫中深植了供應鏈入侵，證明了一個受污染的更新如何能在軟體生態系統中連鎖反應。通過引入兩小時延遲，微軟實際上創建了一個偵測窗口——在這段時間內，安全供應商、自動化分析工具和社群審查人員可以在擴充功能被靜默安裝到開發者系統之前，仔細檢查新發佈的擴充功能程式碼。
這種方法代表了一種理念的轉變。微軟現在不再將更新速度視為需要最大化的功能，而是將短暫的暫停本身視為一種安全機制。
基礎步驟，非完整解決方案
安全研究人員普遍歡迎此舉，但指出僅靠兩小時的延遲無法解決所有供應鏈威脅場景。例如，一個堅定的攻擊者可以先發佈一個良性版本，然後在後續更新中引入延時載荷，或者精心設計程式碼以在緩衝窗口期間逃避自動掃描。
延遲的有效性最終取決於這兩個小時內發生了什麼。如果安全供應商和社群監控工作協調一致，在該窗口期內積極分析新擴充功能，那麼緩衝期就成為了一個有意義的防禦層。如果這段時間未經仔細檢查，那麼延遲就僅僅成為一個減速帶。
仍存在幾個未解之謎。微軟尚未詳細說明如何處理擴充功能的緊急安全修補——是否會存在用於關鍵更新的驗證旁路機制。企業開發團隊通常維護著內部審查流程和依賴可預測更新時機的 CI/CD pipeline，他們可能也需要可配置的策略來根據自身安全工作流程管理延遲。
更廣泛的趨勢
這一決定反映出平台供應商越來越認識到分發管道承擔著固有的安全責任。隨著開發者工具在軟體生產中變得越來越核心，為其服務的應用程式商店和 registry 正在成為需要主動防禦措施的關鍵基礎設施。
對於 VS Code 龐大的用戶群——包括個人開發者、開源貢獻者和企業團隊——實際影響應該很小。自動更新兩小時的延遲不太可能打亂開發工作流程，但它可能在及時發現受入侵的擴充功能、防止其造成大範圍損害方面，產生實質性的影響。
此舉可能會在其他開發者工具生態系統中引發類似的討論，在這些生態系統中，更新便利性與供應鏈安全之間的平衡仍然是一個活躍的辯論領域。