They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations.

Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector.

Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.

CCL:

Totals grouped by language (dominant language first):

  lisp:        336793 (84.60%)
  asm:          30410 (7.64%)
  ansic:        29862 (7.50%)
  sh:             718 (0.18%)
  objc:           299 (0.08%)
  java:             7 (0.00%)

> Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C.

Yeah, right.

> Yeah, right.

In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion.

Do you have any arguments other than the unsubstantial "yeah, right"?

Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.