You can call everything everything - in 2021, all of our components (CPUs, machine code, compilers, interpreters) share so many aspects, that you'll find an argument in almost any direction. Maybe it would not be quite wrong to call a CPU an interpreter, but I feel it would be very weird and discount what actual interpreters are about in the first place.
An all-purpose CPU stupidly executes its instructions. If we ignore advanced current-days aspects of lookahead and heavy parallelization - i.e., think of an old, extremely simple, 6502 CPU instead of a current Intel or ARM offering - then you see that the CPU looks at one specific point in RAM or ROM, fetches one instruction, then executes that extremely simple instruction. There is nothing between this execution and the electrons running around on the hardware - at this low level, the machine code is the electronic layer.
So, no, in general I would say the processor is an executor, not an interpreter.
Modern aspects could change this. For example, you could create a CPU which understands CISC commands, but does this by running a microcode preprocessor inside the CPU which translates those CISC commands into RISC commands, which then are executed on the actual machinery of the CPU. In this case you could say the the CPU interprets CISC code. I would accept this especially in the case that this preprocessor has larger state than just the next command; i.e. if it does complex decisions based on previous and next statements. This also leads to branch prediction, parallelization, power management and so on - complex "management" efforts which may be reordering or optimizing the stream of incoming machine commands. This "preprocessor" then would be an interpreter, shoveling commands to its internal execution engine.
An actual interpreter earns its designation by looping over some more abstract representation of a program (sometimes this can be the source code directly, for example in certain scripting languages close to a shell; sometimes bytecode which can be generated upfront (e.g. Java) or on the fly (e.g. Ruby, Perl)). A common theme is that this bytecode is often compatible between different interpreters; famously you can run Java bytecode anywhere from big servers to embedded little machines, which may have nothing much in common on the machine language level.
Finally, all of this is a moving target anyway, since on each level of abstraction, we are combining all kinds of techniques. Your Java interpreter might have a Just-in-time compiler and your pieces of "bytecode" might in fact just be a compiled-in-the-meantime machine code. Your state-of-the-art CPU might have an interpretion layer for compatibility for some generation of CPU 20 years ago. Your compiler might have a compile-time interpreter able to modify compilation in some way, etc.