Security administrators are still busy chasing down patches for Shellshock, the Bash vulnerability that hit the web last week.

Bash is a system software used by millions of computers, so the vulnerability opens up the possibility that an attacker could execute arbitrary commands on any machine running it.

The biggest target is web servers; for now, average users don't have much to fear. But as security researchers look into aspects of the Bash codebase, more dangerous vulnerabilities are starting to crop up.

Google's Michal Zalewski, also known as "lcamtuf", has found two additional common vulnerabilities and exposures (CVE) in the Bash parser in the last few days alone.

Found 6th and most serious issue in bash, equiv to the original RCE. If you're using just the first patch, you'll be in trouble soon.— lcamtuf (@lcamtuf) September 28, 2014

That brings the total number of CVE's in Bash that we can associate with Shellshock to six. The sixth vulnerability, which Zalewski reported Sunday, is as bad as the original flaw.

"The second one is essentially equivalent to the original flaw, trivially allowing remote code execution even on systems that deployed the fix for the initial bug," Zalewski told iTnews in Australia.

Zalewski hasn't released any technical details on the vulnerabilities; he wants to give admins and companies a chance to update first. But he urges all server admins and advanced users to deploy an unofficial patch from Red Hat employee Florian Weimer.

Weimer's patch is shipping with several Linux distributions, so advanced users will need to check to see if the latest patch is available or whether they need to install it manually.

The original Shellshock vulnerability, and those that followed in the last few days, have naturally led security researchers to question the security of the Bash parser itself.

The Bash codebase dates back to 1987; the Shellshock bug itself was likely introduced in 1992. That makes it one of the oldest, if not the oldest, bug of this magnitude to go undisclosed for this period of time.

Errata Security's Robert Graham wrote about the state of the Bash codebase on the Errata Security blog, where he points out how obsolete many of its practices are:

In response to #shellshock, Richard Stallman said the bug was just a "blip". It's not, it's a "blimp" — a huge nasty spot on the radar warning of big things to come. Three more related bugs have been found, and there are likely more to be found later. The cause isn't that a programmer made a mistake, but that there is a systematic failure in the code — it's obsolete, having been written to the standards of 1984 rather than 2014.

Part of the problem — which we saw with Heartbleed as well — is that when code seems to work, the longstanding theory of "many eyes makes all bugs shallow" tends to disappear. That's because many eyes aren't actually looking at the code. For some of the most important parts of the open-source ecosystem, the number of users rarely aligns with the number of maintainers or auditors.

The silver lining of the Heartbleed vulnerability was that it exposed just how woefully underfunded the OpenSSL project was. The Linux Foundation and others set up a Core Infrastructure Initiative to try to prevent a problem like that from happening in the future.

A widespread audit of GNU Bash seems a natural fit for the Initiative's next target. As Graham says, part of the solution is to clean up the technical debt of these core projects, bringing them up to modern standards.

Until then system admins, major corporations and operating system vendors and distributions will continue to try to plug the holes as they find them.

In the meantime, a repository of Shellshock "proof of concept" code is on GitHub. This shows software maintainers and system admins from other projects what they need to do — and hopefully prevent further pwnage.

BONUS: What is Shellshock?