Not necessarily - it depends on the language and how closures are implemented.
For example in Java, closures, created via lambda expressions or anonymous classes, can only access immutable ("final") variable in their enclosing scope. (At least that was true in Java 8, not sure if that was relaxed later.) So they don't export mutability of local variables. (Although they don't prevent you from mutating object fields from with a closure - again, a consequence of the host language semantics.)
Of course, closures in other imperative languages often violate FP immutability constraints. But that's only because they're given unrestricted access to the underlying imperative language features.
An interesting case is OCaml, which allows closures to mutate ref cells, e.g.:
let x = ref 5 in
let set y = x := y in
set 4;
x;;
...which outputs 4. This is compatible with OCaml's approach to mutation, and the mutable variable is at least not the default variable type - it's an explicitly mutable cell value. But this certainly breaks various good properties that immutability provides.
For example, the function `set` above provides no indication at the type level that it performs a side effect, which undermines the ability to reason about function behavior without examining the implementation.
If you want to say OCaml is only providing an FP facade which is broken by this behavior, I'm sure many Haskell programmers would agree with you. :)
Btw here's a relevant article, "Closures don't mean mutability": http://blog.agiledeveloper.com/2017/01/closures-dont-mean-mu...