GHSA-jh74-jr8c-55p8: 
Rust analisi e mitigazione delle vulnerabilità

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

Impact

On macOS, Kule reads what a task's sandbox refused back from the system log, and reports the list as complete once the log shows a refusal Kule makes after the commands'. Under heavy load, a refusal made before Kule's own could still be missing from the log at that moment, or the log could have dropped it from the stream Kule reads while still delivering Kule's own. Kule then listed fewer refusals than were made, or none, without saying the list may be incomplete (kule exec, kule run, the app's run and terminal notes, the agent's next-run record). The sandbox refused every operation all the same; only the report was short. A process inside the task can cause such load itself.

Root cause (measured 2026-10-24 and 2026-10-25)

1. log show reads the log's store, which a busy machine fills late and out of order: reads begun up to 4 s after a refusal missed it while Kule's later flush refusal already showed; some entries showed ~30 s late. After a burst of 4000 refusals, the store showed about 60% of them when the flush made after them first showed; the rest landed within seconds. After bursts of 50 the store had them all when the flush showed (15 of 15 rounds).
2. The kernel writes sandbox reports as "unreliable" messages and drops them when logd falls behind (many refusals at once × many log stream readers); streams and store lose the same ones. The drop is noted only in the store, as lossEvent (processID 0, "lost ≥63 unreliable messages from <mach>-<mach>"); no log stream ever carries loss events. Loss events reach the store late but in order relative to later messages.
3. logd gives a reader of log stream that falls behind (CPU-starved, or paused) its backlog only up to a cap: some 700 to 2000 of a sandbox's refusals, depending on message size. Past the cap the newest events are dropped with no word to the reader, and events made after the reader catches up are delivered, Kule's own refusal among them. A list checked against that refusal on the stream could therefore read as all the log kept while the middle was missing. log stream itself waits for a slow consumer of its stdout (nothing is lost there); the cap is logd's, and only events matching the reader's predicate fill it.
4. Side issue: sandbox tags and process marks came from the clock; sandboxes made at the same moment shared them.

Fix (0.2.0-preview.14)

• Kule reads a sandbox's refusals from one log stream per Kule process, shown to listen (a refusal of Kule's own arrives) before the sandbox's first command.
• Once the commands are done, Kule makes one more refusal of its own and waits for the log's store to show it. What the stream brought is listed as all the log kept only when the store shows that refusal and shows nothing refused under the sandbox's tag that the stream did not bring. Otherwise Kule adds what the store shows, read until it stops growing (up to 8 s), and tells the list as perhaps not all, as before.
• The kernel's losses the store notes between when Kule began to listen and that last refusal are told in their own quiet line, with when they happened, in kule exec, kule run, kule shell, the app's run notes and terminals. A loss cannot be tied to its sender, and a busy Mac drops kernel messages every few seconds (250–485 losses per hour measured on one Mac under ordinary desktop load), so it is told every time but not as a warning. No second source of truth exists for an unprivileged process: SBPL trace writes nothing on current macOS, send-signal is ignored, sandbox_inspect_pid needs privileges, Endpoint Security needs an Apple entitlement.
• Sandbox tags and process marks come from /dev/urandom.
• The exit code stays the command's in every case: the sandbox refused everything all the same.

Tests

• Kule's stream reader is paused (SIGSTOP) through a burst of 4000 refusals and continued before Kule reads: such a list is never told as all there was, and it lists what the store shows (refusals_the_stream_dropped_are_read_from_the_store; seen failing first: 718 of 4000 listed, told as all).
• A burst of other sandboxes' refusals plus log readers, ended before Kule reads: a refusal the log dropped is never in a list told as all there was, and the loss is told (a_refusal_the_log_dropped_is_told_when; a round whose command never ran is skipped); the same invariant under a continuing flood; 1024 sandboxes made at once on 16 threads have distinct marks; the store's losses are bounded by when Kule began to listen and by its last refusal; the stream holds no descriptor of Kule's process.
• Mutations of each guard were run. Removing the check that the store shows nothing the stream lacks is caught. Removing the wait for the store to stop growing was not caught (one read already showed over 90% on the test Mac; under a flood the kernel kept too few refusals to tell); it is kept, as the store was measured to fill seconds late. Removing the wait for the store to show Kule's last refusal was not caught by any flood configuration on the test Mac; it is kept, as the store was measured to note losses up to ~30 s late under load.

Workarounds

Upgrade to 0.2.0-preview.14. The sandbox's boundary itself was never affected: only the list of what it refused could be short.