@exoteric: you can't blame programming constructs for malicious behavior - you blame malicious programmers (attackers) and programmers who don't design security into their programming logic/patterns/design/architecture. That said, obviously, direct access to memory and unbounded data structures has led to many, many bad things, but then again, bad people do bad things - the developers who coded the holes aren't malicious or bad programmers (generally...), they just didn't/don't place enough emphasis on security, as they do, say, for performance and reliability...
I'd say it's really more about bad programming behavior (writing exploitable code on the one hand, then doing evil things with the holes on the other) than it is about bad programming language features used to write unsafe code that is then exploited by malicious developers for nefarious reasons...
That's why malicious is in quotes in the title and this thread is about what causes problems in practice, when being used by human beings, and not about what works in theory, if programmers were as reliable as computers.
The entire first post should be read to understand that.
No one tool serves all purposes but if a tool is involved in many incidents, when used by its intended users, perhaps that observation is worthy of reflection.
The post is meant to inspire a discussion about language design and on what features cause problems in the wild - an entirely pragmatic view. API design might be relevant insofar as it shows significant pitfalls of the language, as commonly used, in this sense.