Tor TROVE Bugs: Why Debian's Missing CVEs Are Business as Usual

What happened

A recent Linux security roundup flagged an odd-looking detail. Debian pushed a Tor update for its trixie release before any CVE had been assigned to the fixes, and the roundup's headline singled out Tor for shipping "without a CVE" 4. The same morning brought a much larger wave of patches elsewhere: Python fixes across Fedora and SUSE, ten Red Hat advisories, and a nine-CVE update for vips. Tor stood out mainly because its entry had no CVE identifier attached 4.

That framing makes the Tor update sound irregular. Debian's own security tracker shows otherwise. The open-issues table for the tor source package lists more than a dozen entries carrying placeholder "TEMP-0000000" identifiers instead of CVE numbers. Each one is labeled only with a Tor Project TROVE identifier, including TROVE-2026-004, -013, -014, -015, -017 through -022, -026, and TROVE-2025-015 3. A missing CVE on a Tor fix is the normal state of affairs.

How TROVE and CVE numbering relate

The Tor Project tracks its own security issues under TROVE identifiers. CVE identifiers sometimes follow later, and sometimes arrive in batches. The CVE records published on May 7, 2026 show this mapping. CVE-2026-44603, an out-of-bounds read of one byte triggered by a malformed BEGIN cell in Tor before 0.4.9.7, is recorded as "aka TROVE-2026-007" and carries a maximum CVSS score of 9.1 1. The other records in that batch follow the same pattern [1]:

• CVE-2026-44597 (TROVE-2026-011): an out-of-bounds read when an END, TRUNCATE, or TRUNCATED cell lacks a reason in its payload.
• CVE-2026-44599 (TROVE-2026-008): Tor could attempt or accept BEGIN_DIR over conflux legs.
• CVE-2026-44600 (TROVE-2026-010): mishandled accounting of the conflux out-of-order queue when the queue is cleared.
• CVE-2026-44601 (TROVE-2026-009): a client crash from a double close of a circuit under circuit-queue memory pressure.

None of these TROVE numbers appear in the visible TEMP entries on Debian's tracker. The TEMP list covers different TROVE IDs, mostly higher-numbered 2026 issues 3. One plausible reading is that a first batch of Tor bugs received CVEs and a later, larger batch has not yet, with Debian tracking the later batch under placeholders until identifiers arrive.

How distributions are handling it

openSUSE's advisory shows what a CVE-mapped Tor update looks like. Announcement openSUSE-SU-2026:20709-1, rated critical for openSUSE Leap 16.0, moves tor to version 0.4.9.8 and cross-references six CVEs: 44597, 44599, 44600, 44601, 44602, and 44603 2. Its changelog lines pair each fix with both its CVE and its TROVE ID, so the two numbering schemes appear side by side 2. The changelog excerpt does not describe CVE-2026-44602, and its TROVE pairing is not shown.

Debian appears to be working from the TROVE side first. According to its tracker, the TEMP-labeled issues are marked fixed in bookworm, trixie, forky, and sid, and still vulnerable in bullseye 3. Shipping fixes keyed to upstream advisories, without waiting for CVE assignment, is the practical choice for a project like Tor, where the upstream release is the authoritative signal.

Why it matters

The "ships without a CVE" angle highlights a real gap in how many organizations consume security information. Scanners, compliance dashboards, and patch-prioritization tools often key on CVE IDs. A fix that exists only under a TROVE number or a Debian TEMP placeholder may not register in those systems, even when the patched package is already in the archive. For Tor, a meaningful share of fixes may sit in that unindexed state at any given moment, and a CVE-only view would undercount them.

The severity of the CVE-assigned batch also suggests the unassigned TROVE issues should not be treated as trivia. A 9.1-rated out-of-bounds read reachable through a malformed cell 1, plus several conflux and circuit-handling bugs, points to an active stretch of hardening in Tor's newer code paths. The Debian tracker offers no severity details for the TEMP entries 3, so no ranking can be inferred from the listing itself.

The takeaway

The missing CVE is not a red flag about Debian's process or Tor's disclosure practices. The more useful signals are elsewhere:

• Upgrade: Tor operators should be on the 0.4.9.7-or-later line the CVE records reference, or 0.4.9.8 as openSUSE ships 12.
• Check bullseye: Debian's tracker still lists bullseye as vulnerable across the open TROVE entries 3. That is the detail administrators on older Debian systems should act on.
• Track by TROVE: Anyone monitoring Tor by CVE alone will lag behind the actual fixes.