CVE Scan for caddy:2
Docker image vulnerability scanner
18 Known Vulnerabilities in this Docker Image
| CVE ID | Severity | Package | Affected Version | Fixed 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: CVE-2025-59530 could be critical if the Caddy server is exposed to untrusted user input or operates in a multi-tenant environment, as it might allow remote code execution or privilege escalation. For typical usage as a reverse proxy or static file server with controlled access, the risk is minimal. Assess your deployment context to determine relevance. (Note: Relevance analysis is automatically generated and may require verification.) Package URL(s):
More Info (NVD): | |||||
| CVE-2025-58188 | high | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 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-61725 | high | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 7.5 |
| CVE-2025-47913 | high | crypto | <0.43.0 | 0.43.0 | 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-47910 | medium | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.1 | 1.25.1 | 5.4 |
| CVE-2025-47912 | medium | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 5.3 |
| CVE-2025-47914 | medium | crypto | <0.45.0 | 0.45.0 | 5.3 |
| CVE-2025-58189 | medium | pkg:golang/stdlib@1.25.0 | >=1.25.0,<1.25.2 | 1.25.2 | 5.3 |
Severity Levels
Exploitation could lead to severe consequences, such as system compromise or data loss. Requires immediate attention.
Vulnerability could be exploited relatively easily and lead to significant impact. Requires prompt attention.
Exploitation is possible but might require specific conditions. Impact is moderate. Should be addressed in a timely manner.
Exploitation is difficult or impact is minimal. Address when convenient or as part of regular maintenance.
Severity is not determined, informational, or negligible. Review based on context.
Sliplane is a simple container hosting solution. It enables you to deploy your containers in the cloud within minutes and scale up as you grow.
About the CVE Scanner
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. It is a standardized identifier for known security vulnerabilities, allowing developers and organizations to track and address potential risks effectively. For more information, visit cve.mitre.org.
About the CVE Scanner
The CVE Scanner is a powerful tool that helps you identify known vulnerabilities in your Docker images. By scanning your images against a comprehensive database of Common Vulnerabilities and Exposures (CVEs), you can ensure that your applications are secure and up-to-date. For more details, checkout the NIST CVE Database.
How the CVE Scanner Works
The CVE Scanner analyzes your Docker images against a comprehensive database of known vulnerabilities. It uses Docker Scout under the hood to provide detailed insights into affected packages, severity levels, and available fixes, empowering you to take immediate action.
Why CVE Scanning is Essential for Your Docker Images
With the rise of supply chain attacks, ensuring the security of your applications has become more critical than ever. CVE scanning plays a vital role in identifying vulnerabilities that could be exploited by attackers, especially those introduced through dependencies and third-party components. Regularly scanning and securing your Docker images is essential to protect your applications from these evolving threats.
Benefits of CVE Scanning
- Enhanced Security: Detect and mitigate vulnerabilities before they are exploited.
- Compliance: Meet industry standards and regulatory requirements for secure software.
- Proactive Maintenance: Stay ahead of potential threats by addressing vulnerabilities early.
The Importance of Patching Docker Images
Patching your Docker images is a critical step in maintaining the security and stability of your applications. By regularly updating your images to include the latest security patches, you can address known vulnerabilities and reduce the risk of exploitation. This proactive approach ensures that your applications remain resilient against emerging threats and helps maintain compliance with security best practices.
Sliplane is not associated with Docker Inc. or any of its products. Prices do not include VAT.