SecurityWeek reported on June 4, 2026 that a Visual Studio Code and github.dev issue could allow a crafted Jupyter notebook to steal a GitHub access token. The original researcher post said that token could read and write repositories the user can access, including private repositories. Microsoft also merged a VS Code change on June 3 that added a confirmation step for certain browser-based notebook sessions and hardened the extension-install command path.
For many business owners, the immediate reaction is to file this under developer news. That is too narrow. Source-code access often controls websites, customer portals, automation scripts, reporting tools, integrations, internal apps, deployment files, and sometimes infrastructure configuration. If a vendor, consultant, MSP, or employee has broad GitHub access, a tool problem can become a business-control problem.
The business decision is about access, not just the bug
The practical question is not whether every owner should understand the VS Code webview model. The question is whether the business knows who can reach its code and what would happen if one of those accounts or tokens were exposed.
This matters most when development is handled outside the company. A web agency may manage the website repository. A software vendor may hold integration code. An MSP may keep scripts for device setup, backup jobs, or reporting. A part-time developer may still have access from a past project. In each case, the owner needs an inventory and an accountable person, not just a verbal assurance that the tools are patched.
What owners should ask
- Who has access to our GitHub, source-code, automation, or deployment repositories? Include employees, contractors, vendors, former vendors, and shared service accounts.
- Are browser-based coding tools such as github.dev allowed for company work? If yes, ask whether access is monitored and whether high-risk repositories are restricted.
- Are VS Code, extensions, and developer workstations managed? Ask how updates are applied, how untrusted extensions are blocked, and who approves exceptions.
- Can tokens be revoked quickly? The business should know who can revoke GitHub tokens, rotate secrets, and review audit logs after a suspected issue.
- Do vendors have more access than they need? A website vendor may not need access to infrastructure scripts. An MSP may not need write access to application source code.
- Is repository activity reviewed after security news like this? The answer should include evidence, not only a statement that everything is fine.
Why this belongs in vendor reviews
Developer access is often approved during a project and then forgotten. That is where business risk builds up. A finished website, cloud migration, or internal app may leave behind broad repository permissions, personal access tokens, old deploy keys, or unmanaged extensions on a vendor machine.
Owners do not need to turn a one-day news item into a panic. They should use it as a trigger to ask for a basic access review. If a provider manages development or automation work, the provider should be able to explain what repositories exist, who can access them, how credentials are stored, how logs are reviewed, and what changed after the reported VS Code and github.dev issue.
A practical next step
Ask your IT provider, web vendor, or internal technical lead for a short source-code access report. It should list repositories, administrators, external collaborators, active tokens or deploy keys where available, and any unmanaged developer tools used for company work. Then ask what access can be removed, what should be converted to least-privilege roles, and what should be monitored going forward.
The point is not to blame a specific tool. The point is to make sure developer access is treated like any other sensitive business system: owned, reviewed, documented, and limited to the people who still need it.
Sources and further reading