DEV Community: Konstantin Evtenko

Why You Can't "Set and Forget" Your Go Version

Konstantin Evtenko — Tue, 01 Sep 2026 17:02:21 +0000

Let's look at this through one of the recent Go releases: a security release that fixed 10 vulnerabilities in the standard library, specifically in the packages present in every backend: net/url, net/http, html/template, crypto/tls, encoding/xml, encoding/asn1, plus go command, net, and x/mod/sumdb. The date and version number matter less here than the recurring pattern itself: releases like this come out regularly, and the problem they solve applies to any version of Go, and really to the runtime of almost any language. If you're interested in the specific version numbers and exact release date being discussed, ask in the comments, I'll be glad to answer.

The problem is that for many teams, releases like this pass unnoticed: the Go version in production gets fixed once at project start and never revisited since. Let's break down why that's risky, what exactly this release fixed, and how to build a process so patches like this don't slip by unnoticed.

Why a Security Patch Is the Moment of Risk, Not the Moment of Safety

The logic can seem counterintuitive: doesn't a patch make the system safer? Yes, but only for those who install it.

A vulnerability in the code has existed since the moment that code was written, it's just that no one knows about it publicly until a certain point. Someone (a security researcher, the Go team itself) finds the problem, then private work on the fix begins: vulnerability details are deliberately withheld until the patch ships, in line with the project's security policy.

Then the key moment happens: as soon as the patch is published, the vulnerability description, the CVE (Common Vulnerabilities and Exposures), is published alongside it. From that second, information about the vulnerability becomes public, and attackers start deliberately scanning the internet for servers still running the old, unpatched version.

Your production image running an old Go version doesn't "accumulate" vulnerabilities over time, it already contained them from the start. It's just that before, no one knew, and now everyone does, including those looking for how to exploit it. The window between a patch's publication and the appearance of mass exploitation attempts can be a matter of days.

What Exactly Was Fixed

Let's walk through specific packages from this release to show what was actually at risk, to make clear this isn't about abstract "vulnerabilities" but about code that actually runs in production.

net/url and net/http: parsing everything that comes from outside

These packages handle URL parsing and HTTP request processing in general. Practically any service that interacts with the outside world depends on them in some way: API gateways, reverse proxies, data aggregators, any code that parses a URL received from a client or a third-party source.

If your architecture has a component that accepts and parses external URLs (for example, a gateway making requests to external data sources based on user input), it sits directly on these packages, and a vulnerability in them potentially affects every such node.

html/template: an XSS attack surface in rendering

One of the fixed issues, CVE-2026-56858, involves incorrect JavaScript context tracking when handling regexp expressions inside <script> blocks. In short: the escaping logic in html/template didn't always correctly escape the / character in the context of regexp literals, which under certain conditions allowed injecting arbitrary JavaScript through user input.

For any service that renders HTML templates using user data, this is a direct XSS vulnerability, and html/template in Go exists specifically to prevent things like this by default. The patch closes a specific hole in that protection.

encoding/xml and encoding/asn1: the forgotten parsers

These packages rarely get attention, since XML and ASN.1 haven't been fashionable formats for a while. But they're still alive in SOAP-service integrations (typical for legacy enterprise systems) and in certificate handling (ASN.1 is the format in which X.509 certificates, used in TLS, are encoded). If you have an integration written a few years ago and untouched since, the odds that it uses one of these packages somewhere aren't small.

x/mod/sumdb: a hit to the dependency supply chain

Two vulnerabilities in x/mod/sumdb (CVE-2026-56865 and CVE-2026-56864) deserve special attention. The GOSUMDB mechanism in Go exists to guarantee the integrity of downloaded modules: when installing a dependency, Go checks its checksum against a public database to confirm the downloaded code hasn't been tampered with.

The discovered vulnerabilities show that a malicious GOPROXY (the proxy server through which Go can fetch modules) was able to forge entries in this database so that substituted, potentially malicious module code passed the GOSUMDB check and settled into the local module cache as if it were legitimate. This is a hit to the very foundation of trust in the dependency ecosystem: if the integrity check can be fooled, any dependency in your project could potentially be swapped out without your knowledge.

A Cadence That's Easy to Underestimate

Literally a few days after this release, another patch shipped, again touching net/http. This isn't an isolated case: Go ships security point releases irregularly, but often, sometimes days apart, sometimes a few weeks apart.

If you don't actively follow announcements on go.dev/security, it's easy to miss not just one but several consecutive patches, and only discover the problem when your infrastructure's security scanner (or, worse, an actual exploit) points to it after the fact. By that point, the CVE has long been public, and attackers have had plenty of time to figure out how to use it.

How to Check What You're Running

A quick check of the Go version installed locally or in your CI environment:

go version

To see which Go version is pinned in the project:

cat go.mod | grep "^go "

If the version is older than the latest published security version for your branch, it's time to plan an upgrade.

How to Build a Process So This Doesn't Keep Happening

A one-time upgrade to the latest version solves today's problem but not the systemic one: next month another patch will ship, and without a process you'll be back in the same situation. A few practical steps:

Pin the toolchain via go.mod. Starting with Go 1.21, you can explicitly specify a toolchain directive in go.mod, which guarantees that CI and production use the same Go version, rather than whatever happens to be installed on a given machine:

go 1.26

toolchain go1.26.6

This doesn't protect against vulnerabilities on its own, but it eliminates the situation where a developer has one version locally, CI has another, and production has a third, with no one sure which version is actually running where.

Update your base Docker image on a schedule, not from memory. If your production images are built, for example, on top of golang:1.26 or a similar base image, it's worth setting up a regular (say, weekly) rebuild that checks for a new version, rather than relying on someone on the team remembering to check go.dev.

Subscribe to Go's security announcements. The go.dev/security page and its associated RSS/mailing list are the most direct source of information about new patches, without the delay that comes from relying on a patch announcement catching your eye on social media by chance.

Add a Go version check to CI as a separate step. A simple check that compares the version in use against the latest published security version and fails the build (or at least warns) if the version in use is older than a defined threshold removes the human factor from this process.

A minimal example for GitHub Actions, pulling the Go version straight from go.mod instead of hardcoding it in the workflow file:

- name: Set up Go
  uses: actions/setup-go@v5
  with:
    go-version-file: 'go.mod'

This keeps CI in sync with whatever version is pinned in go.mod, so bumping the version in one place updates it everywhere.

Verify the Go version in the deployed binary, not just in configuration. An updated Dockerfile or a rebuilt base image guarantees nothing on its own: if a given service hasn't been rebuilt and redeployed, production keeps running a binary built with the old toolchain, even though the configuration was updated long ago. It's especially easy to miss a service that hasn't been touched in a while, one with no trigger for a rebuild (a new commit, a PR). Closing that gap means checking the version after the fact, for example via runtime.Version() in a health endpoint, to confirm what's actually running rather than what's supposed to be running according to configuration.

(as one commenter pointed out on the LinkedIn post for this article, an updated Dockerfile alone doesn't close the loop: rebuilding and redeploying every affected service should be part of the patch process, followed by verifying the version in the deployed binary itself.)

Takeaway

You can't "set and forget" the Go version in your production images, any more than you can with any other project dependency. The difference is that third-party libraries are usually visible to everyone in composer.json or package.json, while the version of the language or runtime itself often remains an invisible part of the infrastructure, configured once at project start and never revisited.

Update Go as deliberately as you update dependencies: with security announcement monitoring, a pinned toolchain, regular base image rebuilds, and verification of what's actually running in production rather than just what's written in configuration. The difference between a team that learns about a vulnerability from the official announcement and a team that learns about it from a security scanner report after the fact is usually the difference between a few minutes spent on a version bump and several days spent on incident response.

How do you keep Go up to date in production: do you pin the toolchain via go.mod, roll base images on a schedule? And who on your team is responsible for monitoring go.dev/security?

If posts like this are useful, follow for more on Go, Laravel/PHP, and production backend engineering.

PHP 8.6 Deprecations: Why Your Logs (and Bill) Will Spike

Konstantin Evtenko — Tue, 11 Aug 2026 09:29:34 +0000

PHP 8.6's mass deprecation vote just closed: 35 separate RFCs, most of them passing. Nothing breaks in 8.6 itself: deprecated functions keep working, they just start warning. That's exactly what teams tend to underestimate, and it's worth walking through why.

Effect #1: Log volume becomes a cost problem

On a live Laravel project with notice logging enabled, every deprecated call in a hot path turns into log volume: disk, ingestion into Loki/ELK, money. The symptom shows up as "logging costs went up," not "time to fix the code," which means it often gets triaged by the wrong team, at the wrong layer, weeks after the actual cause shipped.

A rough mental model: if a deprecated function sits in a hot path called thousands of times per minute, you're not looking at a handful of warnings, you're looking at a sustained, compounding log stream that ingestion pipelines have to process and store indefinitely.

Effect #2: Deprecations you don't control

You'll fix your own code fast. The harder problem is vendor packages without an 8.6-ready release: they'll keep making noise in your logs until the upstream maintainer ships a fix, and that timeline isn't yours to control. On a dependency-heavy Laravel stack, this can mean weeks of irreducible noise even after your own codebase is clean.

(as one commenter pointed out on the LinkedIn version of this post, Rector automates a big chunk of the fixing work, but only for code you own. It won't touch vendor internals, so it complements the CI gate below rather than replacing it.)

You don't have to upgrade right now.
PHP 8.5 is supported for years to come, and deprecations by themselves aren't urgent: they won't break anything until they eventually become removals, often years later. If you're not planning an 8.6 bump soon, none of this is time-sensitive.

The scenario below is for whenever that upgrade does happen, this month, or in a few years. The failure mode doesn't change based on timing: whenever you bump the version, the vendor-deprecation noise shows up the same way, so the CI-gate approach is worth having in place before that day arrives, not scrambling to add it after.

The order that actually works

The trap is discovering deprecation noise in production logs after the fact, then reverse-engineering which release caused it. The order that avoids that:

Bump the PHP version in CI first, not in production.
Set error_reporting to treat E_DEPRECATED as an error in CI, so warnings fail the build instead of silently passing.
Fix what breaks, your own code first; for vendor deprecations, check if a newer package version resolves it, or track the upstream issue.
Only then ship the version bump to production.

A minimal CI-side snippet for the second step:

// In a CI-only bootstrap or phpunit bootstrap file
error_reporting(E_ALL);
set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    if ($errno === E_DEPRECATED || $errno === E_USER_DEPRECATED) {
        throw new \ErrorException($errstr, 0, $errno, $errfile, $errline);
    }
    return false; // fall back to default handler for everything else
});

This turns deprecation warnings into hard failures during your test suite run, cheap to add, and it moves the discovery point from "someone notices the Loki bill" to "the build fails on the PR."

The dependency case

For vendor deprecations specifically, worth checking before assuming you're stuck waiting on upstream:

Is there a newer major/minor version of the package that's already 8.6-ready?
Is the deprecated call actually reachable in your usage, or dead code you can just remove?
Can you suppress just that specific warning at the call site (via @, sparingly) while tracking the upstream issue, rather than disabling the CI gate entirely?

Takeaway

Nothing forces you to fix deprecations the moment they're announced. But treating them as a CI concern, not a production logging concern, is the difference between a five-minute PR fix and untangling a spike in your observability bill three weeks later.

How does your team handle this: hard CI gate, lower log verbosity, or something else?

If posts like this are useful, follow for more on Go, PHP, and production backend engineering.