CVE-2019-13050

mediumPriorität · verfolgen · 31EPSS 0.025 · 85. PerzentilDEEURUUS

grimoire priorityP3 · Track

Exploitable?

—

no known exploitation

Likely / severe?

2.52% (85th) EPSS

CVSS 5 · medium

Is it mine?

41 products

Prüfe deine Angriffsfläche

Who says so?

6 sources

cnnvd · enisa_euvd · fstec_bdu · cert_bund

EPSS · bewertet 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.

Behebungen

Hersteller-Fix, Mitigation oder Workaround, wie von den Quellen veröffentlicht.

Ein Hersteller-Fix ist verfügbar.

Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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
Behobengnupg2-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

Technischer Schweregrad, 0–10. Eine Zeile je Quelle.

7.5

010

Basiswert 0–10 · höher = schwerwiegender · Vektor überfahren zum Auflösen⚠ Quellen uneinig · medium–high · 5–7.5

v2.05mediumAV:N/AC:L/Au:N/C:N/I:N/A:Pprimary · NVD / NIST USAusnutzbarkeit 10 · Auswirkung 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 USAusnutzbarkeit 3.9 · Auswirkung 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)

schwächen

Die CWE-Schwächeklassen, zu denen dies gehört.

CWE-295USprimärCWE-297USCWE-297US

betroffene Produkte (41)

Betroffene Produkte und Versionsbereiche.

IBM InfoSphere Information Serveralle Versionencert_bundDEcpe:/a:ibm:infosphere_information_server:-
IBM QRadar SIEM 7.3alle Versionencert_bundDEcpe:/a:ibm:qradar_siem:7.3
IBM QRadar SIEM 7.4alle Versionencert_bundDEcpe:/a:ibm:qradar_siem:7.4
IBM QRadar SIEM 7.5.0alle Versionencert_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:*:*:*:*:*:*:*:*

20 von 41 angezeigt

Advisories (2)

Hersteller- und Ökosystem-Meldungen dazu.

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.

auch bekannt als (4)

Weitere Namen und Kennungen dieser Entität.

quellen

Welche Quellen diesen Datensatz belegen und wann.

cnnvd enisa_euvd fstec_bdu cert_bund nvd redhat_csaf NVD CVE.org MITRE

veröffentlicht 2019-06-29geändert 2026-06-17

verwandt (1,894)

Verwandte Einträge.

ID	Schweregrad	EPSS	ausnutzbar	veröffentlicht
CVE-2026-85102US	—OT kritisch	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 kritisch	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 kritisch	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 kritisch	83.5% (100th)	KEV	2022-05-10
Active Directory Domain Services Elevation of Privilege Vulnerability
CVE-2022-20703US	high8.0OT kritisch	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 weitere

Referenzen (72)

Externe Belege — Patches, Meldungen, Analysen.

scry

Angreifer nutzen Schwachstellen wie diese gegen im Internet exponierte Dienste aus. Sehen Sie mit einem kostenlosen Passiv-Scan, was exponiert ist.

Kostenloser Scan