OpenX Tips

OpenX have announced a security vulnerability in version 2.8.2 of the OpenX ad server.

If you are running OpenX 2.8.2, you should immediately update to OpenX 2.8.3, or follow the instructions from OpenX, to remove the vulnerable files from your OpenX ad server installation.

Great news! Erik Geurts and Matteo Beccati have combined forced, and released a patch for the contract campaign under-delivery bug in the OpenX 2.8.2!

You can find the patch attached to OpenX bug OX-5839.

OpenX 2.8.2 was released a while ago now, and the release notes stated that:

We have completed a number of critical security updates to the ad server in OpenX 2.8.2 to reduce any potential vulnerabilities in the software.

However, it seems that the situation is more serious that this – in the past week, an actual remote code execution vulnerability has been announced as being in OpenX 2.8.1 and earlier.

Admittedly, based on the vulnerability report, it would appear that this remote code execution can only be executed if you (or someone with access to your OpenX installation) upload an image banner with a .php file name extension that contains embedded PHP code. If you are careful about what you upload as banners into your OpenX installation, it seems unlikely that you would be vulnerable.

Still, if you have not yet upgraded to the latest version of OpenX, you would be wise to consider doing so!

A couple of weeks ago, OpenX released a study of direct ad selling practices, based on survey data from the OpenX community. If you have not read it yet, it is well worth downloading the study.

In particular, the report outlines five different techniques that publishers with direct ad sales income of more than $5 CPM generally use, and which may be worth considering using yourself if you are planning on selling your inventory directly. For smaller publishers, this is very useful and valuable information to have. Kudos to OpenX for releasing the information!

Today’s tip comes courtesy of Seagull Systems’ Demian Turner, who quite rightly points out:

“During testing you can set the cache timeout value to some low value like 1 second so that effectively the cache doesn’t get used.”

If you’re debugging banner delivery, or you want to test the results of changing settings like banner capping or companion positioning, then reducing the banner cache value can be a great way of seeing your changes “go live” much faster.

Of course, if you’re doing this on a production system, you may affect delivery performance, so make sure you keep an eye on your system performance monitoring tool!