{"id":"CVE-2025-54799","aliases":["DEBIAN-CVE-2025-54799","EUVD-2025-23896","GHSA-q82r-2j7m-9rv4","GO-2025-3847","SUSE-SU-2025:02912-1","UBUNTU-CVE-2025-54799","openSUSE-SU-2025:15434-1"],"status":"published","title":"Lego does not enforce HTTPS","description":"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.","severity":{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00256,"percentile":0.17369,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-319"],"published":"2025-08-06T17:08:52Z","modified":"2026-10-28T02:30:49Z","fixes":[{"ecosystem":"Go","package":"github.com/go-acme/lego/v4","fixed_in":["4.25.2"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"golang-github-xenolf-lego","fixed_in":["4.35.2-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/go-acme/lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"4.25.1"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/go-acme/lego/v3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"4.25.1"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/go-acme/lego/v4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"4.25.1"},{"fixed":"4.25.2"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.35.2-1","4.35.2-2","4.35.2-2~bpo13+1","4.35.2-3","4.35.2-3~bpo13+1","4.9.1-1","4.9.1-2","4.9.1-3","4.9.1-4"]},{"source":"osv","ecosystem":"Debian:13","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.35.2-1","4.35.2-2","4.35.2-2~bpo13+1","4.35.2-3","4.35.2-3~bpo13+1","4.9.1-2","4.9.1-3","4.9.1-4"]},{"source":"osv","ecosystem":"Debian:14","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.35.2-1"}]}],"versions":["4.9.1-2","4.9.1-3","4.9.1-4"]},{"source":"osv","ecosystem":"Go","package":"github.com/go-acme/lego","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"4.25.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/go-acme/lego/v3","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"4.25.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/go-acme/lego/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.25.2"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/go-acme/lego/v4","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.25.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250814T182633-150000.1.98.1"}]}],"bundled":31},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250814T182633-150000.1.98.1"}]}],"bundled":31},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.3.1-5"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.3.1-5","2.7.2+dfsg-1","3.2.0-1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.2.0-3.1","4.1.3-3ubuntu1","4.1.3-3ubuntu1.22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:24.04:LTS","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.9.1-1build1","4.9.1-2","4.9.1-2ubuntu0.24.04.1","4.9.1-2ubuntu0.24.04.2","4.9.1-2ubuntu0.24.04.2+esm1","4.9.1-2ubuntu0.24.04.3","4.9.1-2ubuntu0.24.04.3+esm1","4.9.1-2ubuntu0.24.04.3+esm2"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.9.1-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.9.1-4","4.35.2-3"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"golang-github-xenolf-lego","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.9.1-2","4.9.1-3","4.9.1-4"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250811T192933-1.1"}]}],"bundled":29}],"products":[{"vendor":"go-acme","product":"lego"}],"references":[{"url":"https://github.com/go-acme/lego/security/advisories/GHSA-q82r-2j7m-9rv4","tags":["x_refsource_CONFIRM","advisory","web","report"]},{"url":"https://github.com/go-acme/lego/commit/238454b5f74f3cfcbb244ff0d0dc914a4ad44b96","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-54799","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-q82r-2j7m-9rv4"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/54xxx/CVE-2025-54799.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2025-54799","tags":["advisory"]},{"url":"https://github.com/go-acme/lego","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502912-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2021-21411","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-44906","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-44779","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47907","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-50738","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53534","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-53942","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54386","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54388","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54410","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54424","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54576","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54799","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54801","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54996","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54997","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54998","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-54999","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55000","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55001","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55003","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-5999","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6000","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6004","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6011","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6013","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6014","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6015","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-6037","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-7195","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-8341","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2025-54799","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-54799","tags":["report"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2025-54799","title":"Lego does not enforce HTTPS","description":"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.","status":"published","published":"2025-08-07T00:04:14.718Z","modified":"2025-08-07T14:07:32.104Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low","assessor":"cna"}],"cwes":["CWE-319"],"updated_at":"2026-11-02T14:32:27.603809Z"}],"euvd":[{"id":"EUVD-2025-23896","description":"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.","status":"published","published":"2025-08-07T00:04:14Z","modified":"2025-08-07T14:07:32Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low"}],"updated_at":"2026-11-02T20:32:00.279926Z"}],"ghsa":[{"id":"GHSA-q82r-2j7m-9rv4","title":"github.com/go-acme/lego/v4/acme/api does not enforce HTTPS","description":"## Summary\n\nIt was discovered that 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.\n\n## Details\n\nUnlike 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. This is stated in 6.1 of RFC 8555: [https://datatracker.ietf.org/doc/html/rfc8555#section-6.1](https://datatracker.ietf.org/doc/html/rfc8555#section-6.1)\n\n\u003e Each ACME function is accomplished by the client sending a sequence\n\u003e of HTTPS requests to the server [[RFC2818](https://datatracker.ietf.org/doc/html/rfc2818)], carrying JSON messages\n\u003e [[RFC8259](https://datatracker.ietf.org/doc/html/rfc8259)].  Use of HTTPS is REQUIRED.  Each subsection of [Section 7](https://datatracker.ietf.org/doc/html/rfc8555#section-7)\n\u003e below describes the message formats used by the function and the\n\u003e order in which messages are sent.\n\nHowever, 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.\n\nIf the library user accidentally inputs an HTTP URL, or the CA similarly misconfigures its endpoints, this will cause the relevant parts of the protocol to be performed over HTTP. This can result, at the very least, in a lost of privacy of the request/response details, such as account and request identifiers (which could be intercepted by an attacker in a privileged network position). We did not investigate whether other more serious threats could result from the ability to impersonate a CA for some of the protocol requests, but enforcing HTTPS usage is definitely the safe choice.\n\n## Reproducing\n\nThis is illustrated in the attached http_acme_test.go. Since it uses private field Core.directory, this test must be placed inside the source directory of https://github.com/go-acme/lego/v4/acme/api to run.\n\nPlease note that this only checks getting the directory and creating a new account, but other ACME functions are likely impacted as well, such as creating orders, getting and checking order authorizations.\n\n\u003cdetails\u003e\n\n```go\npackage api\n\nimport (\n\t\"crypto/ecdsa\"\n\t\"crypto/elliptic\"\n\t\"crypto/rand\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"strings\"\n\t\"testing\"\n\t\"time\"\n\n\t\"github.com/go-acme/lego/v4/acme\"\n)\n\nconst letsEncryptURLHTTP = \"http://acme-v02.api.letsencrypt.org/directory\"\nconst letsEncryptURLHTTPS = \"https://acme-v02.api.letsencrypt.org/directory\"\n\nfunc changeToHTTP(url *string) {\n\tif strings.HasPrefix(*url, \"https:\") {\n\t\t*url = \"http\" + (*url)[len(\"https\"):]\n\t}\n}\n\nfunc changeToHTTPS(url *string) {\n\tif strings.HasPrefix(*url, \"http:\") {\n\t\t*url = \"https\" + (*url)[len(\"http\"):]\n\t}\n}\n\nfunc TestHTTPURLs(t *testing.T) {\n\tprivateKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)\n\tif err != nil {\n\t\tt.Fatalf(\"error generating a private key: %v\", err)\n\t}\n\n\tfunc() {\n\t\tt.Log(\"testing that Discover enforces https\")\n\t\t_, err := New(\u0026http.Client{\n\t\t\tTransport: \u0026httpsOnlyRoundTripper{inner: http.DefaultTransport},\n\t\t\tTimeout:   20 * time.Second,\n\t\t}, \"\", letsEncryptURLHTTP, \"\", privateKey)\n\t\tif err != nil {\n\t\t\tt.Errorf(\"New error: %v\", err)\n\t\t}\n\t}()\n\n\tcore, err := New(\u0026http.Client{\n\t\tTransport: \u0026httpsOnlyRoundTripper{inner: http.DefaultTransport},\n\t\tTimeout:   20 * time.Second,\n\t}, \"\", letsEncryptURLHTTPS, \"\", privateKey)\n\tif err != nil {\n\t\tt.Fatalf(\"New error: %v\", err)\n\t}\n\n\tfunc() {\n\t\tt.Log(\"testing that account creation enforces https\")\n\n\t\t// Simulate a misconfigured CA that gives out HTTP directory URLs and when\n\t\t// we're done change it back to HTTPS to test the rest.\n\t\tchangeToHTTP(\u0026core.directory.NewAccountURL)\n\t\tdefer changeToHTTPS(\u0026core.directory.NewAccountURL)\n\n\t\t_, err := core.Accounts.New(acme.Account{\n\t\t\tTermsOfServiceAgreed: true,\n\t\t\tContact:              []string{},\n\t\t})\n\t\tif err != nil {\n\t\t\tt.Errorf(\"core.Accounts.New error: %v\", err)\n\t\t}\n\t}()\n\n\t_, err = core.Accounts.New(acme.Account{\n\t\tTermsOfServiceAgreed: true,\n\t\tContact:              []string{},\n\t})\n\tif err != nil {\n\t\tt.Fatalf(\"core.Accounts.New error: %v\", err)\n\t}\n}\n\ntype httpsOnlyRoundTripper struct {\n\tinner http.RoundTripper\n}\n\nfunc (r *httpsOnlyRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {\n\tif req.URL.Scheme != \"https\" {\n\t\treturn nil, fmt.Errorf(\"non-https request is being sent\")\n\t}\n\treturn r.inner.RoundTrip(req)\n}\n```\n\n\u003c/details\u003e\n\n_","status":"published","published":"2025-08-06T17:08:52Z","modified":"2025-08-07T15:11:33Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low"}],"cwes":["CWE-319"],"updated_at":"2026-11-02T14:38:52.85141Z"}],"nvd":[{"id":"CVE-2025-54799","description":"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.","status":"published","published":"2025-08-07T01:15:26.37Z","modified":"2026-06-17T09:40:43.547Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"low","assessor":"secondary"}],"cwes":["CWE-319"],"updated_at":"2026-11-02T14:11:22.319351Z"}],"osv":[{"id":"CVE-2025-54799","title":"Lego does not enforce HTTPS","description":"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.","status":"published","published":"2025-08-07T00:04:14.718Z","modified":"2026-11-11T10:47:21.646989315Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low"}],"cwes":["CWE-319"],"updated_at":"2026-11-11T03:22:28.447808Z"},{"id":"DEBIAN-CVE-2025-54799","description":"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.","status":"published","published":"2025-08-07T01:15:26.37Z","modified":"2026-09-01T20:05:55.058347568Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"low"}],"updated_at":"2026-11-02T15:45:47.378563Z"},{"id":"GHSA-q82r-2j7m-9rv4","title":"github.com/go-acme/lego/v4/acme/api does not enforce HTTPS","description":"## Summary\n\nIt was discovered that 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.\n\n## Details\n\nUnlike 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. This is stated in 6.1 of RFC 8555: [https://datatracker.ietf.org/doc/html/rfc8555#section-6.1](https://datatracker.ietf.org/doc/html/rfc8555#section-6.1)\n\n\u003e Each ACME function is accomplished by the client sending a sequence\n\u003e of HTTPS requests to the server [[RFC2818](https://datatracker.ietf.org/doc/html/rfc2818)], carrying JSON messages\n\u003e [[RFC8259](https://datatracker.ietf.org/doc/html/rfc8259)].  Use of HTTPS is REQUIRED.  Each subsection of [Section 7](https://datatracker.ietf.org/doc/html/rfc8555#section-7)\n\u003e below describes the message formats used by the function and the\n\u003e order in which messages are sent.\n\nHowever, 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.\n\nIf the library user accidentally inputs an HTTP URL, or the CA similarly misconfigures its endpoints, this will cause the relevant parts of the protocol to be performed over HTTP. This can result, at the very least, in a lost of privacy of the request/response details, such as account and request identifiers (which could be intercepted by an attacker in a privileged network position). We did not investigate whether other more serious threats could result from the ability to impersonate a CA for some of the protocol requests, but enforcing HTTPS usage is definitely the safe choice.\n\n## Reproducing\n\nThis is illustrated in the attached http_acme_test.go. Since it uses private field Core.directory, this test must be placed inside the source directory of https://github.com/go-acme/lego/v4/acme/api to run.\n\nPlease note that this only checks getting the directory and creating a new account, but other ACME functions are likely impacted as well, such as creating orders, getting and checking order authorizations.\n\n\u003cdetails\u003e\n\n```go\npackage api\n\nimport (\n\t\"crypto/ecdsa\"\n\t\"crypto/elliptic\"\n\t\"crypto/rand\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"strings\"\n\t\"testing\"\n\t\"time\"\n\n\t\"github.com/go-acme/lego/v4/acme\"\n)\n\nconst letsEncryptURLHTTP = \"http://acme-v02.api.letsencrypt.org/directory\"\nconst letsEncryptURLHTTPS = \"https://acme-v02.api.letsencrypt.org/directory\"\n\nfunc changeToHTTP(url *string) {\n\tif strings.HasPrefix(*url, \"https:\") {\n\t\t*url = \"http\" + (*url)[len(\"https\"):]\n\t}\n}\n\nfunc changeToHTTPS(url *string) {\n\tif strings.HasPrefix(*url, \"http:\") {\n\t\t*url = \"https\" + (*url)[len(\"http\"):]\n\t}\n}\n\nfunc TestHTTPURLs(t *testing.T) {\n\tprivateKey, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)\n\tif err != nil {\n\t\tt.Fatalf(\"error generating a private key: %v\", err)\n\t}\n\n\tfunc() {\n\t\tt.Log(\"testing that Discover enforces https\")\n\t\t_, err := New(\u0026http.Client{\n\t\t\tTransport: \u0026httpsOnlyRoundTripper{inner: http.DefaultTransport},\n\t\t\tTimeout:   20 * time.Second,\n\t\t}, \"\", letsEncryptURLHTTP, \"\", privateKey)\n\t\tif err != nil {\n\t\t\tt.Errorf(\"New error: %v\", err)\n\t\t}\n\t}()\n\n\tcore, err := New(\u0026http.Client{\n\t\tTransport: \u0026httpsOnlyRoundTripper{inner: http.DefaultTransport},\n\t\tTimeout:   20 * time.Second,\n\t}, \"\", letsEncryptURLHTTPS, \"\", privateKey)\n\tif err != nil {\n\t\tt.Fatalf(\"New error: %v\", err)\n\t}\n\n\tfunc() {\n\t\tt.Log(\"testing that account creation enforces https\")\n\n\t\t// Simulate a misconfigured CA that gives out HTTP directory URLs and when\n\t\t// we're done change it back to HTTPS to test the rest.\n\t\tchangeToHTTP(\u0026core.directory.NewAccountURL)\n\t\tdefer changeToHTTPS(\u0026core.directory.NewAccountURL)\n\n\t\t_, err := core.Accounts.New(acme.Account{\n\t\t\tTermsOfServiceAgreed: true,\n\t\t\tContact:              []string{},\n\t\t})\n\t\tif err != nil {\n\t\t\tt.Errorf(\"core.Accounts.New error: %v\", err)\n\t\t}\n\t}()\n\n\t_, err = core.Accounts.New(acme.Account{\n\t\tTermsOfServiceAgreed: true,\n\t\tContact:              []string{},\n\t})\n\tif err != nil {\n\t\tt.Fatalf(\"core.Accounts.New error: %v\", err)\n\t}\n}\n\ntype httpsOnlyRoundTripper struct {\n\tinner http.RoundTripper\n}\n\nfunc (r *httpsOnlyRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {\n\tif req.URL.Scheme != \"https\" {\n\t\treturn nil, fmt.Errorf(\"non-https request is being sent\")\n\t}\n\treturn r.inner.RoundTrip(req)\n}\n```\n\n\u003c/details\u003e\n\n_","status":"published","published":"2025-08-06T17:08:52Z","modified":"2026-09-10T03:50:27.302884949Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low"}],"cwes":["CWE-319"],"updated_at":"2026-11-02T15:46:54.40888Z"},{"id":"UBUNTU-CVE-2025-54799","description":"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.","status":"published","published":"2025-08-07T01:15:00Z","modified":"2026-10-17T12:57:07.937754033Z","cvss":[{"version":"4.0","score":2.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U","level":"low"}],"updated_at":"2026-11-02T16:55:50.817402Z"},{"id":"GO-2025-3847","title":"Github.com/go-acme/lego/v4/acme/api does not enforce HTTPS in github.com/go-acme/lego","description":"Github.com/go-acme/lego/v4/acme/api does not enforce HTTPS in github.com/go-acme/lego","status":"published","published":"2025-08-11T17:25:05Z","modified":"2026-02-04T04:28:55.836126Z","updated_at":"2026-11-02T15:47:01.728182Z"},{"id":"openSUSE-SU-2025:15434-1","title":"govulncheck-vulndb-0.0.20250811T192933-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20250811T192933-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-08-12T00:00:00Z","modified":"2026-03-23T04:53:46.634804Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"SUSE-SU-2025:02912-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20250814T182633 2025-08-14T18:26:33Z (jsc#PED-11136)\n\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3765 CVE-2024-44906 GHSA-h4h6-vccr-44h2\n  * GO-2025-3829 CVE-2025-54410 GHSA-4vq8-7jfc-9cvp\n\n- Update to version 0.0.20250811T192933 2025-08-11T19:29:33Z (jsc#PED-11136)\n  \n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3822 CVE-2025-53942 GHSA-9g4j-v8w5-7x42\n  * GO-2025-3829 CVE-2025-54410 GHSA-4vq8-7jfc-9cvp\n  * GO-2025-3830 CVE-2025-54388 GHSA-x4rx-4gw3-53p4\n  * GO-2025-3831 CVE-2025-50738 GHSA-hfcf-79gh-f3jc\n  * GO-2025-3832 CVE-2021-21411 GHSA-652x-m2gr-hppm\n  * GO-2025-3833 CVE-2025-54576 GHSA-7rh7-c77v-6434\n  * GO-2025-3834 CVE-2025-54424 GHSA-8j63-96wh-wh3j\n  * GO-2025-3835 CVE-2025-54386 GHSA-q6gg-9f92-r9wg\n  * GO-2025-3836 CVE-2025-6037 GHSA-6c5r-4wfc-3mcx\n  * GO-2025-3837 CVE-2025-5999 GHSA-6h4p-m86h-hhgh\n  * GO-2025-3838 CVE-2025-6000 GHSA-mr4h-qf9j-f665\n  * GO-2025-3839 CVE-2025-6011 GHSA-mwgr-84fv-3jh9\n  * GO-2025-3840 CVE-2025-6004 GHSA-qgj7-fmq2-6cc4\n  * GO-2025-3841 CVE-2025-6014 GHSA-qv3p-fmv3-9hww\n  * GO-2025-3842 CVE-2025-6015 GHSA-v6r4-35f9-9rpw\n  * GO-2025-3843 CVE-2025-8341 GHSA-3c93-92r7-j934\n  * GO-2025-3844 CVE-2025-53534 GHSA-fm3m-jrgm-5ppg\n  * GO-2025-3845 CVE-2025-54801 GHSA-qx2q-88mx-vhg7\n  * GO-2025-3847 CVE-2025-54799 GHSA-q82r-2j7m-9rv4\n  * GO-2025-3848 CVE-2025-6013 GHSA-7rx2-769v-hrwf\n  * GO-2025-3851 CVE-2025-44779 GHSA-93jv-pvg8-hf3v\n  * GO-2025-3852 CVE-2025-7195 GHSA-856v-8qm2-9wjv\n  * GO-2025-3853 CVE-2025-55000 GHSA-f7c3-mhj2-9pvg\n  * GO-2025-3854 CVE-2025-54999 GHSA-hh28-h22f-8357\n  * GO-2025-3855 CVE-2025-54998 GHSA-j3xv-7fxp-gfhx\n  * GO-2025-3856 CVE-2025-55003 GHSA-rxp7-9q75-vj3p\n  * GO-2025-3857 CVE-2025-54996 GHSA-vf84-mxrq-crqc\n  * GO-2025-3858 CVE-2025-54997 GHSA-xp75-r577-cvhp\n  * GO-2025-3859 CVE-2025-55001 GHSA-2q8q-8fgw-9p6p\n\n- Update to version 0.0.20250807T150727 2025-08-07T15:07:27Z (jsc#PED-11136)\n\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2025-3849 CVE-2025-47907\n","status":"published","published":"2025-08-19T12:52:27Z","modified":"2026-03-23T04:49:48.54789Z","updated_at":"2026-11-02T15:53:57.111474Z"}]}}