• Out ticket: https://dev.gnupg.org/T7908
• Status: Not a security vulnerability (social engineering and UI changes would be required; see note above)
• Description: In PGP compatibility mode, and when no explicit command is specified, GnuPG may adopt a filename from the Literal Data packet. For this reason, it has long been recommended to invoke gpg with an explicit command and to specify the target filename explicitly.
• Prerequisites: Users must be persuaded to trust the suggested filename.
• Assessment: The filename contained in the Literal Data packet is advisory only. It is not enforced and does not replace an explicitly specified output filename.

Originally, PGP automatically stored files using the filename provided in the Literal Data packet and would overwrite existing files if necessary. This behavior could lead to security issues.

GnuPG deliberately changed this behavior. When gpg is invoked without an explicit command or output filename, it does not overwrite existing files automatically. Instead, GnuPG explicitly asks whether an existing file should be replaced:

File 'test.txt' exists. Overwrite? (y/N)

The default response is explicitly “N” for “No”. If the input is confirmed or “N” is selected, GnuPG prompts for a new filename. This prevents accidental overwriting.

Apart from this, earlier OpenPGP specifications did not include the filename as part of the signature. In the current LibrePGP specification, however, the filename is covered by the signature—a behavior that GnuPG fully supports. Even in this case, the filename remains advisory and does not constitute a binding instruction.

For this reason, we continue to recommend invoking gpg with an explicit command (for example, --decrypt) and specifying the output filename explicitly.

• Out Ticket: https://dev.gnupg.org/T7909
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Description: This issue describes that, when using cleartext signatures, the plaintext used for hash computation may differ from the text displayed by simple tools such as cat. The content produced by gpg --output, however, always corresponds to the plaintext that was actually signed.
• Prerequisites: Users rely on the plaintext displayed by cat and do not verify the content that was actually signed.
• Assessment: Signature verification itself is correct. Any difference is a result of comparing the wrong output.

Relying solely on the output of cat is inherently unsafe, as cat doesn't always display everything that is actually contained in a file. Even using cat -v would have made additional control characters visible and shown that the displayed text does not match the actual content.

Using gpg --output, as recommended, would have reliably prevented this scenario (see above).

• Our ticket: https://dev.gnupg.org/T7907
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Summary: Users must ignore an error message issued by gpg (“decryption failed”) and then continue to process or even sign the resulting output.
• Description: It is claimed that an attacker could craft manipulated encrypted messages in such a way that usable plaintext is produced despite a decryption error.
• Prerequisites: Recipients ignore an explicit error reported by gpg and continue working with the output anyway.
• Assessment: Under these conditions, this is not a security vulnerability.

1. Claim according to gpg.fail

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. In combination with the buggy code pointed out above, we believe that there is sufficient risk of a serious vulnerability to warrant investigation and fixes by GnuPG maintainers.

We assume that:

• We have access to the encrypted data
• The encrypted data is exactly 64 bytes of total entropy
• Bob uses GnuPG 2.4.8
• Bob has no non-standard config and uses head -c64 /dev/urandom | gpg -e -r online to encrypt his data

2. Described attack scenario

To illustrate the claimed impact, the website describes an attack scenario.

Mallory is an attacker who either later gets access to an encrypted message, or as as an active MITM. Mallory's goal is to decrypt an encrypted message that Alice encrypted for Bob.

• Alice has Bob's public key
• Alice encrypts the plaintext "SECRET" to Bob's public key, and sends the ciphertext as a PGP message to Bob.
• Mallory gets access to the encrypted message, and would like to decrypt it, so Mallory modifies the message to be a public key.
• 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.
• Mallory fetches the key from the keyserver and retrieves the accidentally decrypted plaintext

3. Constraints and assumptions of the attack

Based on the description provided, the attack essentially relies on Mallory sending Bob a manipulated message and asking him to sign what appears to be a public key—a request that is common for PGP users and does not appear suspicious. Bob decrypts the apparent public key, signs it, and publishes the signature together with the public key on a keyserver.

However, Bob ignores the fact that the decryption has failed and proceeds to sign something without being certain what he is actually signing. The purpose of authenticated encryption (AE)—either via CFB+MDC (since version 1.0.2 in 2000) or OCB (since version 2.3.0 in 2021)—is precisely to detect such modified encrypted messages.

4. Further claims regarding error handling and assessment

The attack description further states:

1. Packets can be modified by an attacker to output a failure that appears harmless to the user, such as truncation, and
2. it does not discard inputs known to be a security problem and continues processing the data.

This scenario assumes that a clear error message issued by gpg is deliberately downplayed or ignored. The message referred to here is:

gpg: decryption failed: Invalid packet

Calling such a failure “harmless to the user” therefore relies on social engineering—specifically on persuading users to dismiss or disregard an explicit error message.

The claim that GnuPG does not discard problematic input is also based on a misunderstanding of how Unix tools operate. A traditional Unix tool does not necessarily write directly to a file, but often works as part of a pipeline. Data that has already been written to the output cannot be retracted afterward. Only after processing has completed can it be determined whether the data as a whole was valid.

Specialized applications or graphical user interfaces can behave differently in this regard. They buffer the decrypted data in full and prompt the user before saving it. This ensures that faulty data is not reused.

Under these conditions, this is not a security vulnerability.

• Our ticket: https://dev.gnupg.org/T7906
• Status: Fixed on November 6, 2025 for VSD, on November 19, 2025 for 2.5, and on December 30, 2025 for 2.4
• Description: This issue allows at most a single byte to be overwritten. That byte could affect the beginning of the next block on the heap and potentially alter the tag typically stored there.
• Assessment: Depending on the specific malloc(3) implementation, it might have been possible to construct an exploit from this around 20 years ago. Today, this is no longer feasible. Modern malloc implementations consistently validate pointers and sizes and abort the process immediately when inconsistencies are detected.

Even if it were possible to deliberately influence the next block on the heap, this would still not allow code execution, for example via free() (see “Vudo Malloc Tricks”, Phrack #57, 2001, [https://phrack.org/issues/57/8.html](https://phrack.org/issues/57/8.html)).

• Assessment: The observations mentioned in this context relate to minisign, not to GnuPG. They affect neither the functionality nor the security of GnuPG and therefore fall outside our area of responsibility.

• Our ticket: https://dev.gnupg.org/T7901
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Assessment: The affected functionality was marked as obsolete in GnuPG 2.5.16. It can now only be checked using a dedicated flag and was part of a release process that is no longer in use today.

• Our ticket: https://dev.gnupg.org/T7902
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Description: In the described scenario, the format of a cleartext signature is manipulated by inserting an additional hyphen in the header: -----BEGIN PGP SIGNED MESSAGE------
• Prerequisites: Users do not verify the signed output and accept the manipulated structure.
• Assessment: The described confusion relies on social engineering and results from a use of cleartext signatures that is not intended.

Additional Technical Context

For this scenario to work, users must inspect the input data without noticing that the header of the cleartext signature has been slightly but deliberately modified. An additional hyphen can easily go unnoticed.

For this reason, users should not rely on the input data itself, but verify the output produced by gpg. Using the --output option ensures that the verified content is actually processed.

• Our ticket: https://dev.gnupg.org/T7909
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Description: In this scenario, the encrypted data itself contains a forged success message that appears to indicate a successful signature verification by gpg.
• Prerequisites: Users rely on this message instead of checking the actual result of the signature verification.
• Assessment: The misleading effect relies on targeted social engineering and on failing to verify the signed output. There is no flaw in the signature verification itself.

• Our ticket: https://dev.gnupg.org/T7900
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Description: In the described scenario, the appearance of a valid cleartext signature is created even though the content that is actually verified differs.
• Prerequisites: Users look at the original input rather than the output validated by gpg during signature verification.
• Assessment: The misleading effect arises solely from not considering the verified output of the signature check. It relies on targeted social engineering and on a use of cleartext signatures that is not intended.

• Our ticket: https://dev.gnupg.org/T7905
• Status: Not a security vulnerability (social engineering, improper use of cleartext signatures, and UI changes would be required; see note above)
• Description: In the described scenario, data is manipulated so that signed and unsigned data appear side by side.
• Prerequisites: During decryption, users ignore an error message issued by gpg and nevertheless rely on the displayed data.
• Assessment: Successful exploitation requires that the reported error message is deliberately ignored.

• Our ticket: https://dev.gnupg.org/T7904
• Status: Fixed on October 22, 2025
• Description: Due to a bug, GnuPG could downgrade the hash algorithm in use to SHA-1.
• Assessment: This was a genuine bug. However, exploiting this issue would require a second-preimage attack against SHA-1. Such an attack is currently not feasible for SHA-1.

• Status: Not a security vulnerability (social engineering; see note above)
• Description: In the described scenario, manipulated trust packets in a keyring could cause additional subkeys to be taken into account.
• Prerequisites: Users must be induced to execute a malicious command on the command line that they do not understand.
• Assessment: The attack requires users to import a manipulated keyring from an external source and then use it for cryptographic operations, encrypting with deliberately altered certificates contained in that keyring.

Public keys or certificates are exchanged individually. Entire keyrings are not. The described scenario therefore depends on targeted social engineering and requires command-line usage outside the intended scope.

• Assessment: The observations mentioned in this context relate to minisign, not to GnuPG. They affect neither the functionality nor the security of GnuPG and therefore fall outside our area of responsibility.