The recently announced Rails vulnerability is a bad one — probably gives an exploiter ability to execute arbitrary ruby code on your server, which basically means to execute arbitrary commands on the shell. Which often can be escalated to all sorts of other stuff.
And this looks to be the sort of vulnerability for which attackers can easily write port-scanners to just scour the net for exploitable apps — it exists in most any Rails app, exploitable in a generic way. You’ve got to patch your apps. Here’s a scary comment on hacker news trying to drive that home too.
If you are on Rails 3.0, 3.1, or 3.2, fixing this can be as easy as bundle update, check in Gemfile and redeploy. If you are on Rails 2.3 pre-bundler, updating Rails to latest patch release in production can be more of a pain — but there’s still 2.3 version relased to update to.
If you are pre Rails 2.2, you are still vulnerable but you don’t have a release to update to, you’re going to have to figure out what to do. It seems like you can probably be fine by following the workaround instructions to simply disable xml/yaml params parsing (it’s highly unlikely your app uses these features, if it does, then you’re REALLY out of luck) — but the announcement doesn’t at present give tested instructions for how to do this in various rails versions, might take some investigation.
You’ve really got to do this to every app, even weird out of the way ones that seem unimportant and don’t do anything that matters — the vulnerability could mean that app is providing a hole onto one of your servers inside your firewall.
If you don’t even know if you have such apps running, or have inherited apps from predecessors without documentation or current staff competence in maintaining, and you don’t know where to find the source or how to redeploy or anything about rails and you have no idea where to begin…. oh boy, I mention this because one of my nightmares is that I’m some day going to leave such a pile-of-doo for the future at my organization. I do my best not to, but in the end it’s an organizational issue not a personal one, our organizations have got to start acting like competent IT organizations which don’t bite off more than they can chew and fund IT operations adequately to reliably and securely support what’s being asked of them. And university libraries just plain don’t. And some day, they’re all going to reap the consequences. And then decide “See, this is why we shouldn’t do any IT inhouse, but just buy black boxes from vendors the end.” Which will only hasten the irrelevance and disappearance of libraries.
Okay, my rant went a bit off track there (erm, off the rails?).
Anyhow, while this Rails security vulnerability is bad, I don’t think it should probably be taken to mean that Rails is inherently less secure than anything else, or that Rails made a mistake larger than other similar products have and will make. Except that Rails is popular, so a target for attackers.
Bibliographic Wilderness 
No Rails here, but Drupal is in use – which has had its own long string of vulnerabilities.
A big ACK to your “university libraries” bit; absolutely true. And when they do decide to go with just black boxes, there will of course be security vulnerabilities in those too, but doing anything about the problems will be entirely out of their control.
Sadly, I think in many organizations, it’s more of a priority to have problems be “not our fault/problem”, then it is to minimize problems. Better to have more problems that all are ‘not our fault’ than fewer that may be.