But the point made by BlogSecurity.net is that there is a fundamental problem with the WP core. Do you think that is the case?

No. Let me elaborate on what I said above. When he mentions specifics, DK argues that what makes WordPress insecure is 1) that it should be “providing a proper set of SQL safe functions” 2) WordPress should use mysql_real_escape_string(), and 3) WordPress should “have clearly defined coding standards and security policies.”

1) Is true in development WordPress, which implements the prepare method of the WPDB class.
2) Is tricky. WordPress supports a variety of character encoding in databases, and mysql_real_escape_string() doesn’t play nicely with all of them. Right now there’s a Trac ticket in which people are trying to work this out.
3) Is more of a documentation issue than a WordPress issue, and it has to do more with plugin authors than WordPress itself.

I think it’s unreasonable to expect developers to anticipate every possible attack vector. Rather, we should expect them to respond quickly to security flaws when discovered (which WP does) and to follow secure coding practices as much as is possible (which WP generally does).

There have been programs with more users, but as far as the number of complete noobs using it and installing it, I’m pretty sure WordPress is top of the pile.

Perhaps this is an overriding factor in WordPress’s security problems?

So is WordPress insecure by design? The answer seems to be yes!

I don’t think that’s quite right. For one thing, some of the things DK suggests are implemented in the development version of WordPress, which will be released as version 2.5 in the spring.

It’s not really fair to say WordPress is “insecure by design” when steps are and have already been taken to address those general issues.

And to be fair, the WP developers are pretty quick about addressing security issues when discovered: it took less than two days for the recent XML-RPC bug to get a patched release.