I completely agree: It's a stupid bug that lingered long in the codebase, probably because it was hidden in an obscure feature that nobody knew about or used. It's embarrassing, but I bet that pretty much every larger framework out there had a remote code execution bug[1]. Still, it's wrong to point at it and say "that's an engineering or QA bug that's symptomatic for the rails bunch." I'm not a rails friend, but the response showed that the rails developers take security and QA serious. Patches and workarounds were released not only for the supported versions, but also for older, long-dead releases.
I bet that pretty much every larger framework out there had a remote code execution bug[1].
I would gladly take the other side of that bet.
A decade ago I was working on a site using Perl/Mason/Apache. When we were bought by eBay, we were put through a thorough pen test. The ONLY security hole they identified as needing fixing was a redirect that could redirect to any URL anywhere. (The people testing us were shocked - they had never before seen that few problems.)
To the best of my knowledge, no holes have been discovered in that architecture in the following decade either. (Looking through Apache vulnerabilities, there have been a couple of remote code exploits. But not on all platforms, and we turned off every feature we didn't need.)
If you take the attitude up front that you won't have magic, this kind of bug doesn't tend to slip in. If you take the attitude that there will be a lot of magic, then this kind of bug does slip in.
You admit that the framework you used had a couple of exploits and you were not affected because you turned of all features that you didn't need. The current rails vulnerability does not affect you if you turned off all features you didn't need. Same argument. So we have a hole in Mason, I already cited one in Spring, someone else cited one in .NET http://news.ycombinator.com/item?id=5043839.
[1] Sinatra didn't, but that's < 1000 LOC.