I like a memory-safe language as much as the next person, but software security really is an open-ended problem. My language may prevent me from making a string that overflows its memory, but if the string I'm building happens to be a SQL query, my code could still to vulnerable to SQL injection. Of course there are several ways to build SQL interfaces which don't allow unchecked strings as queries.
The point is that the SQL injection vulnerability is completely analogous to the string overflow vulnerability. Strings were originally implemented as abstractions in languages which had no concept of "string". There have been many such implementations of strings, and a good fraction of them are not memory safe. But now we also have languages which implement memory-safe strings as an abstraction of the language. And people have used these languages to implement a new abstraction, SQL. Again, there are many implementations. Some are safe from SQL injection. Some are not. The ones which are not safe actually may be simpler to use from a naive point of view - like just building a string and passing it to a function. Some programmers may find that more appealing than an API which requires multiple calls or multiple parameters to make a query. It doesn't require them to learn a new abstraction.
Software security problems will always exist, as long as we continue to build higher-level abstractions with APIs which allow the abstraction to be subverted. Even when you have a safe API to a new abstraction, there's an excellent chance someone will come along an implement a "simpler" API, which is simpler mostly because it is vulnerable.