We accidentally disabled CSRF protection at some point in the past.
Impact
CSRF attacks allow attackers to execute actions on behalf of other users. To do so, they either need another (so-called XSS) vulnerability inside Flarum, or trick a logged-in user into visiting a site they control, from which they can make the user's browser send malicious requests to Flarum on behalf of the user.
One of our team members successfully reproduced the report, coming up with an attack that would let attackers manipulate any admin setting they want - provided they could attack a user with admin privileges.
Patches
Please upgrade to 0.1.0-beta.9 immediately to re-enable CSRF protection.
Workarounds
None
References
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Acknowledgments
Thanks to @CuPcakeN1njA for the responsible and detailed disclosure!
Reminder: If you notice or learn about vulnerabilities in Flarum's code, please report them responsibly according to our security policy.
unknwncharlie Analyst
We accidentally disabled CSRF protection at some point in the past.
Impact
CSRF attacks allow attackers to execute actions on behalf of other users. To do so, they either need another (so-called XSS) vulnerability inside Flarum, or trick a logged-in user into visiting a site they control, from which they can make the user's browser send malicious requests to Flarum on behalf of the user.
One of our team members successfully reproduced the report, coming up with an attack that would let attackers manipulate any admin setting they want - provided they could attack a user with admin privileges.
Patches
Please upgrade to 0.1.0-beta.9 immediately to re-enable CSRF protection.
Workarounds
None
References
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Acknowledgments
Thanks to @CuPcakeN1njA for the responsible and detailed disclosure!
Reminder: If you notice or learn about vulnerabilities in Flarum's code, please report them responsibly according to our security policy.