Hi, I didn't check the sources to see what solution was finally given to the Version DoS attack, but I have a suggestion. The problem, IIUC, is that Zope needs to decide whether the Version informaton it's receiving is valid without having access to ZODB data. My suggestion is to disable Versions unless Zope is started with the ENVVAR (or ZConfig var) VERSION_KEY, which is a password used to hash the Version info. In this case, the version cookie would be generated like this Zope-Version = <version>:MD5(<version>:VERSION_KEY) This way the connection machinery doesn't need to open the connection in order to verify that Zope-Version was generated from a real version object. The only way to abuse the Version system is by knowing VERSION_KEY. Looking at the cookie itself will only allow an attacker to open the same version, but even this can be avoided if we put an expiration time in the cookie value and encode it in the signature part as well: Zope-Version = <version>:<expiration>:MD5(<version>:<expiration>:VERSION_KEY) Variants of this include putting the auth info in a different cookie (Zope-Version-Auth), using SHA instead of MD5 to make it stronger, base64 encoding the binary flavor of the digest digest instead of using the hexdigest to make the cookie smaller, etc. Cheers, Leo PS: I can help coding this if anyone can help me get my subscription to zope-coders going (I tried subscribing but nothing happened) and checking why my public key isn't working to get a Zope checkout (my zope.org login is LRA) :-)