Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Blog Module /

Discuss the Blog Module.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Posted Spam -> Blog module hacked!

Go to End

35 Posts   6423 Views


Forum Moderator, 5523 Posts

7 July 2009 at 11:15am

..... and you cannot create one by the "dev/build" way.

Yes you most certainly can recreate admin members via dev/build if no members exist. You can even specify the username and password via dev/build?username=mynewuser&password=password.

I have no idea what else you can try apart from looking through the logs for the IP address. Seeing who is doing it / block that IP. And is it only the blog module - they haven't added any pages else where?. What happens if you disable the blog module (or comment out the code which allows users to write blogs on the front end)


Community Member, 607 Posts

7 July 2009 at 11:57am

Edited: 07/07/2009 11:57am

Hi cliersch,

Shot in the dark. But can you open up /mysite/_config.php and just make sure there isn't a line in there that looks like this:

Security::setDefaultAdmin('admin', 'password');

If it's there, delete it.

It really sounds like you need to check your server logs on this though. You need to find out what URL they are using to post these comments (if at all). Check the datestamp on the post and try to match it up with a time in your log - they should match.



Community Member, 904 Posts

7 July 2009 at 6:28pm

Edited: 07/07/2009 6:28pm

I tried logging in to the site using admin/password and that doesn't work. I also tried willrs suggestion to create a new user. That didn't work either. Seems like the CMS is still protected...
Aaron made a very good suggestion though. Look up the blog post timestamps and compare them with your access log. One should be able to tell what URL was used to create the blog posts.

Still: I'd change all the passwords of your website. Control Panel, FTP, Database (and others that might exist). Use distinct and secure passwords (obviously)


Community Member, 75 Posts

7 July 2009 at 10:19pm

Edited: 07/07/2009 11:17pm

I have no DefaultAdmin set inside the config.

1. We use only an ssh acces to the server. I haven't found any suspicious files or new code there - just my Silverstipe and Blog Module.

2. This morning we checked the Log files and found the entries for the latest spam (here are the last 3 - postet from different IPs and Browsers): - - [07/Jul/2009:03:22:03 +0200] "POST /news/BlogEntryForm HTTP/1.1" 302 - "" "Mozilla/4.0 (compatible; MSIE 6.0
; Windows NT 5.0)"
yy.yy.yyy.yy - - [07/Jul/2009:06:19:47 +0200] "POST /news/BlogEntryForm HTTP/1.1" 302 - "" "Mozilla/4.0 (compatible; MSIE 6.
0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 1.0.3705)"
zzz.zzz.zzz.zzz - - [07/Jul/2009:09:04:51 +0200] "POST /news/BlogEntryForm HTTP/1.1" 302 - "" "Mozilla/4.0 (compatible; MSIE
6.0; Windows NT 5.0; KTXN)"

Guess that means the entries are coming across the URL - someone is able to execute the BlogEntryForm without permission!
Thats a security problem of the blog module or not?
What should I to to stop this?


Community Member, 904 Posts

8 July 2009 at 12:50am

Bad news everyone. I just installed the Blog module and it is indeed very vulnerable to these kinds of attacks. No login checks whatsoever are being done when form data is sent to the server.
Here's a post I just created:

I used the official module download. Will check if the vulnerability is still present in trunk and file a bug report.


Community Member, 904 Posts

8 July 2009 at 1:02am

For a quick fix, add the following (colored red) to your BlogHolder.php File (BlogHolder_Controller Class):

// @line 168
function BlogEntryForm() {
		return Security::permissionFailure($this, _t('BlogHolder.HAVENTPERM', 'Posting blogs is an administrator task. Please log in.'));

// @line 347
function postblog($data, $form) {
		return Security::permissionFailure($this, _t('BlogHolder.HAVENTPERM', 'Posting blogs is an administrator task. Please log in.'));


Community Member, 904 Posts

8 July 2009 at 1:14am

Edited: 08/07/2009 1:25am

Here's a patch that fixes the issue with the current version in trunk (rev. 81246)
Will submit a ticket now.

Update Ticket is here:


Community Member, 75 Posts

8 July 2009 at 1:41am

Edited: 08/07/2009 1:42am

This is bad! But good you found a solution!!! Thanks!

I just build in your "red code" above inside the BlogHolder.php. Now I'm able to post as logged in admin but - is it save now? How can I test this?

When I'm going to use your patch I'm not able to post as an admin user either.
Your patch uses

insted of
and is adding something in function post()