VoiceSentinel Processor CVE-2026-61854

Requires the opt-in report buffer to be turned on (report_buffer.enabled: true in config.json); it is disabled by default, which is the primary limiting factor. The race is reached through normal operation but is substantially more likely/faster when processing.worker_count is 2 or more (the project's own documented performance recommendation) or on a busy/shared public-pool deployment where multiple servers write to the same tenant file via a shared server_key. Only versions 2.2.1 through 3.3.0 are affected; the manifestation is timing/load-dependent (CWE-362), so it is not reliably triggerable on demand and primarily degrades availability (disk exhaustion) and transcript integrity rather than exposing data.

Signals are mixed and point to a moderate, operationally-scoped risk rather than an urgent emergency. The input CVSS is 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H), driven almost entirely by the Availability:High component (disk exhaustion crashing the host), with Integrity only Low and no Confidentiality impact. The vuln.today decision label is 'this_week' (not act_now/emergency). No EPSS score, no CISA KEV listing, and no public PoC were provided - the only references are the vendor GHSA advisory, the fix commit, and the 3.3.1 release tag, i.e. patch artifacts, not exploit code. Exploitation status: no public exploit identified at time of analysis. Two tensions should be flagged explicitly: (1) the input vector marks AC:L, but the root cause is a CWE-362 race between retention cleanup and transcript appends that depends on concurrency timing and load - a deliberate attacker-driven trigger is closer to high-complexity, so AC:L overstates how reliably an outsider can force it; (2) the vector is AV:N/PR:N, yet this is not a classic crafted-request RCE - it is a concurrency defect reached through normal processing load, and critically it only exists when the opt-in report_buffer.enabled feature is turned on (disabled by default), which the base CVSS vector does not reflect. Net: a genuine availability/integrity reliability bug worth patching on a normal cycle for operators who enabled the report buffer, but not a widespread drive-by exploitation threat.

On a VoiceSentinel processor with report_buffer.enabled=true and the recommended processing.worker_count of 2+, sustained concurrent voice traffic causes multiple _processing_worker tasks to append transcripts while a once-per-hour retention cleanup rewrites transcripts.jsonl in place without locking. The racing write clobbers the cleanup (or vice versa), silently defeating retention pruning so the buffer grows without bound, eventually filling the disk and crashing the host and any co-located services. No public exploit code is identified; the condition can arise in normal operation, and a busy or shared public-pool deployment (many servers sharing one server_key file) accelerates it.