Paillier is a CPA-secure cipher, thus anything we can deduce from ciphertexts requires the private key. Thus "I want to find…" requires that "I" has the private key, and then "I have an encrypted array" implies "I" can decipher each of the ciphertexts, which makes the question as stated moot.
We'll therefore change the problem statement to: we have at most $k$ small integer $m_i\in[0,\ell)$ (in the problem at hand we want $k\ge6$, and $\ell>20$); and we want a public method to express these $m_i$ encrypted as $c_i$ using the Paillier Cryptosystem, and combine the $c_i$ into a single $c$ as we do in Paillier. That is making a product modulo $n$ of the $c_i$, and optionally multiply modulo $n$ by a ciphertext for $0$ to further mask the outcome. We want things so that a person holding the private key can determine from $c$ if $0$ was present in the initial data set of $m_i$. That changes two important things in the initial problem statement:
- There's this notion of combining the ciphertexts $c_i$ into $c$, with the $c_i$ unavailable to the holder of the private key.
- We do not "have an encrypted array". We want to have one, but are free to define how it's made, as long as that's with an encryption that uses Paillier. Without such freedom, there is no solution, because Paillier decryption will only let one obtain $m=(\sum m_i)\bmod n$ and there's no way to tell from that if an $m_i$ was $0$.
Here is something where we'll not only know if $0$ was present in the $m_i$, we'll also know how many times each integer in $[0,\ell)$ was present in the original array.
Towards this, we encode $m_i$ into $m'_i=(k+1)^{m_i}$ before applying Paillier encryption. Paillier will let us combine the ciphertexts $c_i$ then decipher the combination $c$ into $m'=(\sum m'_i)\bmod n$. From $m'$ we can deduce how many time each integer in $[0,\ell)$ was present in the $m_i$, as long as $k(k+1)^{\ell-1}<n$, by expressing $m'$ in base $k+1$ and looking at the digits/limbs. I'll skip the algebra for how, and use an example in decimal (thus $k=9$). $m_0=2$, $m_1=4$, $m_2=5$, $m_3=10$, $m_4=0$, $m_5=20$ encodes to $m'_0=100$, $m'_1=10000$, $m'_2=100000$, $m'_3=10000000000$, $m'_4=1$, $m'_5=0$, $m'_6=100000000000000000000$ in decimal. We'll get $m'=1000000000010000110101$, from which we can tell there was exactly one each of $0$, $2$, $4$, $5$, $10$, $20$ in the original array of $m_i$, by looking at the position of the non-zero digits and seeing they are $1$. If the $20$ was changed to $0$, the outcome would be $m'=10000110102$ and we'd know there was two $m_i=0$, because the rightmost digit is $2$.
The question does not tell what we don't want the holder of the private key to be able to determine from $c$. Perhaps we want to restrict that to determining if there was a $0$, with as little leakage about how many $0$ as possible.
Towards this, we can encode each $m_i\ne0$ to $m'_i=0$, and each $m_i=0$ to some integer $m'_i$ in $[1,\lfloor n/k\rfloor)$ picked at random with a distribution heavily biased towards low values. When the decryption of the combination is zero, it's known there was no zero in the $m_i$, and nothing else. Otherwise, it's known there was a zero, and it is leaked little information about how many. The distribution can be optimized towards minimizing that leakage, this is left as an exercise to the reader.
It's possible to refine things so that one with the private key and $c_i$ can find $m_i$, yet (as above) one with the private key and $c$ can get little information about the $m_i$, beyond that one is $0$. I won't detail because that's not in the problem statement.
As many homomorphic encryption things, these are nice theoretical systems with little matching real-life problems.
