Improving Quality Control in Joomla Code

Since writing my previous blog post, in which I explained how a coding error had protected older versions of Joomla from the serious security vulnerability which was patched in Joomla 3.6.4, my friend Bernard Toplak has been doing some research into how it came about that the coding error in the vulnerable user controller was fixed.

It seems that a user called lecoeurlou joined Github on 30 August 2015, submitted a patch for the faulty function call to $model->validate() to the Joomla CMS project that same day, which was accepted without question and has never had any activity on Github since.

You can see the activity here:

Now this may in fact be innocent, but to my mind it is at least possible that someone had noticed the potentially vulnerable controller in the code, had experimented with it and found the coding error. Then they realised that if they could quietly fix it, they could open up a critical vulnerability in one of the world’s most popular content management systems, which they could then exploit.

I think that the lesson is that there needs to be more quality control on patches submitted through Github, because unfortunately there clearly is scope for a malicious actor to wreak havoc.


Since I wrote this yesterday, I have been astonished at the level of interest. I expected it to be read by a dozen people at most, and to provoke no reaction whatsoever. Instead it seems to have been read by several thousand people and to have annoyed quite a few of them.

But there was a serious purpose to the article: when something goes seriously wrong, then I think it makes sense to look at why it happened rather than burying our heads in the sand, carrying on as normal and pretending it can’t happen again.

I will deal quickly with a few of the points that have been raised:-

Firstly, I am definitely not trying to point the finger of blame at any individual. I have no idea whether lecoeurlou is an evil genius or just a helpful person trying to fix some code. The problem is that we have no way of knowing.

Secondly, I am not suggesting any kind of conspiracy. Frankly it hardly required a conspiracy. If the code patch was malicious, it was far more likely just opportunism.

Thirdly, yes I really did think of saying all this by myself, I am not being used by anyone.

I am saying it because I think that it matters. Open source software is a wonderful thing, and so is the Joomla project. I would like to see it thrive. But I think that is more likely to happen in the long run if we are honest with ourselves about what the problems are.

I don’t know what the solution is. I certainly don’t want to discourage anyone from contributing to an Open Source project, quite the contrary. But we are really kidding ourselves if we think that every single person who does so does it from the purest motives, because that I am afraid is just not human nature.

I think that these are issues that need to be discussed, and if I have upset a few people by encouraging that then I can live with it, though that was not the intention.

One thought on “Improving Quality Control in Joomla Code

  1. The key piece here is where you said, “…which was accepted without question…” because that’s where the failure really occurred. Somebody should have reviewed that code before allowing it to merge in with the rest of the project. All code needs that extra pair of eyes, regardless of author, to make sure all consequences of the code are intended and wanted.

Leave a Comment on this post

This site uses Akismet to reduce spam. Learn how your comment data is processed.