Daniel Kahn Gillmor reported on gnupg-devel this bug:
[...]
At the bottom of this message are two copies of the same key. The first
copy has an indication that my key (D21739E9) is allowed to revoke
certifications by it. The second copy has a deliberately broken (that
is, not cryptographically-valid) revocation certification, indicating
that a key with fingerprint 0x000...001 is allowed to revoke it. I
created this bogus version by just swapping out the fingerprint bytes in
the signature made over the primary key.

If the local keyring has the bogus version installed, then importing the
good key will fail to update gpg's revoker information.

That is, save the two versions of the key below as bogus.key and
good.key compare the output of:

gpg --delete-key C108E83A
gpg --import bogus.key
gpg --import good.key
gpg --list-keys --with-colons C108E83A

with:

gpg --delete-key C108E83A
gpg --import good.key
gpg --import bogus.key
gpg --list-keys --with-colons C108E83A

The final versions should be identical, but (at least for me, with gpg
versions 1.4.10 and 2.0.14 on debian testing) the former shows no rvk:
line, while the latter shows an rvk: line.

Compare also the output of "gpg --export C108E83A | gpg --list-packets"
with these two states. It appears to be "first revocation certification
received wins", even if one of them is cryptographically unsound.

This is a potential security problem, because it suggests that a
malicious user could block the distribution of revocation indicators. A
user who relies on published revocation certifications may not have them
treated properly if a malefactor produces a modified or simply corrupt
revocation certification that somehow overrides the first.

It appears that fetching the good key material from the keyservers does
not fix the problem either.