CVE-2019-13050

mediumpriority · track · 31EPSS 0.025 · 85 %ileDEEURUUS

grimoire priorityP3 · Track

Exploitable?

—

no known exploitation

Likely / severe?

2.52% (85th) EPSS

CVSS 5 · medium

Is it mine?

41 products

Check your exposure

Who says so?

6 sources

cnnvd · enisa_euvd · fstec_bdu · cert_bund

EPSS · scored 2026-10-27

Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes it risky to have a GnuPG keyserver configuration line referring to a host on the SKS keyserver network. Retrieving data from this network may cause a persistent denial of service, because of a Certificate Spamming Attack.

remediations

Vendor fix, mitigation, or workaround guidance, as published by each source.

A vendor fix is available.

Fixedgnupg2-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-0:2.2.20-2.el8.src as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debuginfo-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debuginfo-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debuginfo-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debuginfo-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debugsource-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debugsource-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debugsource-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-debugsource-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-debuginfo-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-debuginfo-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-debuginfo-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Fixedgnupg2-smime-debuginfo-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258
https://access.redhat.com/errata/RHSA-2020:4490
Workaroundgnupg2-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-0:2.2.20-2.el8.src as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debuginfo-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debuginfo-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debuginfo-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debuginfo-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debugsource-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debugsource-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debugsource-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-debugsource-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-debuginfo-0:2.2.20-2.el8.aarch64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-debuginfo-0:2.2.20-2.el8.ppc64le as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-debuginfo-0:2.2.20-2.el8.s390x as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.
Workaroundgnupg2-smime-debuginfo-0:2.2.20-2.el8.x86_64 as a component of Red Hat Enterprise Linux BaseOS (v. 8)redhat_csaf
As per upstream: High-risk users should stop using the keyserver network immediately. 1. Open ~/.gnupg/gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. 2. Open ~/.gnupg/dirmngr.conf in a text editor. Add the line "keyserver hkps://keys.openpgp.org" to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence. For installations which are currently rendered unusable by this attack, the following repair method is advised: 1. If you know which certificate is likely poisoned, try deleting it. Once the installation becomes usable again, you can acquire a new unpoisoned copy of the certificate and re-import it. 2. If you do not know which certificate is poisoned, best option is to get a list of all your certificate IDs, delete your keyrings completely, and rebuild from scratch using known-good copies of the public certificates.

cvss

Technical severity, 0–10. One row per scoring source.

7.5

010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 5–7.5

v2.05mediumAV:N/AC:L/Au:N/C:N/I:N/A:Pprimary · NVD / NIST USexploitability 10 · impact 2.9

v3.17.5highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hprimary · NVD / NIST USexploitability 3.9 · impact 3.6

v3.06.5mediumCVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:Hsecondary · Red Hat Product Security US

v3.17.5highAV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsecondary · FSTEC (BDU) RU

v3.16.9mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:Usecondary · CVSS-BT (t0sche)

weaknesses

The CWE weakness classes this flaw belongs to.

CWE-295USprimaryCWE-297USCWE-297US

affected products (41)

Products and version ranges known to be affected.

IBM InfoSphere Information Serverall versionscert_bundDEcpe:/a:ibm:infosphere_information_server:-
IBM QRadar SIEM 7.3all versionscert_bundDEcpe:/a:ibm:qradar_siem:7.3
IBM QRadar SIEM 7.4all versionscert_bundDEcpe:/a:ibm:qradar_siem:7.4
IBM QRadar SIEM 7.5.0all versionscert_bundDEcpe:/a:ibm:qradar_siem:7.5.0
n/a n/a≤ n/aenisa_euvdEU
Fedora Project Fedora≤ 30fstec_bduRU
Fedora Project Fedora≤ 29fstec_bduRU
Novell Inc. OpenSUSE Leap≤ 15.1fstec_bduRU
Novell Inc. OpenSUSE Leap≤ 15.0fstec_bduRU
Novell Inc. SUSE Linux Enterprise Module for Basesystem≤ 15 SP1fstec_bduRU
Novell Inc. SUSE Linux Enterprise Module for Basesystem≤ 15fstec_bduRU
Сообщество свободного программного обеспечения GNU Privacy Guard (GnuPG)≤ 2.2.16fstec_bduRU
Сообщество свободного программного обеспечения SKS Keyserver≤ 1.2.0fstec_bduRU
f5 traffix signaling delivery controller5.0.0 → 5.1.0nvdUScpe:2.3:a:f5:traffix_signaling_delivery_controller:*:*:*:*:*:*:*:*
fedoraproject fedora= 29nvdUScpe:2.3:o:fedoraproject:fedora:*:*:*:*:*:*:*:*
fedoraproject fedora= 30nvdUScpe:2.3:o:fedoraproject:fedora:*:*:*:*:*:*:*:*
gnupg gnupg≤ 2.2.16nvdUScpe:2.3:a:gnupg:gnupg:*:*:*:*:*:*:*:*
opensuse leap= 15.0nvdUScpe:2.3:o:opensuse:leap:*:*:*:*:*:*:*:*
opensuse leap= 15.1nvdUScpe:2.3:o:opensuse:leap:*:*:*:*:*:*:*:*
sks keyserver project sks keyserver≤ 1.2.0nvdUScpe:2.3:a:sks_keyserver_project:sks_keyserver:*:*:*:*:*:*:*:*

showing 20 of 41

advisories (2)

Vendor and ecosystem advisories describing this.

RHSA-2020:4490Red Hat Security Advisory: gnupg2 security, bug fix, and enhancement update2020-11-04csaf · redhat_csafUS
An update for gnupg2 is now available for Red Hat Enterprise Linux 8. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.
WID-SEC-W-2025-0227IBM QRadar SIEM: Mehrere SchwachstellenDeutsch2021-11-30csaf · cert_bundDE
Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in IBM QRadar SIEM ausnutzen, um seine Privilegien zu erweitern, Administratorrechte zu erlangen, beliebigen Programmcode auszuführen, Informationen offenzulegen, Dateien zu manipulieren oder Sicherheitsvorkehrungen zu umgehen.

also known as (4)

Other names and identifiers for this entity.

sources

Which sources assert this record, and when.

cnnvd enisa_euvd fstec_bdu cert_bund nvd redhat_csaf NVD CVE.org MITRE

published 2019-06-29modified 2026-06-17

related (1,894)

Related entries.

ID	severity	EPSS	exploitable	published
CVE-2026-85102US	—OT critical	54.1% (99th)	KEV	2026-09-09
Improper certificate trust validation during VPN negotiation in Check Point Quantum Security Gateway may allow an unauthenticated remote attacker to execute arbitrary code on the G…
CVE-2023-41991US	medium5.5OT critical	13.4% (96th)	KEV	2023-09-21
A certificate validation issue was addressed. This issue is fixed in macOS Ventura 13.6, iOS 16.7 and iPadOS 16.7. A malicious app may be able to bypass signature validation. Apple…
CVE-2023-20963US	high7.8OT critical	1.47% (74th)	KEV	2023-03-24
In WorkSource, there is a possible parcel mismatch. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed…
CVE-2022-26923US	high9.0OT critical	83.5% (100th)	KEV	2022-05-10
Active Directory Domain Services Elevation of Privilege Vulnerability
CVE-2022-20703US	high8.0OT critical	9.20% (95th)	KEV	2022-02-10
Multiple vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers could allow an attacker to do any of the following: Execute arbitrary code Elevate pr…

+1889 more

references (72)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan