One of the core issues here was a serialization library that was too convenient, with the ability to deserialize into arbitrary classes and end up executing code from them. In the Python world, this vulnerability has been a bit better known for a while (which is not to say that they are immune, but it's at least been common community knowledge for a very long time now, at least a decade). Pickle is well-known to have it, but it's frequently pointed out in the docs that it is possible and that you shouldn't unpickle things from users. But other libraries may have this too, and if Django uses them, have a poke around. JSON libraries would be one obvious point. There's probably some extant Perl vulnerabilities in this area too. PHP wouldn't surprise me (though it would be a particular framework and probably not the language as a whole).
I doubt it's an issue of Python community vs Ruby community. Instantiating arbitrary objects is the sort of feature I'd expect an object serialization library to have, but not a document serialization library. Pickle is clearly an object serialization library, and I would have naively assume that YAML is a document serialization format, but apparently either the authors of the Ruby YAML parser or the creators of YAML don't see it that way, and see YAML as an object serialization format that is by default permitted to specify arbitrary objects to instantiate.
Python's YAML library is also capable of serializing python objects[1]. My understanding is the YAML spec allows these extensions but does not require them.
If you are using PyYaml.Loader instead of PyYaml.SafeLoader for anything coming from a user, you are at risk of this problem.
I'd be surprised if there wasn't at least one reasonably major PHP framework with similar sorts of vulnerabilities: while PHP's JSON decoder should be safe (it can't create any objects other than stdClass objects, which are simple property buckets), the use of unserialize() in older frameworks was rife (mostly due to a lack of alternatives), and that's definitely not safe with arbitrary user data -- as we've seen with the RoR issues, it only takes one code path where user data unexpectedly gets in somewhere it shouldn't.
AFAIK, the only way this could be an issue with the language is if you use serialize/unserialize, which can be used on classes. It goes without saying that this can be useful in certain contexts - such as file-based caching - but should not be relied upon too heavily.
I cannot remember the last time I came across a php project that did something similar.
