Spotted what might be an issue in go.mod around line 1.
The project pins golang.org/x/mod at v0.38.0, which is vulnerable to CVE‑2026‑56864. A compromised GOSUMDB can serve arbitrary module code that bypasses the Go module checksum database and the transparency log, enabling supply‑chain attacks such as injection of malicious binaries or backdoors. Because this could affect any build that resolves modules, the risk is HIGH. Upgrading to a fixed version (≥ 0.40.0) restores proper verification of module content.
Something like this might fix it:
```diff
--- a/go.mod
+++ b/go.mod
@@
-require golang.org/x/mod v0.38.0
+require golang.org/x/mod v0.40.0
```
For reference: rule CVE-2026-56864. Rated high.
I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Spotted what might be an issue in
go.modaround line 1.The project pins golang.org/x/mod at v0.38.0, which is vulnerable to CVE‑2026‑56864. A compromised GOSUMDB can serve arbitrary module code that bypasses the Go module checksum database and the transparency log, enabling supply‑chain attacks such as injection of malicious binaries or backdoors. Because this could affect any build that resolves modules, the risk is HIGH. Upgrading to a fixed version (≥ 0.40.0) restores proper verification of module content.
Something like this might fix it:
For reference: rule
CVE-2026-56864. Rated high.I may be wrong about this one — closing it costs you nothing if so.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.