VaultWiki News

On May 7, 2020, we put forth another stable proposal for VaultWiki 4.1.x, Release Candidate 3. This release adds disambiguation tools, area rules governing the usage of templates, an editor button for invoking templates, overall improved editor responsiveness to other form field selections, a handful of smaller improvements, and over 100 bug fixes and style tweaks.

For a more complete list of changes in RC 3, please see the changelog here.

Where to Focus

RC 3 contains a lot and it can be a bit daunting to decide what to look at. Of particular interest are the following items (and trying to break them):

• Disambiguation pages (more below)
• Creating and testing areas with various template rules; also, determining whether the expected behavior is followed if you also require specific content-types or custom fields in the same area (more below)
• Using the editor button to insert TEMPLATE content
• Ensuring wiki uploads still work as expected
• Using the Infobox custom-field type, and testing new infobox styles and groupings
• Using the new Duration custom-field type
• Trying various option combinations for Date custom-fields
• Assigning microdata properties to various custom fields

Disambiguation Pages

RC 3 introduces the new Disambiguation page type. These are intended to be groupings of other similarly-named, similarly-themed, or often-confused wiki pages. For example, you might have multiple pages in your wiki that are named "Blue" or some variation:

• Blue (color)
• Blue (cheese)
• Blue (parrot)
• Blue (a fish in pegasus's aquarium)
• Blue (character from the TV show Blue's Clues)
• Blue (character from the movie Rio)
• Blues (music)

A disambiguation page will help uninformed users make sense of these options, reducing frustration if they end up on the wrong page. Each page that is disambiguated shows a notice at the top that describes the topic of the page, and links back to the Disambiguation page in case the user wanted a different topic.

Listings on disambiguation pages allow for full-sentence descriptions to explain how each is different from the other.

Template Rules

RC 3 now allows the institution of a template rule in each area. Using such a rule, you can:

• Suggest that editors use certain templates
• Allow editors to easily copy the contents of suggested templates, like they were drafts
• Require that editors use certain templates
• Force pages to match a template exactly, only allowing editors to fill in template parameters.

A more indepth discussion of these rules can be found here.

Release Notes

VaultWiki 4.1.0 RC 3 is proposed as stable. We recommend that customers test it first, but it should be usable in a live environment if the customer deems those tests successful.

As of May 7, security patches for May 2020 are now available.

Issue List

VWE-2020-5782 is a Permissions Escalation issue, where users are able to change a book's chapter order even though their edits require moderation, as long as they have permission to change the book's categories. The issue affects all prior versions of VaultWiki 4.x series.

VWE-2020-5788 is a Permissions Escalation issue, where users can view soft-deleted attachment edits of wiki indexes that are also attachments, without permission to manage soft-deleted index-related content, as long as the user has global permissions to manage soft-deleted content. This is a rare situation involving imports from VaultWiki 3.x, where VaultWiki 3's index page had been set to a wiki attachment. The issue affects VaultWiki 4.1.0 Alpha 1 and higher.

VWE-2020-5789 is a Permissions Escalation issue, where users who are not social group members can add or remove social group pages to wiki indexes that are also social groups, without permission to moderate index-related content, as long as the user has global permissions to moderate content. This is a rare situation involving imports from VaultWiki 3.x, where VaultWiki 3's index page had been set to a social group. The issue affects VaultWiki 4.1.0 Alpha 1 and higher.

VWE-2020-5794 is an HTML Injection issue, where unescaped HTML might appear in certain Open Graph elements. The issue affects all prior versions of VaultWiki 4.x series.

VWE-2020-5795 is a MySQL Injection issue, where users can execute arbitrary MySQL queries by leveraging a flaw in a book's Manage Chapters form. The issue affects all prior versions of VaultWiki 4.x series.

VWE-2020-5804 is a Permissions Escalation issue, where all area content parses with a forum's default parser settings for non-forum content, regardless of area settings, if the forum has Disabling Content Caching active or has recently cleared the content-type cache. The issue affects all prior versions of VaultWiki 4.x series, on vBulletin 4.x-based platforms only.

VWE-2020-5805 is a Permissions Escalation issue, where hook location bbcode_parse_start sees NULL for $forumid in wiki content, which could cause parsing with parser settings for non-wiki content, regardless of area settings, when combined with certain third-party add-ons such as CES Parser Permissions. The issue affects VaultWiki 4.1.0 RC 2, on vBulletin-based platforms only.

Patches

The following patches address the aforementioned issues:

• 4.1.0 RC 2 Patch Level 2
• 4.1.0 RC 1 Patch Level 3
• 4.0.28 Patch Level 3
• 4.0.27 Patch Level 6
• 4.0.26 Patch Level 8*

*A patch was issued for this version even though it reached its end-of-life on the patch date, because at least one of the addressed issues was identified prior to its end-of-life. However, we recommend that users update to a more recent patched version.

Notes

We strongly recommend that all users running VaultWiki in a production environment update to a patched release.

As of April 7, security patches for April 2020 are now available.

Issue List

VWE-2020-5643 is a Subscription Management issue, where alerts for likes or reactions of content the user contributed to are sent even if that user is not opted-in to that alert. The issue affects XenForo 2.x-based platforms only.

VWE-2020-5645 is a Local File Inclusion issue, whereby a malicious attacker can load VaultWiki PHP files into memory outside of the intended execution pattern for those files. However, the attacker receives a fatal error when doing so. The issue affects all versions of VaultWiki 4.x series.

VWE-2020-5727 is an HTML Injection issue, where unescaped HTML can appear in keywords, description, and other META elements. The issue affects all versions of VaultWiki 4.x series.

VWE-2020-5774 is a Permissions Escalation issue, by which users can leverage assignment form filters to retrieve a list of containers they don't have permission to view, as long as they have permission to view the container's area's content list. The issue affects all versions of VaultWiki 4.x series.

Patches

The following patches address the aforementioned issues:

• 4.1.0 RC 2 Patch Level 1
• 4.1.0 RC 1 Patch Level 2
• 4.0.28 Patch Level 2
• 4.0.27 Patch Level 5
• 4.0.26 Patch Level 7

Notes

We highly recommend that all users running VaultWiki in a production environment update to a patched release.

On March 20, 2020, we put forth another stable proposal for VaultWiki 4.1.x with Release Candidate 2. This release adds custom fields, a number of minor improvements, and about 50 bug fixes and style tweaks.

Custom Fields (XenForo 2.1 only)

RC 2 adds the ability to create custom form fields for wiki content, which can be defined in the admin panel, and configured to appear in a variety of locations, such as above the content, in a sidebar widget, or on a new tab.

When users edit wiki content, they can enter values for these fields, and the changes will be tracked in the page's history. Missing field values can be inherited from templates.

A more indepth discussion of custom fields can be found here.

Ratings

RC 2 reintroduces a feature that was once in the 3.x series, but has been missing ever since: the ability for users to rate wiki content from 1-5 stars. Ratings for pages are weighted; a rating for the current edit is considered more valuable than a rating made 5 edits ago. In this way, eventually ratings fade away, so users should be encouraged to rate and re-rate content frequently.

Ratings can be activated separately for each area, and the user must have permission to rate a given content-type.

Release Notes

VaultWiki 4.1.0 RC 2 is proposed as stable. We recommend that customers test it first, but it should be usable in a live environment if the customer deems those tests successful.

As of March 6, security patches for March 2020 are now available.

Issue List

VWE-2020-5603 is a Permissions escalation issue, where by leveraging nested templates, a user can alter the permissions of a containing template to that of a contained template. The issue affects 4.0.0 RC and higher, on vBulletin-based platforms only.

VWE-2020-5604 is a Denial of service issue, where by leveraging specially-crafted templates, a user can bypass template usage limits and create a situation where a page cannot finish parsing before server processes time out. The issue affects all versions of VaultWiki 2.x, 3.x, and 4.x series.

VWE-2020-5622 is a Permissions escalation issue, where moderators are able to action reports for index-related content they can't manage, as long as they have global management permissions. The issue affects VaultWiki 4.1.0 Alpha 1 and higher.

VWE-2020-5623 is a Permissions escalation issue, where content lists might contain content from areas that the user does not have permission to view. The issue affected VaultWiki 4.1.0 RC 1 build 001 only.

VWE-2020-5631 is a Permissions escalation issue, where users can create feeds in areas that can't contain feeds. The issue affects VaultWiki 4.0.0 and higher.

VWE-2020-5636 is a Permissions escalation issue, where users can create content they don't have permission to create, as long as they attempt to create it as part of the same request that allowed them to create different content. The issue affects VaultWiki 4.0.0 Alpha 1 and higher.

Patches

The following patches address the aforementioned issues:

• 4.1.0 RC 1 Patch Level 1
• 4.0.28 Patch Level 1
• 4.0.27 Patch Level 4
• 4.0.26 Patch Level 6

Notes

We recommend that all users running VaultWiki in a production environment update to a patched release.

We are pleased to offer a stable proposal for VaultWiki 4.1.x with Release Candidate 1, which is now available for testing. This is the first release to include compatibility with the newest PHP 7.4. In ensuring that compatibility and preparing for stable proposal, we performed a deep scrub of the code in almost all 5000+ files to get it as clean as possible. As a result, this release includes over 170 bug fixes, in addition to the normal amount of style tweaks, and other changes.

Where to Focus

While RC 1 includes mostly bug fixes, some of those fixes involved some late changes that were rather significant. For example, we fixed a long-standing regression that appeared in 4.0.x, where adding pages to categories by embedding them in templates was no longer possible. In addition, we changed some of the underlying database structure for wiki discussions and comments.

Therefore it would be ideal that this round of testing focuses on categories (especially templated ones) and ensures that discussions still work as expected.

Resolved Security Issues

Since beta versions are not subject to the same patching policy as stable versions, the following issues are patched in this release of the 4.1.x branch, 4.1.0 RC 1:

• Issues covered in the January 2020 security update
• VWE-2020-5468, which is a Permissions escalation issue, under which comments on the index don't respect the index's parsing rules set forth in the Area Manager.

Release Notes

Sites running 4.1.x betas should upgrade to VaultWiki 4.1.0 RC 1 as soon as they are able in order to improve stability. VaultWiki 4.1.0 RC 1 is proposed as stable. We recommend that customers test it first, but it should be usable in a live environment if the customer deems those tests successful.

4.0.x Update

At the same time, the latest update in the 4.0.x branch, 4.0.28 is now available, which likewise adds support for PHP 7.4. Since 4.1.x is proposed as stable, this will be one of, if not the last, main update in the 4.0.x branch, aside from security updates. Customers may have already noticed that a number of bugs reported under 4.0.x were fixed in 4.1.x only. If users have not already done so, we recommend to begin making plans to migrate to the newer 4.1.x branch, when you deem it suitable, so you can continue to benefit from the broadest number of fixes and improvements moving forwards.