{"id":16317,"date":"2026-06-04T01:41:34","date_gmt":"2026-06-04T01:41:34","guid":{"rendered":"https:\/\/newestek.com\/?p=16317"},"modified":"2026-06-04T01:41:34","modified_gmt":"2026-06-04T01:41:34","slug":"hole-in-githubs-browser-based-vscode-editor-could-lead-to-stolen-token","status":"publish","type":"post","link":"https:\/\/newestek.com\/?p=16317","title":{"rendered":"Hole in GitHub\u2019s browser-based VSCode editor could lead to stolen token"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
<\/div>\n<\/section>\n

A vulnerability in GitHub\u2019s browser-based VSCode editor could lead to the theft of a developer\u2019s token under certain circumstances, says a researcher.<\/p>\n

The issue, revealed this week in a blog by Ammar Askar<\/a>, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher\u2019s allegation that, because Microsoft doesn\u2019t treat bug discoveries seriously, he can justify giving it short notice before openly publishing vulnerabilities he finds.<\/p>\n

First, the bug: Users of github.com<\/em> may not realize it, but when they are on any repository, they can shift to github.dev<\/em> and its browser-based version of VSCode just by changing the URL. <\/p>\n

Why do this? Because the browser instance of VSCode is pretty powerful, Askar says in his blog. \u201cYou can view all the files in the repo (even if it\u2019s a private one), you can send out pull requests, and even make commits.\u201d<\/p>\n

Rob Enderle<\/a>, a IT consultant who heads the Enderle Group, agrees that jumping into VSCode this way is \u201can incredibly useful tactical tool for quick tasks. By just hitting the \u2018.\u2019 key in any GitHub repo, you instantly get a browser-based VS Code interface without having to clone gigabytes of data locally. It\u2019s perfect for rapid PR reviews, quick documentation edits, or navigating code on the fly without breaking your workflow. Just keep in mind that it runs entirely in the browser sandbox; there\u2019s no compute backend, no terminal, and no code execution.\u201d<\/p>\n

For any heavy lifting or actual compiling, he added, the developer will still need the raw compute of a local workstation, or a full cloud environment like Codespaces.<\/p>\n

The problem, Askar says, is that this functionality is achieved by github.com<\/em> POSTing over an OAuth token to github.dev<\/em> that allows it to interact with GitHub on your behalf. \u201cThe token is\u00a0not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to,\u201d he wrote in the blog.<\/p>\n

\u201cThe presence of this token, and the fact that this web app is running almost the entire brunt of VSCode\u2019s million line Typescript codebase, makes it a great target for anyone looking into VSCode bugs,\u201d he wrote.<\/p>\n

The exploit<\/h2>\n

Askar said that a threat actor could install an extension in a repository using a Jupyter notebook, a web application for creating and sharing computational documents that has the ability to install a malicious local workspace extension while skipping the publisher trust check. In his proof of concept, Askar said that once his payload runs, the newly installed extension will grab the GitHub API token, run a query to get the private repos the developer has access to, and then print out the replies and the token.<\/p>\n

This vulnerability also exists in the desktop version of VSCode, Askar said, though it\u2019s harder to exploit, since a threat actor would need to convince the victim to clone their repo and open the notebook containing the webview script payload. \u201cOf course,\u201d he added, \u201cif you [the hacker] had some other XSS [cross-site scripting attack] in a webview that you can get a victim to open, you get effectively full RCE [remote code execution] on their computer.\u201d<\/p>\n

In an email, he said this vulnerability was \u201cabout as serious as it gets. Any website on the internet could have redirected you to a github.dev<\/em> link that could have provided an attacker a token to read and modify your code repos. If one could convince the maintainer of a popular software project to click a link, they could have made whatever modifications they wanted to their project.\u201d<\/p>\n

This means, said Enderle, \u201cwe have to start treating developer endpoints with strict, isolated, zero-trust parameters, because we clearly cannot rely on vendor complacency to protect us.\u201d<\/p>\n

This issue reinforces the point that you should never follow any links unless you know exactly where they will take you, added\u00a0Dwayne McDaniel<\/a>, principal\u00a0developer\u00a0advocate\u00a0at\u00a0GitGuardian.<\/p>\n

Short notice<\/h2>\n

Here\u2019s where things get complicated. Because of an unhappy experience when disclosing a previous VSCode vulnerability to Microsoft \u2014 the bug was fixed, but Askar wasn\u2019t given credit \u2014 this time he only gave GitHub one hour notice that this new discovery was going to be published. Microsoft applied what Askar calls a \u201cstopgap\u201d fix<\/a> by adding a confirmation when a developer opens notebooks in web VSCode, and by not allowing the trusted publisher<\/em> requirement to be skipped by commands.<\/p>\n

[Related content: When responsible disclosure becomes unpaid labor<\/a>]<\/strong><\/p>\n

An ethical question<\/h2>\n

Askar\u2019s short notice raises an ethical question: How far in advance should a responsible researcher give notice to a vendor about a vulnerability before publicly revealing it?<\/p>\n

These days, most infosec pros agree that notice must<\/em> be given, or else a threat actor can quickly exploit a hole. Not only that, but the researcher risks damage to their reputation if reasonable notice isn\u2019t given. Experienced researchers often give vendors at least 30 days to create and distribute a patch.<\/p>\n

For their part, vendors often create bug bounty programs, or partner with bug bounty programs, to reward researchers for their work. Unfortunately, some vendors don\u2019t always credit researchers, or downplay the damage a vulnerability can cause. In fact, last month Microsoft and a prominent cybersecurity researcher got into a public spat<\/a> about one such alleged incident.<\/p>\n

An imbalance of power<\/h2>\n

Asked for comment about Askar\u2019s most recent discovery, a Microsoft spokesperson said, \u201cwe value the critical role that the security research community plays in strengthening the security of our products, services, and the broader technology ecosystem. While independent researchers determine when and how to publish their findings, we remain committed to rapidly assessing reported issues, mobilizing the appropriate engineering and security response resources, and delivering mitigations, guidance, and protections as quickly as possible to help safeguard our customers.\u201d<\/p>\n

[Related content: Is the vulnerability disclosure process glitched?<\/a>]<\/strong><\/p>\n

There is a balance between coordinating disclosure with a software vendor (CVD) and full disclosure, Askar told us. But, he added, there\u2019s an imbalance of power. \u201cA security researcher can pour countless hours into an issue, ensuring they develop a good proof of concept and provide all the steps to recreate the issue. With this, they hope to at least get an acknowledgement for their efforts, which they can use to further their security track record or, in the best case, a monetary bounty reward.\u201d<\/p>\n

However, he added, \u201cIf security vendors don\u2019t adhere to their side of the bargain, public disclosure is one of the few options security researchers have (if they don\u2019t want to sit on their vulnerabilities or sell them on the black market). It forces the vendor to acknowledge the security issue publicly and usually leads to a much faster resolution than any private communication would.\u201d<\/p>\n

This, said Enderle, creates problems for enterprises: \u201cWhen vendor bureaucracy penalizes responsible disclosure, it alienates the security community and forces public zero-day drops, ultimately leaving enterprise customers holding the bag.\u201d<\/p>\n

This article originally appeared on InfoWorld<\/a>.<\/em><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

A vulnerability in GitHub\u2019s browser-based VSCode editor could lead to the theft of a developer\u2019s token under certain circumstances, says a researcher. The issue, revealed this week in a blog by Ammar Askar, has apparently been already addressed by GitHub owner Microsoft. But it raises a questions about both DevOps security, and about the researcher\u2019s allegation that, because Microsoft doesn\u2019t treat bug discoveries seriously, he… <\/p>\n

Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-16317","post","type-post","status-publish","format-standard","hentry","category-uncategorized","is-cat-link-borders-light is-cat-link-rounded"],"_links":{"self":[{"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/posts\/16317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=16317"}],"version-history":[{"count":0,"href":"https:\/\/newestek.com\/index.php?rest_route=\/wp\/v2\/posts\/16317\/revisions"}],"wp:attachment":[{"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=16317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=16317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/newestek.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=16317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}