-
VaultWiki News
by Published on November 8, 2020 4:18 PM
As of November 8, security patches for November 2020 are now available.
Issue List
VWE-2020-5943 is a Denial of Service issue, where a sanitization issue in AJAX-submitted input allows invalid UTF-8 characters to pass verification, and could result in the prevention of moderator access to XenForo 2.x's approval queue if it contains affected content. The underlying sanitization issue has existed since 4.0.0 Gamma 6 and exists in all platforms; however, the code was never used on XenForo-based platforms in the VaultWiki 4.0.x series. The issue has been exploited in the wild as early as June 2017 on vBulletin-based platforms. The malicious effect can only be realized in the following situations:
- vBulletin installations, running VaultWiki 4.0.0 Gamma 6 or higher when exploited, if that installation converts to XenForo 1.x running VaultWiki, and later converts to XenForo 2.x running VaultWiki.
- XenForo installations, running VaultWiki 4.1.x or higher when exploited, if that installation now runs XenForo 2.x
VWE-2020-5948 is a Denial of Service issue, where a malicious user may be able to a force a wiki page into a permanently moderated state by leveraging unapproved minor edits. The issue affects all versions of the VaultWiki 4.x series.
VWE-2020-5953 is a Permissions Escalation issue, where a user can see certain non-area listings of content that exists in an area where that user has no permission to view the area's contents, as long as the user has permission to view the area's landing page. The issue affects VaultWiki 4.0.0 Alpha 6 and higher.
VWE-2020-5954 is a Permissions Escalation issue, where a user can see the name of a collaborative feed they don't have permission to view, as long as a page has been added to that feed already and the user has permission to add the same page to a different collaborative feed. The issue affects VaultWiki 4.0.0 and higher.
VWE-2020-5955 is a Permissions Escalation issue, where a user can see the name of a category they don't have permission to view, as long as they have permission to edit the categories for a page that is already listed in that category. The issue affects all versions of the VaultWiki 4.x series.
VWE-2020-5956 is a Permissions Escalation issue, where a user can see the name of a wiki page they don't have permission to view, as long as they have permission to edit translations for another page that is already a translation of that page. The issue affects all versions of the VaultWiki 4.x series.
VWE-2020-5963 is an Expired Pointer Dereference issue, which can lead to unintentional data corruption or data loss. When purging the current revision of a page, both the actioned page and another unrelated page may become damaged. The issue affects the actioned page in all versions of the VaultWiki 4.x series, and the additional unrelated page in 4.0.0 and higher.
Patches
The following patches address the aforementioned issues:
- 4.1.0 Patch Level 2
- 4.1.0 RC 3 Patch Level 4
- 4.1.0 RC 2 Patch Level 5
- 4.1.0 RC 1 Patch Level 6
- 4.0.28 Patch Level 6
Notes
We recommend that all users running VaultWiki in a production environment update to a patched release.by Published on September 28, 2020 4:47 PM
As of September 28, security patches for September 2020 are now available.
Issue List
VWE-2020-5875 is a Permissions Escalation issue, whereby if there is an existing upload a user and others don't have permission to view, the user can create a duplicate of that upload in an area where they do have permission, if the user can guess the file's hash. The issue affects all versions of VaultWiki 4.x series.
VWE-2020-5930 is a Permissions Escalation issue, where by leveraging template inclusions, for a template that contains media-related BB-Codes in an area that disallows such tags, these tags might might parsed within the context of a different area that does allow them. The issue affects VaultWiki 4.0.9 and higher.
VWE-2020-5937 is a Permissions Escalation issue, where by leveraging page-level whitelists, a lower-level user could revoke an administrator's or moderator's permission to modify affected pages. The issue affects VaultWiki 4.1.0 Beta 2 and higher.
Patches
The following patches address the aforementioned issues:
- 4.1.0 Patch Level 1
- 4.1.0 RC 3 Patch Level 3
- 4.1.0 RC 2 Patch Level 4
- 4.1.0 RC 1 Patch Level 5
- 4.0.28 Patch Level 5
Notes
We recommend that all users running VaultWiki in a production environment update to a patched release.by Published on August 12, 2020 7:36 PM
After several successful rounds of release candidates, we are pleased to announce VaultWiki 4.1.0. Bug reports since the last release candidate have quieted to such a degree that we are comfortable labeling this release as stable.
Aside from all the new features that 4.1.0 betas introduced, this release includes over 80 bug fixes, resolving issues discovered in the last round and during our continuous internal code review process.
XenForo 2.2.x Compatibility
While we were wrapping up this release, XenForo 2.2.x Betas became public, and we learned that previous versions of VaultWiki would not run on those versions without encountering fatal errors and other showstopper issues. So we took some additional time to ensure that VaultWiki 4.1.0 would run under those new XenForo 2.2.x versions.
Thus, VaultWiki 4.1.0 is the first version that will run on XenForo 2.2.x. However, please note that we have not implemented any new XenForo 2.2.x features at this time.
Looking Ahead
Over the coming months, our main focus will be migrating this site to XenForo 2. In addition to the normal forum, wiki, and other add-ons, there is a significant amount of in-house code that has to be rewritten for XenForo 2. So the migration will occur as soon as it is feasible.
At the same time, main development now turns to the next feature branch of VaultWiki. For the life of 4.1.x, we expect future releases to mainly be for maintenance; that is, bug fixes or fixing style issues.
As mentioned elsewhere, there will be no further releases in the 4.0.x series, except security patches for the rest of its supported life, which is roughly 6 months from the time of writing. If you are still running 4.0.x, you should endeavor to upgrade before that time.
VaultWiki 4.1.x will be the last series to support vBulletin 3.x, vBulletin 4.0.x-4.1.x, XenForo 1.x, and XenForo 2.0.x. While there is plenty of life left for this branch, please be aware that you should aim to upgrade your forum to a newer version at some point, or you may find yourself unable to upgrade to the next branch.
Release Notes
VaultWiki 4.1.0 is now considered stable. We recommend that customers using earlier versions in a live environment update as soon as they are able.by Published on August 12, 2020 5:53 PM
As of August 12, security patches for August 2020 are now available.
Issue List
VWE-2020-5875 is a Permissions Escalation issue, where a user who was merged from multiple accounts may have new permissions granted that were not granted for any of the source accounts.
VWE-2020-5917 is a Denial of Service issue, where by creating large numbers of discussions for a conflicted page, a malicious user can ensure that the admin's conflict resolution tool cannot handle that page.
Patches
The following patches address the aforementioned issues:
- 4.1.0 RC 3 Patch Level 2
- 4.1.0 RC 2 Patch Level 3
- 4.1.0 RC 1 Patch Level 4
- 4.0.28 Patch Level 4
Notes
We recommend that all users running VaultWiki in a production environment update to a patched release.by Published on June 11, 2020 5:53 PM
As of June 11, security patches for June 2020 are now available.
Issue List
VWE-2020-5857 is an Information Disclosure issue, where debug output containing file paths could appear in the browser's Javascript console when saving pages in areas that grant at least one custom field. The issue affected VaultWiki 4.1.0 RC 3 build 001, on XenForo 2.1.x-based forums only.
VWE-2020-5862 is a Permissions Escalation issue, where some users are able to perform disambiguation tasks regardless of their related permissions. The issue affects VaultWiki 4.1.0 RC 3.
Patches
The following patches address the aforementioned issues:
- 4.1.0 RC 3 Patch Level 1
Notes
We recommend that all users running VaultWiki in a production environment update to a patched release.by Published on May 17, 2020 3:07 PM
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.by Published on May 7, 2020 2:21 PM
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.
This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
By continuing to use this site, you are consenting to our use of cookies.