Let's Encrypt client and ACME library written in Go (Lego). In versions 4.25.1 and below, the github.com/go-acme/lego/v4/acme/api package (thus the lego library and the lego cli as well) don't enforce HTTPS when talking to CAs as an ACME client. Unlike the http-01 challenge which solves an ACME challenge over unencrypted HTTP, the ACME protocol requires HTTPS when a client communicates with the CA to performs ACME functions. However, the library fails to enforce HTTPS both in the original discover URL (configured by the library user) and in the subsequent addresses returned by the CAs in the directory and order objects. If users input HTTP URLs or CAs misconfigure endpoints, protocol operations occur over HTTP instead of HTTPS. This compromises privacy by exposing request/response details like account and request identifiers to network attackers. This was fixed in version 4.25.2.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Let's Encrypt client and ACME library written in Go (Lego). In versions 4.25.1 and below, the     github.com/go-acme/lego/v4/acme/api package (thus the lego library and the lego cli as well) don't enforce     HTTPS when talking to CAs as an ACME client. Unlike the http-01 challenge which solves an ACME challenge     over unencrypted HTTP, the ACME protocol requires HTTPS when a client communicates with the CA to performs     ACME functions. However, the library fails to enforce HTTPS both in the original discover URL (configured     by the library user) and in the subsequent addresses returned by the CAs in the directory and order     objects. If users input HTTP URLs or CAs misconfigure endpoints, protocol operations occur over HTTP     instead of HTTPS. This compromises privacy by exposing request/response details like account and request     identifiers to network attackers. This was fixed in version 4.25.2. (CVE-2025-54799)

Note that Nessus relies on the presence of the package as reported by the vendor.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Let's Encrypt client and ACME library written in Go (Lego). In versions 4.25.1 and below, the
    github.com/go-acme/lego/v4/acme/api package (thus the lego library and the lego cli as well) don't enforce
    HTTPS when talking to CAs as an ACME client. Unlike the http-01 challenge which solves an ACME challenge
    over unencrypted HTTP, the ACME protocol requires HTTPS when a client communicates with the CA to performs
    ACME functions. However, the library fails to enforce HTTPS both in the original discover URL (configured
    by the library user) and in the subsequent addresses returned by the CAs in the directory and order
    objects. If users input HTTP URLs or CAs misconfigure endpoints, protocol operations occur over HTTP
    instead of HTTPS. This compromises privacy by exposing request/response details like account and request
    identifiers to network attackers. This was fixed in version 4.25.2. (CVE-2025-54799)

ID	Name	Product	Family	Severity
253527	Linux Distros Unpatched Vulnerability : CVE-2025-54799	Nessus	Misc.	medium
431692	SCA: security update for github.com/go-acme/lego/v4 (GHSA-q82r-2j7m-9rv4)	Tenable Cloud Security	SCA Checks	medium
431692	SCA: security update for github.com/go-acme/lego/v4 (GHSA-q82r-2j7m-9rv4)	Tenable Self-Hosted Container Security	SCA Checks	medium

Detections

Analytics

CVE-2025-54799

medium

Tenable Plugins

medium

medium

medium