# Filebeat/Metricbeat: which releases will include Go 1.26.10 for CVE-2026-111943 (GO-2026-6809)? **URL:** \ **Category:** Beats\ **Tags:** filebeat, metricbeat\ **Created:** [November 2, 2026, 12:49pm UTC](https://discuss.elastic.co/t/filebeat-metricbeat-which-releases-will-include-go-1-26-10-for-cve-2026-111943-go-2026-6809/391328 "2026-11-02T12:49:48Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![jayanthi\_c](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jayanthi_c/32/123903_2.png) [@jayanthi\_c](https://discuss.elastic.co/u/jayanthi_c)\ **Post date:** [November 2, 2026, 12:49pm UTC](https://discuss.elastic.co/t/filebeat-metricbeat-which-releases-will-include-go-1-26-10-for-cve-2026-111943-go-2026-6809/391328/1 "2026-11-02T12:49:49Z")
Hi Beats team, Our vulnerability scan flags **CVE-2026-111943** ([GO-2026-6809](https://pkg.go.dev/vuln/GO-2026-6809)) in the Go runtime embedded in Filebeat and Metricbeat. It is a Go standard library issue: `crypto/x509.Certificate.Verify` did not reject chains through a set of intermediate CA certificates (eMudhra-issued, per Black Duck) that are no longer trusted, so a TLS client could accept an impersonated server. It is fixed in Go 1.26.10 and 1.27.3 ([golang/go#82345](https://github.com/golang/go/issues/82345)). Black Duck tracks it as BDSA-2026-37945, CVSS 3.1 base score 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). Beats' TLS clients (Elasticsearch, Logstash and Kafka outputs, HTTP-based inputs and modules) verify server certificates through `Certificate.Verify`, so the affected code is reachable whenever SSL verification is enabled. Thanks for getting the Go bump in quickly. It is already merged on these branches: | Branch | PR | | --- | --- | | main | [#53706](https://github.com/elastic/beats/pull/53706) | | 9.6 | [#53960](https://github.com/elastic/beats/pull/53960) | | 9.5 | [#53961](https://github.com/elastic/beats/pull/53961) | | 9.4 | [#53962](https://github.com/elastic/beats/pull/53962) | | 8.19 | [#53963](https://github.com/elastic/beats/pull/53963) | However, no published release contains it yet. Go version per `.go-version` at each release tag: | Release | Go version | | --- | --- | | [9.5.5](https://github.com/elastic/beats/blob/v9.5.5/.go-version) | 1.26.8 | | [9.4.8](https://github.com/elastic/beats/blob/v9.4.8/.go-version) | 1.26.8 | | [8.19.23](https://github.com/elastic/beats/blob/v8.19.23/.go-version) | 1.26.8 | | [9.3.8](https://github.com/elastic/beats/blob/v9.3.8/.go-version) | 1.26.4 | | [9.3.3](https://github.com/elastic/beats/blob/v9.3.3/.go-version) | 1.25.8 | We also checked the `filebeat-oss-9.5.5-linux-x86_64` and `metricbeat-oss-9.5.5-linux-x86_64` binaries directly; both embed `go1.26.8`. **Questions** 1. Which releases will be the first to ship with Go 1.26.10 (presumably 9.4.9, 9.5.6, 8.19.24 and 9.6.0), and is there an expected release date? 2. The `9.3` branch did not get the backport (it is still on Go 1.26.5). Is another 9.3.x release planned, or is upgrading to 9.4.x or later the only way to get the fix? 3. As an interim mitigation: can you confirm that when `ssl.certificate_authorities` is set, Beats verifies server certificates only against those CAs and not the system trust store? If so, chains through the distrusted public intermediates cannot validate on those connections, and exposure is limited to connections that rely on the system trust store. **Environment** - Filebeat 9.3.3 and Metricbeat 9.3.3, RPM packages (`filebeat-9.3.3-1.x86_64`, `metricbeat-9.3.3-1.x86_64`) - Rocky Linux, x86\_64 **Note on Linux:** some scanner descriptions of this CVE say only macOS and Windows are affected. The Go advisory lists `crypto/x509.Certificate.Verify` with no OS restriction, and the fix also adds the check to the generic verifier in `crypto/x509/verify.go`, so Linux builds are affected too. Thanks!