Hi folks, I hope you’re all okay out there. The year 2020 has been a hell of a ride for many of us, hopefully you all got through it without major damage.

For the FlatPress project, 2020 was kind of quiet. Sure, we made big steps towards FlatPress 1.2 (see the progress in the Changelog), but we didn’t manage to release it yet. Even the security fix I planned to release didn’t work out as expected, it may even not be released until after 1.2.

However, 2020 also was another year with strong community support. Thanks a lot for all the emails and suggestions, for your contributions on the wiki, your testing efforts and your pull requests on GitHub. Also, thank you very much for kindly supporting each other on the forums, it is always a real pleasure for me to see that.

I feel a little sorry about the slow release cycle. FlatPress 1.2 should’ve been released long ago to enable FlatPress for PHP 7.4 and PHP 8. I’ll do my best to get this done real soon. But at least, we consequently stick to our project philosophy: We do not run a feature race here ;)

I wish you all some quiet and peaceful holidays. Let’s take a few days off and gather fresh momentum for the new year. If all goes well, life may go back to some kind of normal one day.

All the best,
Arvid

Image: Derivate of “meh” by Яick Harris - licensed under CC BY-SA 2.0

Hi guys,

it’s been silent here for quite a while. But this doesn’t mean there’s nothing happening:

The security issue

You may or may not have seen the security issue #64 filed by lethanhtrung222. It addresses an issue that allows an attacker to delete any uploaded file on your blog just by making you click on a link like this:

• https://YOURBLOG.ORG/admin.php?p=uploader&action=mediamanager&deletefile=THEFILE.XYZ

This link could be sent to you via email, it works if you are already logged into your admin area.

The described cross-site request forgery (CSRF) also applies to deleting entries and enabling/disabling plugins.

The fix

Although this is not highly critical, I decided to create a bugfix release that solves this issue. Now, on every logon, a unique token is created. The token is added to the affected links in the admin area, e.g. the “Delete” link in the entries listing. Since this token is freshly created on every logon, an attacker does not know it and can’t attach it to the attacking link. Without the correct token, FlatPress will just not execute the desired action.

The testing

Before releasing the new version finally, I reach out to you: Please help me testing the new version thoroughly and report any bugs that you encounter.

Everything should work exactly as in version 1.1 “Da capo”. The only difference is the new “csrftoken” parameter in the links of the admin area actions described above.

Fiddle around with it: Copy the link URL, change the “csrftoken” parameter and see what happens :)

Get the new version here:

• Download it directly from the GitHub branch.
• Get the update package 1.1 to 1.1.1 and copy its contents into your FlatPress 1.1 instance. Simply overwrite existing files.

Please do not test on your productive FlatPress instances, this is still beta.

The new version

If everything works as expected in our tests, I will release the new FlatPress version 1.1.1 very soon.

Thanks for your help - and have a great start into the upcoming new week!
Arvid