Important Security Update: Please Update ioquake3 Immediately

Please immediately update ioquake3 to the latest test build before you connect to any online servers. Despite the name, the test builds are in fact way more stable and secure than any release at this time.
In doing so you’ll also receive access to all kinds of other updates and changes that we’ve made since you last installed ioquake3.
Here’s the why:
We recently pushed  a large security fix that prevents malicious actions from multiplayer servers.
Please share this news with any other Quake 3 players you know. It’s on Facebook and Twitter as well. These kinds of exploits are even worse in the regular Quake 3 client, nobody should be using that anymore.
Our Player’s Guide can help new Quake 3 players get started with ioquake3.
Ideally, we would distribute these security fixes automatically, similar to the way browsers like Chrome and Firefox distribute updates. Games on consoles, or in Steam, require updates in order to go online and happen automatically now. This way, we could distribute an update first so that nobody who is online is vulnerable in an ideal scenario.
Right now we don’t have anyone working on that issue, if you are interested in helping us with an auto-update system to be built into our launcher, get in touch.
Until then, please update your test build as often as you can to get the latest security changes.
ioquake3 is an all-volunteer project that needs your help. Check out this page if you’d like to join us in our mission to keep Quake 3 alive.
Our thanks to Victor Roemer for reporting the vulnerability.
If you find a security vulnerability, please e-mail

Notable Replies

  1. Despite the name, the test builds are in fact way more stable and secure than any release at this time.

    If you have to advise against using your stable builds, I guess that means you should make a release? It would also be much easier for Linux distros to grab a new stable release that fixes a security vulnerability than to have to package the latest commit from your git repo’s master branch (assuming it matches those “test builds”, I haven’t looked yet).

    Edit: Just looked it up, it seems it has been 8 years since the last 1.36 release. It’s really time to release something new. My distro (Mageia) still packages a snapshot from icculus’ SVN repo (rev 2102), no idea how old that is, but likely quite old. I’ll take over that package’s maintainership and update it to the latest git, but that shows how dearly you guys need to put out a proper release.

  2. We need a build engineer to update installers and help us modernize for today’s platforms.

  3. So, I grabbed the “test build” extracted it and was running just fine. I hadn’t realized a problem until I tried to install ioquake3 on another desktop. The x64 client can’t connect to my linux server because of “UnPure pk3 files”. Works fine if I use the original file. Is this correct, or am I missing something?

  4. Quake 3:

    ioquake3.x86.exe (1332 KB) can connect and play, but ioquake3x86_64.exe can NOT play - it gets kicked for unpure pk3.

    I even copied all the pk3’s (and there are a lot) from the server to the client machine, and I still get kicked. I then tried just the basic pak0.pk3 files, and a stock map, and still get kicked.

  5. Thanks, I was able to connect to the server and reproduce the problem. It appears the pure list (sv_paks) is not being set correctly on the server, due to an overflow from too many pk3s. Specifically, I suspect the BIG_INFO_STRING limit is being hit in Info_SetValueForKey_Big on sv_paks, preventing it from being placed in the systeminfo.

    As for why the test builds failed to connect while older versions succeeded, it might be related to the newer versions being more eager to load qvm files outside of pk3s, which causes the pure verfication check to fail. When I ran the test builds with the baseq3/vm folder (that comes from the test build zip) excluded, I was able to connect to the server like with the old versions.

    The overall solution to the problem is to set sv_pure to 0 on the server, or have a smaller number of paks on the server. This should probably also be addressed as a bug in ioq3, since there should be better checks and handling of this kind of overflow.

Continue the discussion at

2 more replies