VoiceSentinel: Race condition in report buffer cleanup can corrupt transcript data and cause unbounded disk growth
Affects VoiceSentinel 2.2.1 through 3.3.0 only when report_buffer.enabled is true, with a higher chance under multiple processing workers or shared public-pool use. Fixed in 3.3.1. No vendor rating is listed.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 3.3.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
VoiceSentinel, a real-time voice moderation system for Minecraft servers, is affected in its optional report buffer feature. When that feature is enabled, concurrent writes and retention cleanup can corrupt or lose transcript data and stop old data from being pruned, so disk usage can grow until storage runs out and the host or other services on it crash.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
VoiceSentinel is a real-time voice moderation system for Minecraft servers. From 2.2.1 until 3.3.1, the optional report buffer feature has a race between retention cleanup and normal transcript writes. In `report_buffer.py`, `_maybe_cleanup()` uses an unlocked dictionary for once-per-hour cleanup throttling, allowing simultaneous `_cleanup_tenant()` operations for one tenant. Cleanup reads `transcripts.jsonl` and rewrites it in place without file locking or atomic replacement, while `report_buffer_append_async` uses `asyncio.to_thread` to append without synchronization. In `main.py`, concurrent `_processing_worker` tasks make this reachable in normal operation; `processing.worker_count` of two or more and public-pool servers sharing a `server_key` increase collisions. With `report_buffer.enabled` set to true, racing writes can lose, duplicate or corrupt transcript data and defeat `report_buffer.retention_seconds` pruning, allowing unbounded disk growth that can exhaust storage and crash the host or other services sharing it. The feature is opt-in and disabled by default. This issue is fixed in version 3.3.1.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- jackh54 VoiceSentinel
From 2.2.1 · fixed in 3.3.1
References 3
GitHub · jackh54/VoiceSentinel
Questions about CVE-2026-61854
What does this mean?
A race condition in the report buffer cleanup can corrupt transcript and report data, which can be lost, duplicated, or corrupted. It can also cause unbounded disk growth on the processor host, which can fill the disk and crash the machine and other services sharing it.Source: github.com
Am I affected, and how do I check?
Versions 2.2.1 through 3.3.0 are affected, and only when report_buffer.enabled is set to true in config.json; this feature is opt-in and off by default. The race is more likely when processing.worker_count is 2 or more or in a busy or shared public-pool deployment. To check, look at the installed VoiceSentinel version and the report_buffer.enabled and processing.worker_count settings in config.json.Source: github.com
What should I do about it?
Upgrade to VoiceSentinel 3.3.1, which is the fixed version.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data