Changing languages will absolutely save you from classes of security holes. Java programmers do not have to keep a working model of object memory lifecycles in their head to build safe programs. C programmers, on the other hand, still do have to care about the metacharacters of the HTML DOM and SQL. In fact, because it's a bitch to rewrite retained char* strings in place without pegging malloc() to the top of your gprof profile, C programs are actually slightly more prone to the kinds of security holes you're implying plague languages like Java.
Even if you stretch to find a class of flaw that only affects a language like Perl (for instance, the ease with which Perl allows you to write code where metacharacters will allow an attacker to stuff commands into a shell), you simply have to go back 10 years or so to see the 8lgm posts that did the same thing to C programs all over the Internet.
And yet, this still ignores the rather amusing fact that the more libraries and VMs and whatnot in between you and the computer hardware, the more chances your program will suffer a security hole because of a mistake in one of those libraries. Not too long ago someone found a bug in PHP that would cause it to go into an infinite loop if you put in a wrong number. These kinds of things happen, so if your going to write secure code, the only thing that will save you is being really good at writing secure code on whatever platform you are choosing to write code for. The only thing that changes is the types of security holes you have to worry about. Instead of buffer overflows, you have to know that function x does x and in some cases function y is more secure but only if there's a solar eclipse, etc. The higher level language you use, the more complexity the system has, which increases the possible security flaws even as the languages reduces other security flaws. The end result is simply that any given language will move the problem around, not actually solve it.
The bug you're talking about is a result of C code. I'm not sure what point you're hoping to make by observing that the C code underpinning high level languages is prone to vulnerabilities; I feel like that point is rather more supportive of my argument.
Even if you stretch to find a class of flaw that only affects a language like Perl (for instance, the ease with which Perl allows you to write code where metacharacters will allow an attacker to stuff commands into a shell), you simply have to go back 10 years or so to see the 8lgm posts that did the same thing to C programs all over the Internet.