Issue: Possible vulnerability: corrupt edit keeps reappearing

None of this is actually a vulnerability. The reappearance of certain revisions is not due to user hacking or reposting, as might be expected, but to undesired side effects of certain moderation actions. It is still possible to undo/remove revisions, but the tools don't work exactly as expected.

A similar issue was noticed in VaultWiki 4 last year, but we thought it was unique to VaultWiki 4, since the entire rollback/purge logic was rewritten since VaultWiki 3. See: https://www.vaultwiki.org/issues/3018/

Unfortunately, at this point in time VaultWiki 3 is EOL (since January 2014), so I doubt we'll be seeing any official updates to that branch. But note that it is still possible to undo unwanted revisions in VaultWiki 3, although it is unintuitive. You must actually click "Undo/Rollback" next to the latest revision you want to keep, and that will become the new working copy. I believe this "bug" began occurring when we at some point changed the phrasing of the "undo/rollback" link, and the new phrasing was actually incorrect as a reference to the design.

Now, probably what is happening to you is the following: you originally tried to rollback the unwanted revision which was the current, lead revision. Due to the behavior noted above, this created a clone of that unwanted revision as the new lead revision. Since you definitely didn't want two of them, you then tried to purge the lead revision... When you purge the lead revision, VaultWiki 3 updates the working copy with the previous revision. A purge on the lead revision is actually a rollback, but the old revision gets deleted before the rollback occurs. However, like other rollbacks, VaultWiki clones the "desired" revision to the lead revision. This makes revision 1 and revision 2 exactly the same. Now if you try to delete revision 1 again, revision 2 will be cloned, and you'll still have revision 1 and revision 2. To get around this, delete the earliest unwanted revisions first, then when the revision in 2nd position is the desired revision, you can safely remove the lead revision.

---

Although rollbacks were fixed, this behavior of purging the lead revision creating a clone of the previous revision persists in VaultWiki 4. From what I understand, this is the easiest way to update URLs, search results, and other connected information that only gets updated when new revisions are created. So while it is unexpected, undocumented behavior, that's the current (and historical) design.

I will be moving this bug report to VaultWiki 4 so that it can be resolved. In my opinion, we can run the revision creator to rebuild all the connected information but then subsequently remove the previous revision from the database, or we can try to spoof it somehow so that it updates the old revision enough to rebuild all the stuff. I think the first option is probably the most reliable in terms of forcing rebuilds.

This is fixed in the next release. This was mostly already fixed by design in VaultWiki 4, but the design was never fully implemented. When purging a front edit, VaultWiki 4 performs something called a "simple" rollback, which just changes the associated "current" edit ID and not really making any other changes.

However, this was not fully implemented, since the page DM was creating a new revision on top of it anyway. As of the next release, the page DM will no longer create a new revision if a "simple" rollback is being performed. Additional steps have been added to fix moderation states for the page if the only valid rollback target in this case is awaiting moderation (seems like a sanity check), was rejected, or soft-deleted (those two are possible).

The page's URL, search data, etc, are all regenerated from the page DM anyway, so there is not a problem there, as I suggested in my previous post.