The described attack is not easy to understand and as of today the
gpg.fail website seems to have the same content as the draft we
received on 2025-10-23. There it states:

In the interest of a timely disclosure, we cannot provide an
refined end-to-end demonstration of the issue. However, under the
following assumptions we can demonstrate relevant parts of the
attack.

From what I can read from it the enabler of the attack is:

• Mallory sends Bob the modified message, asking for a signature on the public key — a common not suspicious action for PGP users.

• Bob decrypts and signs the apparent public key, and publishes the signature along with the public key to a keyserver.

However, Bob ignored that the decryption failed and thus signs
something which he can't be sure what he is signing! The whole idea
of authenticated encryption (AD - either using CFB+MDC or OCB)
is to detect such a modified encrypted message. If this is ignored we
are back to unauthenticated encryption. The attack description
further states:

Packets can be modified by an attacker to output a failure that
aappears harmless to the user, such as truncation, and GnuPG
violates this requirement in two dangerous ways:

- Packets can be modified by an attacker to output a failure that
  appears harmless to the user, such as truncation, and

- it does not discard inputs known to be a security problem and
  continues processing the data.

The "appears harmless to the user" requires social engineering to
discuss the

gpg: decryption failed: Invalid packet

away. It is correct that we see here "invalid packet" and not a

gpg: WARNING: message was not integrity protected
gpg: decryption forced to fail!

The reason for this is that we have a bunch of failure modes and we
don't want to get the user accustomed to this warning. This warning
shall only show up if a message was really modified and not in case of
a simple truncation.

The second point "does not discard" the data is a misunderstanding on
how Unix tools work. A Unix tool does not necessary write to a file
but in many cases works in a pipeline and thus can't discard data it
has already written to the output. Only after all data has been
processed a claim can be made whether the data was good. A frontend or
GUI however can do that. For example Kleopatra ask the user whether
to save a decrypted file - this uses a renaming strategy.

Thus, unless I have a major misunderstanding, I do not see any bug here.