[BUG] Rebuild Syncthing with Go 1.25.12 or newer

[Feberdin]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The Syncthing binary in the public image lscr.io/linuxserver/syncthing:latest at digest sha256:07da4c778027cb13d4a2b9bb8b8d7432ac3a0f0540bb7248b016be3a1cc69788 was built with Go 1.25.10.

Current fixed-version data identifies:

• Go 1.25.11 or 1.26.4 for CVE-2026-27145 and CVE-2026-42504.
• Go 1.25.12, 1.26.5, or newer for CVE-2026-39822.

The image label is v2.1.3-ls227, its creation timestamp is 2026-08-05T15:12:54.9407344Z, and the build stage uses Alpine 3.23. This is a compiler/runtime maintenance report; no Syncthing application-level exploitability is claimed.

Expected Behavior

The current public image should contain a Syncthing binary built with Go 1.25.12 or a newer supported release.

Steps To Reproduce

1. Inspect the immutable public image digest listed above for the x86-64 platform.
2. Scan it with Trivy 0.73.0 and Grype 0.116.1.
3. Observe Go standard library build version 1.25.10.
4. Compare it with the fixed patch releases listed above.

The Dockerfile installs go in the Alpine build stage and compiles Syncthing there, so the compiler version is controlled by the selected build base/repositories.

Environment

• OS: Public image artifact; runtime base is Alpine 3.23.5
• How docker service was installed: Not applicable; reproduction operates on the public registry artifact and does not require a running container

CPU architecture

x86-64

Docker creation

Not applicable; no container needs to be created to reproduce the embedded Go build version.

Container logs

Not applicable; the finding is present in the immutable image binary before container startup.

Suggested remediation

1. Move the build stage to a repository/base that provides Go 1.25.12 or newer.
2. Rebuild the same Syncthing release with that compiler.
3. Publish an immutable digest and verify the embedded Go build version.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

Please stop

linuxserver/docker-prowlarr#83 (comment)

[Feberdin]

You are right. I should have verified component ownership and practical applicability, and I should have read the LinuxServer.io reporting guidance before opening multiple scanner-driven issues. That was my mistake. Sorry for the noise and the unnecessary triage work. I will not refile these findings here.