Important security bug

Hi. I have found that when memcache is working, any regular member can access any object (without regarding its access rights) if it knows its URL. This does not occur when memcache is disabled.

Even more, by simply trying a blog URL like http://domain/pg/blog/read/GUID, I can view details of any private object.

I think that this is an important security bug that must be urgently addressed by core developers.


  • Using 1.7.4

    I just tested your example and it returned me to index every time.

    I tried /pg/blog/GUID/read/OBJECT_ID on a private blog and it returned Sorry; we could not find the specified blog post

  • Carlos, what version are you running?

  • We are using the latest version, i.e., 1.7.10.

    To reproduce the bug, the memcache service must be running. Then copy the URL of a private object (a blog, for example), login as another user, paste the copied URL in the address bar and ... voilá ... you can see the private blog.

    I have also found this error referenced in trac 

    I think that it is very important its solution because memcache improves signicantly the speed and scalability of the Elgg systems.

  • It's not going to get fixed anytime soon unless someone in the community fixes it. This requires a little bit of a story:

    A few years ago, the developers of Elgg would sometimes implement a new feature and get 80% done with it. Whether they were called away on another task or for some other reason, they never finished the feature but left it in the software. Sometimes there would be a notice in the source code saying something was experimental. Sometimes in a blog post or wiki ( and sometimes there was no warning.

    We now have a few of these areas in Elgg and are slowly tackling them, but we are light on resources. This link lists several of the open tickets on memcache:

    If anyone is interested in working on this, please get in contact with us.