No, it’s not easy. I keep history of my webpage in Subversion, so every time I need to upgrade WordPress I need to add the new version into Subversion in the vendor branch, merge in the changes in a WordPress current branch and then merge the changes into trunk of my web page. Why I do this, you say? No software is perfect, WordPress is far from it, so I need to alter some core code from time to time. That’s why.

Ok, back to the topic. Matt Mullenweg does not tell me in his blog post (link above) anything about what versions of WordPress that are potential targets for this Internet worm that exploits this security breach, nor what part of the code that makes it possible, not even how to patch it up. The entire blog post is just explaining that security holes do happen and some theory about how to protect yourself from it. Nothing concrete. Not very useful.

By default, when sending an HTTP Authentication header, Weblogic will check its own security realms for users matching the username and password. If there is no match, a 401 UNAUTHORIZED response is sent directly back to the client, without ever hitting your web application code. That takes care of the security, i guess…

This might sound like a good idea, except for those cases when your application is able to handle its own authentication. How can your application handle security when the request never hits your code?

Another problem, as i see it, is that Weblogic enforces this security model even for web application that are configured with no security at all. You can use your web application as much as you like, as long as you don’t send any HTTP Authentication headers. But when you decide to send an HTTP Authentication header like that, just for fun or when navigating from another website after being authenticated, Weblogic decides on your applications behalf that you are no longer worthy enough to use your application. That sucks…

The solution
The solution? Yes, you can bypass the security model of Weblogic, at least for those applications that does not rely on the web containers security. It took me many weeks of frustration before I found a solution to my problem, but I got there…

Shutdown your admin server and open the config/config.xml file for editing. Add the following XML code into the <security -configuration> node:

<enforce-valid-basic-auth-credentials>
    false
</enforce-valid-basic-auth-credentials>

Start the admin server again. Then you need to restart all the application servers to make the change take effect. Restart them one by one to avoid downtime… you are of course running a cluster right?