BleachBit 6.0.4 repairs a Windows file shredder that skipped scattered clusters

A destruction log that reads "shredded with BleachBit" is now an entry nobody can check. There is no affected version range to compare it against and no residue figure to bound it, so the record shows that a wipe was attempted but not what it actually removed ^[4]. The overwrite that replaces it is volume-wide: everything the file system currently calls unused gets written over, and nothing comes back that names which files were left partly intact ^[5][4].

Fragmentation is the ordinary case, which is what makes the defect broad rather than a corner case. Windows scatters a file across noncontiguous clusters whenever the allocator cannot find one open run large enough to hold it ^[3]. The bigger the file relative to the largest free run on an aged volume, the likelier the scatter, so the documents most likely to have survived a shred are the large ones ^[3]. Help Net Security, in its September 9, 2026 account of the release, puts the residue plainly: parts of the file may still sit on disk where the wipe missed ^[20][2].

The rest of 6.0.4 is a local attack-surface sweep. The Windows build now calls ipconfig and taskkill by absolute path, closing the case where a bare command name hands the choice to the executable search path and whatever an attacker dropped earlier in it answers first; the DLL search path is hardened against preloading for the same reason ^[10]. Wiping no longer follows symlinks in wipe_write or wipe_contents, and truncation rejects reparse points ^[9]. Shredding refuses the working directory and its parent, which closes a path that collapsed to the current directory when handed an empty string, a period, or two periods ^[8].

Untrusted cleaner definitions can no longer run process or winreg actions ^[11], and insecure winapp2 and update-check URLs are now refused ^[12]. Fetch a definition file over a channel a third party can rewrite, and let definitions start processes, and the cleaner executes what that third party wrote. The release notes list the two as separate hardening items and do not claim anyone used it.

Seven browsers, the six Chromium-based ones plus Zen, now have their dynamic HSTS list cleared as a new cleaning capability, not a fix to an existing one ^[6][17]. Any site a user visits can write to that list, so a few bits of identity parked there survive a cookie purge and can be read back across a spread of domains as an identifier ^[7].

CodeQL and a static analysis workflow over the CI pipeline landed in the same release, along with a fix for a potential code injection in the CI translation update ^[16]. That machinery will keep producing findings, but it cannot supply the boundary an operator needs now: absent an affected version range, every Windows shred done on an earlier build is unverified ^[4][2].