| CVE-ID | Schweregrad | Paket | Betroffene Version | Behobene Version | CVSS-Score |
|---|---|---|---|---|---|
| CVE-2025-59530 | high | quic-go | >=0.50.0,<0.54.1 | 0.54.1 | 7.5 |
SummaryA misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake. ImpactA misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana's Firedancer QUIC). Affected Versions
Users are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later. DetailsFor a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:
On the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server's HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake. Due to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server's Handshake packets (containing, among others, the TLS certificate) might arrive before the server's Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys. After completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an assertion that no packets are queued after completion of the handshake. A misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys. This can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client's TLS Finished message (which is sent in Handshake packets). The Fixquic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354. Relevance: The relevance of CVE-2025-59530 depends on the specific vulnerability details; if it involves a critical component like HTTP request handling or TLS, it could be critical in scenarios where Caddy is exposed to untrusted networks or processes sensitive data. Its severity increases if the vulnerability allows remote code execution or bypasses security mechanisms. Always verify the CVE's specifics and apply patches if applicable. (Note: Relevance analysis is automatically generated and may require verification.) Package URL(s):
More Info (NVD): | |||||
| CVE-2025-47913 | high | crypto | <0.43.0 | 0.43.0 | 7.5 |
| CVE-2025-61723 | high | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 7.5 |
| CVE-2025-58187 | high | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.3 | 1.25.3 | 7.5 |
| CVE-2025-58188 | high | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 7.5 |
| CVE-2025-61725 | high | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 7.5 |
| CVE-2025-47910 | medium | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.1 | 1.25.1 | 5.4 |
| CVE-2025-58181 | medium | crypto | <0.45.0 | 0.45.0 | 5.3 |
| CVE-2025-47914 | medium | crypto | <0.45.0 | 0.45.0 | 5.3 |
| CVE-2025-61724 | medium | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 5.3 |
Ausnutzung könnte zu schwerwiegenden Konsequenzen wie Systemkompromittierung oder Datenverlust führen. Erfordert sofortige Aufmerksamkeit.
Sicherheitslücke könnte relativ leicht ausgenutzt werden und erhebliche Auswirkungen haben. Erfordert zeitnahe Aufmerksamkeit.
Ausnutzung ist möglich, erfordert aber möglicherweise spezifische Bedingungen. Auswirkungen sind moderat. Sollte zeitnah behoben werden.
Ausnutzung ist schwierig oder die Auswirkungen sind minimal. Kann bei Gelegenheit oder im Rahmen der regulären Wartung behoben werden.
Schweregrad ist nicht bestimmt, informativ oder vernachlässigbar. Überprüfung je nach Kontext.
Sliplane ist eine einfache Container-Hosting-Lösung. Es ermöglicht dir, deine Container innerhalb von Minuten in der Cloud zu deployen und bei Bedarf zu skalieren.
Der CVE-Scanner ist ein leistungsstarkes Tool, das dir hilft, bekannte Sicherheitslücken in deinen Docker-Images zu identifizieren. Indem deine Images mit einer umfassenden Datenbank von Common Vulnerabilities and Exposures (CVEs) abgeglichen werden, kannst du sicherstellen, dass deine Anwendungen sicher und auf dem neuesten Stand sind. Für weitere Details, schau dir die NIST CVE-Datenbank an.
Mit dem Anstieg von Supply-Chain-Angriffen ist die Sicherung deiner Anwendungen wichtiger denn je. CVE-Scanning spielt eine entscheidende Rolle bei der Identifizierung von Sicherheitslücken, die von Angreifern ausgenutzt werden könnten, insbesondere solche, die durch Abhängigkeiten und Drittanbieter-Komponenten eingeführt werden. Regelmäßiges Scannen und Sichern deiner Docker-Images ist essenziell, um deine Anwendungen vor diesen sich entwickelnden Bedrohungen zu schützen.
CVE steht für Common Vulnerabilities and Exposures. Es ist ein standardisierter Bezeichner für bekannte Sicherheitslücken, der Entwicklern und Organisationen ermöglicht, potenzielle Risiken effektiv zu verfolgen und zu beheben. Für weitere Informationen, besuche cve.mitre.org.
Der CVE-Scanner analysiert deine Docker-Images anhand einer umfassenden Datenbank bekannter Sicherheitslücken. Er nutzt Docker Scout im Hintergrund, um detaillierte Einblicke in betroffene Pakete, Schweregradstufen und verfügbare Fixes zu liefern, sodass du sofort handeln kannst.
Das Patchen deiner Docker-Images ist ein entscheidender Schritt, um die Sicherheit und Stabilität deiner Anwendungen zu gewährleisten. Durch regelmäßige Updates deiner Images mit den neuesten Sicherheitspatches kannst du bekannte Sicherheitslücken beheben und das Risiko einer Ausnutzung reduzieren. Dieser proaktive Ansatz stellt sicher, dass deine Anwendungen widerstandsfähig gegenüber neuen Bedrohungen bleiben und hilft, die Einhaltung von Sicherheitsstandards zu gewährleisten.