# VS Code Vulnerability Enables One-Click GitHub Token Theft — Patched After Public Disclosure


A critical vulnerability in Visual Studio Code has exposed developers to a novel attack vector that allows threat actors to steal GitHub access tokens with a single user interaction. Security researcher Ammar Askar disclosed the vulnerability publicly on June 2, 2026, just one hour after notifying GitHub's security team, prompting Microsoft to release a patch within 24 hours. The incident highlights growing tensions in the vulnerability disclosure ecosystem and raises questions about responsible security research practices.


## The Threat


The vulnerability represents a significant risk to developers who use github.dev, the lightweight web-based version of VS Code that runs directly in the browser. An attacker exploiting this flaw can craft a malicious Jupyter notebook that, when opened on github.dev, automatically installs an unauthorized browser extension that silently exfiltrates the victim's GitHub authentication token.


The scope of compromise is severe:


  • Full repository access: Stolen tokens grant attackers complete read and write permissions to all repositories the victim can access, including private repositories containing proprietary code, credentials, and sensitive business logic
  • Supply chain implications: An attacker gaining access to a developer's token could inject malicious code into repositories, potentially affecting downstream projects and users
  • Lateral movement: Compromised tokens can serve as an entry point for broader attacks against an organization's development infrastructure
  • Minimal user interaction required: The attack triggers automatically when a user clicks a link to the malicious notebook, requiring no technical knowledge to exploit

    • ## Technical Details


    The attack chain leverages the unique capabilities of github.dev and browser-based keystroke simulation to bypass normal security controls. Here's how the exploit works:


    Attack Vector: Jupyter Notebook Weaponization


    The attacker creates a specially crafted Jupyter notebook file containing hidden malicious code. This notebook is hosted on a web server and linked to a github.dev environment through a carefully constructed URL.


    Keystroke Simulation and Extension Installation


    When the victim clicks the malicious link and opens github.dev, the embedded code simulates keyboard inputs to programmatically trigger the VS Code extension installation dialog. Rather than requiring manual configuration, the attack automates the entire process—the victim sees a permission prompt asking if an extension should be allowed access, but only if github.dev hasn't been used previously on their machine.


    Token Exfiltration


    Once installed, the malicious extension gains access to the victim's GitHub authentication token stored in VS Code. The extension silently exfiltrates this token to an attacker-controlled server, providing the threat actor with the same level of access as the legitimate user.


    Desktop Impact


    While the web-based attack is seamless, the vulnerability also affects VS Code's desktop version. However, exploitation requires additional user interaction, making desktop-based attacks less practical. Microsoft had not released a patch for the desktop version as of early June, according to the researcher.


    ## Background and Context


    This disclosure emerged from a contentious history between Askar and Microsoft regarding vulnerability handling. The researcher revealed that he had previously reported a VS Code vulnerability to Microsoft, only to have the company patch it silently without providing any public credit or acknowledgment to the discoverer. This experience shaped his decision to handle the current disclosure differently.


    Askar's approach—publishing full technical details and proof-of-concept code without advance vendor notification—has become increasingly controversial in the security research community. The researcher gave GitHub's security team approximately one hour of notice before making the vulnerability public, a practice that deviates from industry-standard responsible disclosure guidelines, which typically allow vendors 90 days to develop and release patches before public disclosure.


    This incident reflects a broader pattern of escalating tensions:


    In recent weeks, multiple researchers have disclosed Microsoft product vulnerabilities without proper advance notification. Most notably, researchers operating under the aliases "Chaotic Eclipse" and "Nightmare Eclipse" publicly released proof-of-concept exploits for several zero-day vulnerabilities after disagreements with Microsoft during the disclosure process. These vulnerabilities—including RedSun, UnDefend, BlueHammer, YellowKey, MiniPlasma, and GreenPlasma—some have already been exploited in active attacks.


    Microsoft responded to these disclosures with legal threats against researchers who publicly dump zero-days without notification, but later attempted to calm community concerns following significant backlash from security professionals who argued that the company's disclosure policies were unreasonably restrictive.


    ## Implications for Organizations


    Developer Targeting


    Developers represent high-value targets for sophisticated threat actors. A compromised GitHub token provides attackers with access equivalent to the developer's account, enabling them to modify code, steal intellectual property, or implant backdoors in active projects.


    Supply Chain Risk


    Organizations that depend on open-source projects developed by affected developers face indirect risk. Attackers could inject malicious code into public repositories, affecting thousands of downstream users and organizations.


    Enterprise Development Infrastructure


    Within larger organizations, developer tokens often have broad permissions across multiple repositories and may be integrated with CI/CD pipelines, infrastructure-as-code systems, and deployment automation—creating cascading compromise potential.


    ## Recommendations


    Immediate Actions


  • Review GitHub token usage: Organizations should audit which GitHub tokens are in use, their scope of permissions, and where they're stored
  • Rotate sensitive tokens: If your development team uses VS Code or github.dev, consider rotating GitHub personal access tokens and regenerating any organization-level credentials
  • Update VS Code: Install the latest version of VS Code, which includes the security patch released on June 3
  • Browser security review: Check browser extensions for any unfamiliar or unauthorized additions

    • Medium-Term Mitigations


  • Implement fine-grained permissions: GitHub's fine-grained personal access tokens allow you to limit token scope to specific repositories rather than granting broad access
  • Use GitHub Codespaces safely: If possible, prefer GitHub Codespaces (the managed development environment) over github.dev for sensitive work, as it provides additional isolation
  • Monitor for unusual activity: Enable GitHub audit logs and review for any suspicious commits, repository modifications, or access patterns
  • Security awareness training: Educate development teams about the risks of opening untrusted notebook files and the importance of verifying extension sources

    • Long-Term Strategy


  • Zero-trust for developer access: Treat developer tokens with the same rigor as production credentials—implement secrets scanning, rotation policies, and access logging
  • Code review processes: Maintain robust code review practices to catch malicious commits that might slip through compromised developer accounts

    • ## HackWire Analysis


    The VS Code vulnerability incident illustrates a critical inflection point in vulnerability disclosure practices. Askar's decision to disclose without advance vendor notification wasn't arbitrary—it was a deliberate response to what he perceived as unfair treatment by Microsoft. Yet his approach creates a troubling precedent: if every researcher with a legitimate grievance against a vendor defaults to zero-day publication, the entire disclosure ecosystem breaks down. Vendors stop accepting reports, researchers lose leverage for attribution and collaboration, and the window for attackers to develop exploits before patches reach users expands dramatically.


    What makes this case particularly concerning is that Askar's frustration is *legitimate*. Microsoft's silent patching of his previous report without attribution is poor practice. The company's subsequent legal threats against researchers have chilled responsible disclosure conversations. But the solution to those problems isn't faster zero-day dumps—it's better disclosure policies from major vendors.


    The real story here isn't the vulnerability itself; it's that the largest software companies still haven't figured out how to handle researchers with professionalism and respect. Until Microsoft (and other major vendors) commit to transparent, fair, credited vulnerability handling, expect more researchers to follow Askar's path. And when that happens at scale, everyone loses—especially developers who should be able to trust their tools.


    — 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/)