Vigilante File integrity report

Hi again @akgt

Thanks again for pushing on this, and for coming back with concrete examples.

You’re right about the core of it. Alert fatigue is a security problem, not just an annoyance. A report that fires 61 times about translation files is training you to close it without reading, and the day something real shows up in your .htaccess it will be buried in that same flat list. That is a regression, and I’m going to fix it.

Here’s what I found digging into your case.

The language JSON files aren’t multiplying. Checked against the wp.org checksums API for en_GB: 54 files in WP 5.9, 60 in 6.5, 68 in 7.0.4. Six major versions, fourteen files. What actually happens is that they all get rewritten at once. Between 6.8 and 7.0.4, 76 of the 77 shared language files changed hash. They’re the JED files behind wp_set_script_translations(), one per JS file with translatable strings, and they carry a revision-date header, so any rebuild of the language pack changes their content even when the translation itself is identical.

On top of that, wp.org regenerates the checksum manifest every time GlotPress rebuilds a language pack, which happens constantly and independently per locale (all four of these are on 7.0.4: de_DE rebuilt 15 Aug, en_GB 7 Aug, es_ES 10 Jul, fr_FR 24 Jul), while Vigilant caches that manifest for 24 hours under a key that only changes with the WordPress version. So the two sides drift, and you get a burst of “modified” files that either clears itself or, if your cron or translation auto-updates are off, never clears at all. That’s a bug on my side and it’s getting fixed.

On excluding wp-content/languages: I’m taking your point seriously, and you’ve raised useful things here before, so this isn’t me brushing it off. But a blanket exclusion of that folder would be a bad trade. Since WP 6.5 it also holds .l10n.php files, which are executable PHP that WordPress requires on every request. Excluding the folder would leave a writable, executable, unmonitored directory, which is exactly where I’d want to hide a backdoor if I were the attacker. So instead of excluding the path, I’ll add safe rules: extension-scoped exclusions inside that folder for .json, .mo and .po, with .php never excludable there.

The real fix isn’t exclusions at all, though. It’s splitting the report in two: changes I can attribute, and changes I can’t explain. Attributed means the new hash matches the current wp.org checksum (so it isn’t merely expected, it’s verified against the authoritative source), or the change landed entirely inside a known plugin’s marker block (LiteSpeed writes between # BEGIN LSCACHE and # END LSCACHE, which is a different class of event from 14 loose lines outside every marker), or it coincides with an update event I already log. Nothing gets silenced and nothing gets excluded, but after a normal update the second list is empty, and an .htaccess change that matches no update becomes the only thing on screen instead of item 62.

What I won’t do is stop watching .htaccess and wp-config.php. Those are prime persistence vectors and going quiet there wouldn’t make the plugin more convenient, it would make it stop doing its job. But you were never really asking for that, and I read your point too narrowly at first.

One more thing: your report surfaced an actual bug, so thank you. The localized core checksum manifest includes translations for Akismet and the default themes, which aren’t core and update on their own cycle. So if you delete an unused default theme or Akismet, which my own Security Check explicitly tells you to do, File Integrity reports missing core files forever, on any non-English site. Two parts of the same plugin contradicting each other. That one I’m treating as a genuine fix.

No dates from me, since the 3.0 cycle is already scoped and I’d rather not promise a schedule I can’t keep. But all of this is written down and it’s getting done.

Thanks (again) 🙂

Fernando

Absolutely, I’ve understood your concern and it’s a real pain 🙂

Regarding the issue with the verification code, if it come back please open a new thread to check it out 😉