Microsoft WinVerifyTrust function: unzureichende Prüfung kryptografischer Signaturen (CVE-2013-3900)
Veröffentlicht Zuletzt geändert In CISA KEV seit Quellen: CVE.org
Was ist betroffen, was ist zu tun
Warum veröffentlicht Microsoft erneut eine CVE aus dem Jahr 2013? Wir veröffentlichen CVE-2013-3900 im Sicherheitsupdate-Leitfaden neu, um die Tabelle der Sicherheitsupdates zu aktualisieren und Kunden darüber zu informieren, dass EnableCertPaddingCheck in allen aktuell unterstützten Versionen von Windows 10 und Windows 11 verfügbar ist. Obwohl das Format sich vom ursprünglich im Jahr 2013 veröffentlichten CVE unterscheidet, bleibt die Information hierin, abgesehen von Klarstellungen zur Konfiguration des EnableCertPaddingCheck-Registrierungswerts, unverändert gegenüber dem Originaltext, der am 10. Dezember 2013 veröffentlicht wurde.
Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. Die vorliegenden Quellen nennen keine Fix-Version. Prüfen Sie die Herstellerhinweise in den Referenzen unten. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.
- Betroffen
- Microsoft Windows Server 2008
eq r2..r2 - Microsoft Windows Server 2012
eq r2..r2
- Microsoft Windows Server 2008
Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen
Metriken
5,5
XIEM Effective CVSS
Höchste verfügbare CVSS-Bewertung aus NVD- und Herstellerangaben.
Quelle: NVD, CVSS v3
5,5
CVSS v3
Schweregrad Mittel auf der Skala von 0 bis 10.
Quelle: CVE.org
44,7 %
EPSS-Score
Erhöht – Modell schätzt 10-50 % Ausnutzungs-Wahrscheinlichkeit.
Quelle: FIRST EPSS, Perzentil 98,8
Alle Metriken anzeigen
- Schweregrad
- Kritisch
Priorität (0–325)
Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?
Im Glossar lesen- 205.58 Methodik
Exploit-Reife
Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.
Im Glossar lesen- aktiv ausgenutzt
XIEM Effective CVSS
XIEM® ist das gestufte Managed-Security-Betriebsmodell von NEOSEC und eine eingetragene Marke der NEOSEC GmbH. Es erweitert klassisches SIEM — die zentrale Sammlung, Normalisierung und Korrelation sicherheitsrelevanter Ereignisse — um Endpunkt-Forensik, Netzwerk-Sichtbarkeit und Täuschungstechnik und führt diese zu drei aufeinander aufbauenden Stufen zusammen: Sentry, Orchestrate und Command.
Im Glossar lesen- 5,5 Methodik
CVSS v3
CVSS ist der weltweit verbreitete, offene Standard zur Bewertung der technischen Schwere einer Schwachstelle auf einer Skala von 0 bis 10. Er beschreibt, wie leicht eine Lücke ausnutzbar ist und welchen Schaden sie anrichten kann — nicht jedoch, wie wahrscheinlich ihre tatsächliche Ausnutzung ist. CVSS und das ergänzende EPSS beantworten bewusst unterschiedliche Fragen.
Im Glossar lesen- 5,5
EPSS-Score
Der EPSS-Score ist der absolute Modell-Output für eine einzelne Schwachstelle: die geschätzte Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen, ausgedrückt als Wert zwischen 0 und 1 (bzw. 0 % bis 100 %). Ein Score von 0,42 bedeutet „das Modell schätzt eine 42-prozentige Chance auf reale Ausnutzung binnen 30 Tagen“.
Im Glossar lesen- 44,7 %
- Erhöht – Modell schätzt 10-50 % Ausnutzungs-Wahrscheinlichkeit.
EPSS-Perzentil
Das EPSS-Perzentil ist die relative Einordnung einer Schwachstelle innerhalb aller EPSS-bewerteten CVEs, ausgedrückt als Wert zwischen 0 und 1. Ein Perzentil von 0,90 bedeutet „diese CVE hat einen höheren EPSS-Score als 90 % aller anderen bewerteten CVEs“. Anders als der EPSS-Score ist es keine Wahrscheinlichkeit — sondern eine Positionierung im Ranking.
Im Glossar lesen- 98,8
- Kritisch – CVE liegt im obersten Fünftel aller heute bewerteten CVEs (Rang ≥ 80 %).
KEV-Status
Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.
Im Glossar lesen- Aktiv ausgenutzt
- Veröffentlicht
In CISA KEV seit
Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.
Im Glossar lesen- CISA-Bewertung (SSVC)
- Ausnutzung: aktiv · nicht automatisierbar · Auswirkung: teilweise
- Quelle: CISA Vulnrichment, Stand 10. Februar 2025
CWE
CWE ist ein Katalog typischer Schwächen-Arten in Software und Hardware — etwa fehlerhafte Eingabevalidierung, unsichere Speicherbehandlung oder mangelhafte Authentisierung. Während eine CVE eine konkrete Schwachstelle in einem konkreten Produkt benennt, beschreibt eine CWE die zugrunde liegende Fehlerklasse.
Im Glossar lesen- CWE-347
Behebung und Mitigation
Warum sofort handeln?
Priorisierung
Die Lücke steht auf der KEV-Liste, weil Angreifer legitim signierte Binärdateien, oft von Microsoft, mit angehängtem Schadcode versehen. Der Code passiert die Authenticode-Prüfung, und signaturbasierte Vertrauensentscheidungen von Nutzern, AV und Application Control werden umgangen. Typisch ist die Ausnutzung in Phishing- und Malware-Ladeketten gegen breite Nutzerpopulationen. Formal ist sie lokal und erfordert Nutzerinteraktion bei mittlerer Basisschwere, die Ausnutzungswahrscheinlichkeit gilt jedoch als sehr hoch. Weil die Absicherung standardmäßig deaktiviert bleibt und kein regulärer Patch-Zyklus sie schließt, ist praktisch jede ungehärtete Windows-Flotte betroffen. Wegen des geringen Aufwands (eine Registry-Einstellung) ist die Lücke unabhängig von der Basisbewertung als hoch einzustufen und kurzfristig flottenweit zu schließen. CISA meldet keine bekannte Ransomware-Nutzung.
Schritt 1 im Runbook
Sofort-Response (0-24 h)
- Kein Patch-Rollout nötig, aber ein Registry-Schlüssel muss gesetzt werden. Microsoft liefert die strengere Authenticode-Prüfung nur als Opt-in. Auf allen Windows-Clients und -Servern
EnableCertPaddingCheckaktivieren:reg add "HKLM\Software\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_SZ /d 1 /fAuf 64-Bit-Systemen zusätzlich:reg add "HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_SZ /d 1 /fDer Wert wird erst nach einem Neustart wirksam. Microsoft dokumentiert ihn als String "1". - Flächendeckend verteilen: per GPO (Group Policy Preferences → Registry), Intune (Remediation Script oder OMA-URI/Custom Configuration) oder SCCM. Die Pilotgruppe noch heute festlegen und den Rollout auf die Gesamtflotte innerhalb von 24-72 h planen.
- Ist-Zustand erfassen: Die Lücke ist auf fast jeder Windows-Installation ohne gesetzten Schlüssel offen. Bestandsabfrage über Defender Vulnerability Management, Qualys/Tenable-Check oder
Get-ItemPropertyper Remoting-Skript. Ergebnis als Nachweis für das ISMS dokumentieren (NIS2-Risikomanagement). - Kompatibilität testen: Manche legitimen Installer hängen Konfigurationsdaten an die Signaturstruktur an. Mit aktivem Check gelten diese als unsigniert. Softwareverteilung und Paketierung (MSI/EXE-Installer, Updater von Drittanbietern) in der Pilotgruppe prüfen.
- Priorität auf Systeme mit hohem Ausführungsrisiko: Admin-Workstations, Jump-Hosts, Build-Server, Systeme von Nutzern mit lokalen Administratorrechten und Clients mit E-Mail- bzw. Download-Exposition zuerst härten.
- Kein Patch-Rollout nötig, aber ein Registry-Schlüssel muss gesetzt werden. Microsoft liefert die strengere Authenticode-Prüfung nur als Opt-in. Auf allen Windows-Clients und -Servern
Schritt 2 im Runbook
Mitigation-Layer
- Endpoint-Härtung / Application Control: WDAC oder AppLocker mit Hash- statt reinen Publisher-Regeln für sensible Systeme einsetzen. Publisher-basierte Freigaben vertrauen genau der manipulierbaren Signatur. Zusätzlich die Microsoft Recommended Driver/Block Rules aktivieren.
- Least Privilege: Lokale Administratorrechte entziehen (LAPS bzw. Windows LAPS, Just-in-Time-Admin). Die Auswirkung der Lücke skaliert mit den Rechten des ausführenden Nutzers.
- E-Mail- und Web-Gateway: Ausführbare Anhänge (
.exe,.dll,.msi,.scr) sowie Archive mit PE-Inhalt blockieren oder sandboxen. Sandbox-Analyse auch für Dateien mit gültiger Signatur erzwingen, also keine Allowlist auf Basis des Signaturstatus. - ASR-Regeln (Microsoft Defender): „Block executable files from running unless they meet a prevalence, age, or trusted list criterion" sowie „Block executable content from email client and webmail" im Block-Modus aktivieren.
- Konfigurationsüberwachung: Den Schlüssel
Wintrust\Config\EnableCertPaddingCheckin die Baseline aufnehmen (z. B. CIS/BSI-SiSyPHuS-orientierte Härtungsvorgabe) und Abweichungen per Compliance-Policy (Intune/SCCM Configuration Baseline) melden.
Schritt 3 im Runbook
Detection-Regeln
- Manipulation der Härtung (Sysmon EID 12/13/14, MDE): Löschen oder Ändern des Werts deutet auf gezielte Rückabwicklung hin. KQL:
DeviceRegistryEvents | where RegistryKey has @"Cryptography\Wintrust\Config" and RegistryValueName == "EnableCertPaddingCheck" and (ActionType == "RegistryValueDeleted" or RegistryValueData != "1") - Signierte Binärdatei mit abweichendem Hash (Sysmon EID 1 / EID 7): Ein Prozess oder eine DLL mit Signatur „Microsoft" oder eines bekannten Herstellers, deren SHA256 nicht zur bekannten Version passt bzw. in VirusTotal/NSRL unbekannt ist. Sigma-Form:
Signed: true AND Signature contains 'Microsoft' AND Image|contains '\AppData\' OR '\Temp\' OR '\Downloads\' - Überlange Zertifikatstabelle / Overlay im PE (YARA, Datei-Scanning): Daten innerhalb des Security Directory hinter dem PKCS#7-Blob, etwa Skript- oder Shellcode-Fragmente. Regelidee:
pe.number_of_signatures > 0kombiniert mit Strings wie<script,powershell,mshtaoder Base64-Blöcken im Signaturbereich. - Auffällige Prozesskette (EDR): Signierte Microsoft-Utilities, z. B. Installer-Komponenten, die aus Benutzerpfaden starten und anschließend
mshta.exe,rundll32.exe,regsvr32.exeoderpowershell.exeerzeugen. SPL:index=sysmon EventCode=1 ParentImage IN ("*\\AppData\\*","*\\Temp\\*") Image IN ("*\\mshta.exe","*\\rundll32.exe","*\\powershell.exe") - Proaktives Threat Hunting: Flottenweit nach Microsoft-signierten Dateien außerhalb von
C:\WindowsundC:\Program Filessuchen und deren Hashes gegen Referenzwerte abgleichen.
- Manipulation der Härtung (Sysmon EID 12/13/14, MDE): Löschen oder Ändern des Werts deutet auf gezielte Rückabwicklung hin. KQL:
Erkennungsregeln
Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.
Einordnung nach NIS2 und CRA
Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.
NIS2
NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.
Im Glossar lesen- Aktiv ausgenutzt: Behandeln Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 vorrangig. Wird sie in Ihrer Umgebung ausgenutzt, prüfen Sie die Meldepflicht nach Art. 23 (Frühwarnung binnen 24 Stunden).
CRA
Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.
Im Glossar lesen- Seit dem 11.09.2026 müssen Hersteller betroffener Produkte mit digitalen Elementen aktiv ausgenutzte Schwachstellen nach Art. 14 CRA melden, mit Frühwarnung binnen 24 Stunden über die zentrale Meldeplattform der ENISA.
ISO/IEC 27001
ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.
Im Glossar lesen- Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.
Beschreibung
Warum veröffentlicht Microsoft erneut eine CVE aus dem Jahr 2013? Wir veröffentlichen CVE-2013-3900 im Sicherheitsupdate-Leitfaden neu, um die Tabelle der Sicherheitsupdates zu aktualisieren und Kunden darüber zu informieren, dass EnableCertPaddingCheck in allen aktuell unterstützten Versionen von Windows 10 und Windows 11 verfügbar ist. Obwohl das Format sich vom ursprünglich im Jahr 2013 veröffentlichten CVE unterscheidet, bleibt die Information hierin, abgesehen von Klarstellungen zur Konfiguration des EnableCertPaddingCheck-Registrierungswerts, unverändert gegenüber dem Originaltext, der am 10. Dezember 2013 veröffentlicht wurde. Microsoft plant nicht, das strengere Verifizierungsverhalten als Standardfunktionalität in unterstützten Versionen von Microsoft Windows zu erzwingen. Dieses Verhalten bleibt als optionale Funktion über die Registrierungsschlüssel-Einstellung verfügbar und ist seit dem 10. Dezember 2013 auf allen unterstützten Editionen von Windows erhältlich, einschließlich aller aktuell unterstützten Versionen von Windows 10 und Windows 11. Der unterstützende Code für diesen Registrierungsschlüssel wurde zum Zeitpunkt der Veröffentlichung von Windows 10 und Windows 11 integriert, sodass kein Sicherheitsupdate erforderlich ist; jedoch muss der Registrierungsschlüssel gesetzt werden. Siehe die Tabelle der Sicherheitsupdates für die Liste der betroffenen Software. **Beschreibung der Schwachstelle:** Eine Schwachstelle bezüglich der Ausführung von Code auf Distanz besteht darin, wie die WinVerifyTrust-Funktion die Windows Authenticode-Signaturüberprüfung für portable ausführbare (PE) Dateien behandelt. Ein anonymer Angreifer könnte diese Schwachstelle ausnutzen, indem er eine vorhandene signierte ausführbare Datei modifiziert, um unverifizierte Teile der Datei so zu nutzen, dass bösartiger Code zur Datei hinzugefügt wird, ohne die Signatur zu ungültig zu machen. Ein Angreifer, der diese Schwachstelle erfolgreich ausnutzt, könnte die vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer könnte dann Programme installieren; Daten anzeigen, ändern oder löschen; oder neue Konten mit vollen Benutzerrechten erstellen. Wenn sich ein Benutzer mit administrativen Benutzerrechten angemeldet hat, könnte ein Angreifer, der diese Schwachstelle erfolgreich ausnutzt, die vollständige Kontrolle über ein betroffenes System erlangen. Ein Angreifer könnte dann Programme installieren; Daten anzeigen, ändern oder löschen; oder neue Konten mit vollen Benutzerrechten erstellen. Benutzer, deren Konten so konfiguriert sind, dass sie weniger Benutzerrechte auf dem System haben, könnten weniger betroffen sein als Benutzer, die mit administrativen Benutzerrechten arbeiten. Die Ausnutzung dieser Schwachstelle erfordert, dass ein Benutzer oder eine Anwendung eine speziell gestaltete, signierte PE-Datei ausführt oder installiert. Ein Angreifer könnte eine... Weitere Informationen finden Sie unter https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900
Originalquelle nur englisch verfügbar, maschinell ins Deutsche übersetzt.
Quelle: cvelistv5, NVD (NIST), CISA KEV Catalog, CVE.org (MITRE)
Hersteller und Produkte
- Microsoft Windows 10 1507
- Microsoft Microsoft Windows 10 1607
- Microsoft Microsoft Windows 10 1809
- Microsoft Windows 10 1909
- Microsoft Windows 10 20h2
- Microsoft Windows 10 21h1
- Microsoft Microsoft Windows 10 21H2
- Microsoft Microsoft Windows 10 22h2
- Microsoft Windows 11 21h2
- Microsoft Microsoft Windows 11 22H2
- Microsoft Microsoft Windows 11 23H2
- Microsoft Microsoft Windows 11 24H2
Betroffene Betriebssysteme
| Windows | microsoft | windows_10_1507 | — |
| Windows | microsoft | windows_10_1607 | — |
| Windows | microsoft | windows_10_1809 | — |
| Windows | microsoft | windows_10_1909 | — |
| Windows | microsoft | windows_10_20h2 | — |
| Windows | microsoft | windows_10_21h1 | — |
| Windows | microsoft | windows_10_21h2 | — |
| Windows | microsoft | windows_10_22h2 | — |
| Windows | microsoft | windows_11_21h2 | — |
| Windows | microsoft | windows_11_22h2 | — |
| Windows | microsoft | windows_11_23h2 | — |
| Windows | microsoft | windows_11_24h2 | — |
| Windows | microsoft | windows_7 | — |
| Windows | microsoft | windows_8.1 | — |
| Windows | microsoft | windows_rt_8.1 | — |
| Windows | microsoft | windows_server_2008 | r2 |
| Windows | microsoft | windows_server_2008 | — |
| Windows | microsoft | windows_server_2012 | r2 |
| Windows | microsoft | windows_server_2012 | — |
| Windows | microsoft | windows_server_2016 | — |
| Windows | microsoft | windows_server_2019 | — |
| Windows | microsoft | windows_server_2022 | — |
| Windows | microsoft | windows_server_2022_23h2 | — |
| Windows | microsoft | windows_server_2025 | — |
Weakness-Klassen (CWE)
CWE-347Improper Verification of Cryptographic Signature
Base
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
Eintrag bei MITRE CWE-347
Öffentliche Exploit-Referenzen
Öffentlich gemeldete Proof-of-Concepts, Exploit-Module und Detection-Templates zu dieser Schwachstelle. NEOSEC verlinkt ausschließlich auf die Originalquellen und stellt keinen Exploit-Code bereit.
| CISA KEV Catalog | CISA Known Exploited Vulnerability (öffnet in neuem Tab)cisa.gov | aktiv ausgenutzt | |
| PoC-in-GitHub (nomi-sec) | nessus-vulnerability-scanning-lab (öffnet in neuem Tab)github.com | PoC (öffentlich gemeldet)gemeldet, nicht verifiziert |
Quellen & Referenzen
- Microsoft Security Update GuideWinVerifyTrust Signature Validation VulnerabilityHerstellerhinweis
- docs.microsoft.comMS13-098Herstellerhinweis, x_refsource_MS, x_transferred
- blogs.technet.comb/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-securit…x_refsource_CONFIRM, x_transferred
- cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2013-3900government-resource
Änderungen an der CVE
Wer diese CVE wann geändert hat: die NVD (Analyse, betroffene Produkte, CVSS), der Herausgeber der CVE (CNA) und ergänzende Stellen wie CISA (ADP).
Analyse der NVD geändertNVD
Eintrag geändertMicrosoft
3 Einzeländerungen im Original anzeigen
Einzeländerungen dieses Ereignisses im Original der NVD Art Aktion Vorher Nachher Referenz ergänzt —https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900Referenz entfernt https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900—Referenztyp entfernt https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900 Types: Patch, Vendor Advisory—Kennung der Quelle: secure@microsoft.com
Eintrag geändertCISA ADP
CVSS V3.1: vorher AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, nachher —
5 Einzeländerungen im Original anzeigen
Einzeländerungen dieses Ereignisses im Original der NVD Art Aktion Vorher Nachher CVSS entfernt AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H—Schwachstellentyp (CWE) entfernt CWE-347—Referenz ergänzt —https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-3900Referenz entfernt https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-3900—Referenztyp entfernt https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-3900 Types: US Government Resource—Kennung der Quelle: 134c704f-9b21-4f2e-91b3-4a467353bcc0
Eintrag geändertCVE Program
9 Einzeländerungen im Original anzeigen
Einzeländerungen dieses Ereignisses im Original der NVD Art Aktion Vorher Nachher Referenz ergänzt —http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspxReferenz ergänzt —https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-098Referenz ergänzt —https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900Referenz entfernt http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx—Referenz entfernt https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-098—Referenz entfernt https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900—Referenztyp entfernt http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx Types: Broken Link—Referenztyp entfernt https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-098 Types: Vendor Advisory—Referenztyp entfernt https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900 Types: Patch, Vendor Advisory—Kennung der Quelle: af854a3a-2127-422b-91ae-364da2661108
Badge einbetten
Zeigen Sie Schweregrad und KEV-Status dieser Schwachstelle auf Ihrer Seite – mit Link hierher. Das Bild wird stündlich aktualisiert.
<a href="https://intel.neosec.eu/cve/CVE-2013-3900"><img src="https://intel.neosec.eu/badge/cve/CVE-2013-3900.svg" alt="CVE-2013-3900 – NEOSEC Intel" height="20"></a>