Report it privately, not as a public issue. Either of these reaches us:

• GitHub's private vulnerability reporting on this repository, which keeps the report, the discussion and the fix in one place.
• security@lowarc.com, if you would rather not go through GitHub, or do not have an account.

Include what you need to make the case: the version (Help, then About, or lowarc --version), the platform, what an attacker gets, and the smallest project or module that shows it. A working repro is worth more than a description.

Expect an acknowledgement within a few days. LowArc is a small project, so a fix may take longer than that; you will hear where it stands rather than nothing.

Studio runs untrusted things on purpose, and the boundaries between them are the interesting part:

• Plugins render in a sandboxed iframe with no filesystem access and no direct invoke. A plugin reaching disk, another plugin's state, or a host command it was never granted is a bug.
• The plugin asset server serves plugin files over loopback HTTP, scoped to one plugin folder each. A request escaping its own folder is a bug.
• Modules are separate processes, deliberately. They are not sandboxed and are not meant to be: installing a module is the same trust decision as running any program. A module reading your files is the feature. A module reaching something through Studio that it could not reach on its own is a bug.
• Projects. Opening a project must not execute anything from it. Running it, obviously, does.
• The updater verifies a signature before applying anything. Any path that applies an unsigned or wrongly-signed update is a bug, and a serious one.

• A module or plugin doing what it plainly says it does, however unwelcome. Vet what you install.
• Anything requiring an attacker who already has your user account on your machine.
• Findings from a scanner with no demonstrated path to exploiting them.

The beta supports the latest release only. There are no backported fixes; the fix ships in the next version. See docs/versioning.md.