Wordpress, Textpattern and Security · 22. Juli 2004, 19:26


This is not a comprehensive view on the security of these two packages. However I had to get something off my chest which may or may not be interesting to others, either when they make their decisions on which of the two they choose, or in taking initiative to request a different handling of security issues for a package they already chose and want to keep using.

The setting

I was using b2 on this site before, and it served me good for quiet some time. But since development halted, because the Lead-Developer had more important issues (RL I guess) to tackle, I wanted to switch to something that was still actively developed and looked after. Wordpress and Textpattern seemed to be attractive choices, so decided to evaluate them. I am by no means an expert, but I am running a couple of Web-Applications across several sites for a few years now and have developed a few of my own. With the always recurring theme of bug fix-versions that close security holes and doing development myself, I became aware of typical mistakes that keep being made over and over. I have not made a thorough code review (where to take the time…), but I poked around seeing if I would something.

The actual hole

And I did find something, it was related to CSRF. I wrote the general idea up an entry1 and a follow-up to it2. Of course with no mention of any specific software. In a Nutshell: I could have tried to delete entries on your weblog, just by you viewing this page – no matter your browser-vendor or settings. The success would not have been guaranteed, since it would have required that you had to be logged in to your site, or using the auto-login-feature – that however is not a rare condition. IMHO this was a pretty serious issue.

Contacting the developers

Before I wrote those entries (which didn’t mention any specific software anyway), I contacted authors of both of those packages privately via E-Mail: Dean from Textpattern and Matt from Wordpress. The good news is: It was easy finding ways to contact the devs and both of them replied very promptly acknowledging the problem, we had a few E-Mails back and forth about ways to fix it. Both promised to fix the hole for the upcoming release. That was back in mid-May. And a short while after both released a new package. Look at the announcements/change-log:

Textpattern: g1.19 Released
Wordpress: 1.2-Changelog

Did you find the mention of the fix? I’ll help you.


On Dean’s list of 17 bullets the 10th says:

Closed up a nasty but difficult-to-exploit security hole involving variables passed by GET (thanks to Sencer for finding this)

It’s out there. It’s not as prominent as it could have been, but it’s there and it states it as nasty. The “difficult-to-exploit” is at least debatable (to put it mildly, even if it does require the involvement of the victim). From the technical side, the solution that was implemented is the token-approach that Peter W. proposes in his article on CSRF[3]. IMHO a satisfactory reaction.


What does the Wordpress Changelog mention about this? Features… nope, it’s not a feature. Improvements maybe… nope, OK, it’s not an improvement that one can necessarily see. So it must be in the third section – Fixes… nope. The only thing it mentions at all is:

* Sencer

That’s right, no mention of a security issue at all. Nothing, Nada. I don’t know about you, but I am not the kind that immediately jumps on the newest version, if there is no incentive for me. If I am happy with an installed version, I’ll defer updates until I have the time to calmly update my site. So announcements like that which don’t tell me about important security related updates to the code do me as a user a real disservice.

The other thing that bugged me, was that the solution implemented was the Referrer-Solution (again, see [3]), which effectively works around the problem almost all of the time, but well, only almost all of the time. The reasoning (as I understood it) was that other approaches would have required a lot more work, while only being marginally better, which was a no-go with the next version so close to release. However he did make it clear, that the issue will be further worked on and be made just as secure as with the token approach. Since this was in May, I assume that the issue has in the meantime been dealt with, due to lack of time I haven’t been able to check.

My conclusion

I decided to go with Textpattern after that, because I want to know if my software has a security problem and I need to update.

General Proposal

This article has gotten too long already. This last part is held fairly general and is not specifically directed to the developers of Textpattern or Wordpress. I searched for a policy or a proposal that would cover the handling of security issues, but I failed to find something that really fit. If you know of something like that, please leave a comment. The closest I came is in4. So I’ll sketch out a few things that I would expect good Software-Developers to follow:

I know that especially with free and non-commercial software, it is voluntary work we rely on. And I am grateful for other people’s work, and I try to get involved at least somewhat, to give something back. This (obviously) is not a demand, but a Request. I believe that Users as well as Developers can benefit from it. If you are a user, let the developers know how much you would value a open, honest and systematic approach to handling security issues. It will make their choices easier, too.

[1] GET considered harmful; Sometimes
[2] Securing Forms with POST is not enough
[3] CSRF
[4] Open Source Security Strategy
[5] Configuration Management