# Security flaws in VS Code

**URL:** <https://discourse.julialang.org/t/security-flaws-in-vs-code/115456>\
**Category:** VS Code\
**Created:** [June 11, 2024, 6:53am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456 "2024-06-11T06:53:27Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![grahamstark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/grahamstark/32/5200_2.png) [@grahamstark](https://discourse.julialang.org/u/grahamstark)\
**Post date:** [June 11, 2024, 6:53am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/1 "2024-06-11T06:53:27Z")

</div>

Perhaps this is off-topic, but I came across a rather alarming series of posts on the insecurity of VSCode extensions. I’m sure the Julia ones are fine but I wasn’t aware of just how open VSCode was, and how few checks there are in the Marketplace:

> **[3/6 | A Letter to Microsoft: Uncovering Design Flaws of Visual Studio Code...](https://medium.com/@amitassaraf/3-6-uncovering-design-flaws-in-the-visual-studio-code-marketplace-ea1d8e8b0171)**
>
> In the previous blog post “2/6 | Exposing Malicious Extensions: Shocking Statistics from the VS Code Marketplace”, We shared shocking…

---

<div class="post-metadata">

**Author:** ![benz0li](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/benz0li/32/37040_2.png) [@benz0li](https://discourse.julialang.org/u/benz0li)\
**Post date:** [June 11, 2024, 7:58am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/2 "2024-06-11T07:58:37Z")

</div>

Has already been researched over a year ago:

> **[Can You Trust Your VSCode Extensions? - Aqua Security](https://www.aquasec.com/blog/can-you-trust-your-vscode-extensions/)**
>
> Aqua Nautilus breaks down how VSCode extensions can easily be impersonated by attackers who hide malicious code through tactics like typosquatting

---

<div class="post-metadata">

**Author:** ![savq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/savq/32/22063_2.png) [@savq](https://discourse.julialang.org/u/savq)\
**Post date:** [June 11, 2024, 9:59pm UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/3 "2024-06-11T21:59:03Z")

</div>

Unfortunately, this is a problem in most extensible editors. Vim, Neovim, Emacs; none of them have a permission model that restricts the capabilities of an extension, and it’s unlikely they’ll ever get one. It’s practically impossible to retrofit a capabilities/permission system into an ecosystem that didn’t have one from the start.

---

<div class="post-metadata">

**Author:** ![fgerick](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fgerick/32/13228_2.png) [@fgerick](https://discourse.julialang.org/u/fgerick)\
**Post date:** [June 12, 2024, 7:36am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/4 "2024-06-12T07:36:37Z")

</div>

I’m no expert. Do you think the new [zed editor](https://github.com/zed-industries/zed) would qualify as having a permission system in it from the start? I found [this issue on GitHub](https://github.com/zed-industries/zed/issues/8552) that at least mentions it should be possible.

---

<div class="post-metadata">

**Author:** ![savq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/savq/32/22063_2.png) [@savq](https://discourse.julialang.org/u/savq)\
**Post date:** [June 12, 2024, 11:40pm UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/5 "2024-06-12T23:40:50Z")

</div>

Zed is still at an early stage, so it could add a permission system. However, I haven’t seen anything that says zed cares about security, and since they’re already cutting corners (like [downloading unsigned executables](https://github.com/zed-industries/zed/issues/12589) 🤦‍♂️), I wouldn’t count on it.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [June 13, 2024, 12:45am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/6 "2024-06-13T00:45:14Z")

</div>

Yikes! ☹

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [June 13, 2024, 1:08am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/7 "2024-06-13T01:08:13Z")

</div>

This prompts an obvious question: is there ANY editor that cannot be hacked as described? I believe that the plain old vi may be exempt, but seems to me all powerful editors of today are wide open to bad actors of all stripes. Is that true?

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [June 13, 2024, 11:28am UTC](https://discourse.julialang.org/t/security-flaws-in-vs-code/115456/8 "2024-06-13T11:28:33Z")

</div>

> [@PetrKryslUCSD](#):
>
> I believe that the plain old vi may be exempt, but seems to me all powerful editors of today are wide open to bad actors of all stripes. Is that true?

Probably. As soon as an extension is allowed to spawn a useful process, said process can do Bad Things™. Is an extension allowed to run arbitrary code in the context of your editor? Bad Things™ can happen.  
Are you using a vim plugin that uses a language server in an external process? That’s a potential security issue.