If I'm understanding right, the Equifax vulnerability was CVE-2017-5638, where if an invalid Content-Type issue is given, it gets passed to an error-message printing function that searches through the entire provided message for OGNL code (a domain-specific language that apparently can deserialize arbitrary Java objects, or something), and so an attacker can pass OGNL code that spawns an external process in the Content-Type header?

I'd argue that this isn't a language-specific issue at all. It happens to be the case that this is implemented using exception handling in Java, by throwing an object containing the request headers, and having it caught by something that parses the provided message for code. But a language without this type of exception handling, like C or Rust, could have the same issue as easily:

    if (strcmp(request->content_type, "multipart/form-data") != 0) {
        char *error = asprintf("Bad Content-Type header %s", request->content_type);
        log(error);
        free(error);
        return -1;
    }

    void log(char *message) {
        char *ognl = find_valid_ognl(message);
        if (ognl)
            message = evaluate(ognl);
        ...
    }

I doubt that any language can really, fundamentally, save you from wrongly deciding to evaluate untrusted strings. (I do think that the vulnerability here was made more likely by OGNL being able to instantiate arbitrary Java objects and by not distinguishing TrustedString and UntrustedString types, and a good language can gently steer you away from those mistakes, but it won't be able to completely save you.)

I agree that it isn't Java-specific, but Java is affected despite being memory safe and "it's pretty hard to provide malicious input to non-malicious Java source code that takes control over the interpreter" may not be as true a statement as it appears.

That's a fair objection, and I already had to add a caveat about deserialization libraries that can instantiate arbitrary objects. (Which is a problem that affects other memory-safe dynamically-typed languages too, e.g., Python's pickle and yaml modules have the same problems.)

I think there is a meaningful distinction, still, between something like OGNL where the program / library is providing its own interpreter of the EDSL that is excessively capable (which can be done in any language, including Turing-incomplete languages, capability systems, etc.: a library can always dispatch input to whatever functions are available to it) -- i.e., where the programmer intended the functionality that was implemented, they just didn't think through what they were doing -- and things like buffer overflows and ROP where the course of program execution, on the existing interpreter / runtime / platform, is subverted to something the programmer did not intend. I'm not quite sure how to phrase it. (And I'm not sure on which side of the line arbitrary-object deserialization lands.)

I'd phrase it as "Programmers can write vulnerabilities in any language" :-)