GHSA-rfw3-44wh-p22w: 
Rust vulnerability analysis and mitigation

Fixed in 0.2.0-preview.23; upgrade to it.

Impact

A profile's devices (crates/kule-acp/src/profile.rs:253) gives the agent and its commands devices under /dev on Linux (profile.rs:1297-1304, Sandbox::allow_device). Neither place where a person approves a profile lists them: print_profile in crates/kule-cli/src/main.rs and opens() in crates/kule-desktop/ui/app.js have no row for devices, and Profile::warnings has no line. Profile::check does not look at them either; the only check is at launch, a list of names never given (NEVER_DEVICES, sandbox.rs:2820), which leaves a camera (/dev/video0), sound (/dev/snd) or USB (/dev/bus) through. So the person approves a profile "as it stands" without being shown that it opens hardware. The approval's digest does cover the field: it is the showing that is missing. macOS and Windows give nothing for devices.

Seen

macOS, a Kule home of its own:

$ cat agents.toml
[[agent]]
name = "helper"
command = ["helper-agent", "acp"]
hosts = ["api.example.com"]
devices = ["/dev/video0", "/dev/snd", "/dev/bus"]
$ kule --home H agents show helper
[[agent]]  helper
runs              helper-agent acp
writes in ~/      nothing
its login         nothing
sees your env     nothing
also connects to  https://api.example.com

Not run: the effect on Linux (a device readable in the task); that part is from the code above.

Fix

kule agents show and the app list every field a profile opens, its devices and keys from the keychain or a login file among them, with a warning per device. A profile may name only sound devices, cameras, serial ports and GPUs; one naming another device is held, and the sandbox gives no other. Found in the 2026-11-13 review, on main at bbf354f (0.2.0-preview.22).