If you have not yet updated to v1.6.3 or later, do so immediately. The details of the vulnerabilities are public, and your forum could be maliciously exploited.
v1.6.3 has been released to address 3 security vulnerabilities reported by @clarkwinkelmann.
⚠️ Affected versions:
Two of the vulnerabilities affect all versions below v1.6.3.
One affect all versions between v1.3.0 and v1.6.2.
Upgrade instructions:
# Update to latest version
composer update --prefer-dist --no-dev -a -W
Verify that you're on v1.6.3
composer show flarum/core
Clear cache
php flarum cache:clear
Preface
⚠️ Post mentions can be used to read any post on the forum without access control (High Severity)
On December 27th, 2022, we received a report of a high confidentiality vulnerability in Flarum mentions through huntr.dev, affecting all versions below v1.6.3.
Impact
The mentionsPosts relationship included in the POST /api/posts and PATCH /api/posts/<id> JSON responses leaks the full JSON:API payload of all mentioned posts without any access control. This includes the content, date, number and attributes added by other extensions.
The attack allows the leaking of all posts in the forum database, including posts awaiting approval, posts in tags the user has no access to, and private discussions created by other extensions like FriendsOfFlarum Byobu. This also includes non-comment posts like tag changes or renaming events.
All Flarum versions prior to v1.6.3 are affected.
The details of this vulnerability were disclosed on the Flarum Discord's team channel at 00:07 UTC. The vulnerability's CVE score was 7.7, which is a high CVE score.
CVSS
The estimated CVSS vector for this vulnerability is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, resulting in a CVE score of 7.7. See the CVSS score breakdown.
A security advisory has been published on GitHub detailing information of the vulnerability: https://github.com/flarum/framework/security/advisories/GHSA-22m9-m3ww-53h3. Waiting for a CVE to be issued.
Workarounds
Disable the mentions extension.
⚠️ Notifications can leak restricted content (Moderate Severity)
On December 29th, 2022, we received a report of a moderate confidentiality vulnerability in Flarum core through the discord server private channel, affecting all versions below v1.6.3.
Impact
The notification-sending component does not check that the subject of the notification can be accessed by the receiver, and proceeds to send notifications through their different channels. The alerts do not leak data despite this as they are listed based on a visibility check, however, emails are still sent out.
This means that, for extensions which restrict access to posts, any actor can bypass the restriction by subscribing to the discussion if the Subscriptions extension is enabled.
The attack allows the leaking of some posts in the forum database, including posts awaiting approval, posts in tags the user has no access to if they could subscribe to a discussion before it becomes private, and posts restricted by third-party extensions.
All Flarum versions prior to v1.6.3 are affected.
The details of this vulnerability were disclosed on the Flarum Discord's team channel at 13:12 UTC. The vulnerability's CVE score was 6.8, which is a moderate CVE score.
CVSS
The estimated CVSS vector for this vulnerability is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N, resulting in a CVE score of 6.8. See the CVSS score breakdown.
A security advisory has been published on GitHub detailing information of the vulnerability: https://github.com/flarum/framework/security/advisories/GHSA-8gcg-vwmw-rxj4. Waiting for a CVE to be issued.
Workarounds
Disable the Flarum Subscriptions extension or disable email notifications altogether.
There is no other supported workaround for this issue for Flarum versions below 1.6.3.
⚠️ Any user can reply in public discussions whose first post was permanently deleted (Low Severity)
On December 29th, 2022, we received a report of a low integrity vulnerability in Flarum core through through huntr.dev, affecting versions between v1.3.0 and v1.6.3.
Impact
If the first post of a discussion is permanently deleted but the discussion stays visible, any actor who can view the discussion is able to create a new reply via the REST API, no matter the reply permission or lock status. This includes users that don't have a validated email.
Flarum automatically makes discussions with zero comments invisible so an additional condition for this vulnerability is that the discussion must have at least one approved reply so that discussions.comment_count is still above zero after the post deletion.
This can open the discussion to uncontrolled spam or just unintentional replies if users still had their tab open before the vulnerable discussion was locked and then post a reply when they shouldn't be able to.
In combination with the email notification settings, this could also be used as a way to send unsolicited emails.
Versions between v1.3.0 and v1.6.3 are impacted.
The vulnerability's CVE score was 3.5, which is a low CVE score.
CVSS
The estimated CVSS vector for this vulnerability is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N, resulting in a CVE score of 3.5. See the CVSS score breakdown.
A security advisory has been published on GitHub detailing information of the vulnerability: https://github.com/flarum/framework/security/advisories/GHSA-hph3-hv3c-7725. Waiting for a CVE to be issued.
Workarounds
If you don't delete the first posts you are not affected. A workaround can be to delete the discussion itself, or amend the database to manually set a first_post_id.
How were the vulnerabilities fixed?
These were patched through a combination of efforts from multiple developers in the past couple of weeks and pushed to the core's release/v1.6.3 branch on the 10th of January 2023 around 12:00 UST. After verifying that the patch worked as expected and didn't have noticeable effects on other areas of core and bundled extensions, it was released as v1.6.3 on the same day an hour later.
What did we do right?
Available core developers looked into reports and discussed to patch the vulnerabilities one by one as soon as possible, an initial patch was proposed within a day and subsequent patches were proposed the week following it. With all approvals being acquired by the 9th January 2023.
What could we improve?
It took longer than usual to get a full patch ready and released, but this is mostly due to the fact this was a time of holiday for most of our team, but also because there were multiple (3) vulnerabilities we had to look into and our decision to fix them all in one patch.
How can we prevent this from happening again?
While we have made incredible progress in our backend test coverage, there is definitely a lot more that can be done. We need to invest more time into adding more backend tests so that issues such as these are caught earlier.⚠️
