[unidoc-alip]

What is wrong today

GitHub's dependency alerts list one critical and three high-severity security advisories against Echo, the web framework our server is built on. The critical one lets a request skip the server's login and permission checks. The high ones let an attacker make the server use up memory until it slows down or stops.

Every one of them is in an optional part of Echo that a server has to switch on: a built-in forwarding proxy, automatic unzipping of uploaded request bodies, and a request recorder for debugging. Our server uses none of these, so customers are not exposed today. We still update: the fix is a small patch release, it clears the alerts, and it means turning one of those features on later can't quietly bring the problem back.

A fifth alert, high severity, is in go-jose, a library our single sign-on login uses to read the identity token the sign-in provider sends back. This one can be reached today. A specially built token makes the server spend a long time on a key check that should take a moment. Each organization's admin chooses which sign-in provider to trust, so an admin who points it at a server they control can send such a token. On a shared, multi-organization installation, that can slow the server down for every customer. We measured it: one crafted sign-in holds a processor core for about 28 seconds before this change, and is turned away in about a thousandth of a second after it.

The Go team's own vulnerability scanner doesn't know about the Echo or go-jose advisories yet. It did find three other issues, which this PR also fixes:

• Go itself (the version we build with, 1.26.9): a fix that stops trusting a set of compromised security certificates. Our server does use this code, every time it makes a secure connection to another service: single sign-on, S3 storage, email, Slack and Matrix.
• Go's networking library: two bugs in its HTML reader. Our code never calls that part.

This PR fixes the weaknesses directly; there is no separate issue for it.

What this changes

• Echo moves from version 4.16.0 to 4.16.3, the newest release in the same series.
• The Go version used to build and test the server moves from 1.26.9 to 1.26.10, a patch release on the same line.
• go-jose moves from 4.1.5 to 4.1.6, which refuses oversized or malformed keys before checking them.
• Go's networking library moves from 0.60.0 to 0.62.0. That pulls five related Go-team libraries (encryption, background tasks, system, terminal and text) up to the versions it needs.
• The local developer container now installs the same Go version.

No code changes, and nothing users see changes. One Echo change deserves a mention: 4.16.3 changes how Echo works out a visitor's IP address when the application hasn't told it how. Our server already gives Echo its own rule for this, so login rate limiting and sign-in tracking keep seeing the same addresses as before.

Verification

• The server builds, and the code checks and unit tests pass on Go 1.26.10.
• The database-backed tests also pass against a freshly built database.
• The go-jose fix was checked by sending a crafted sign-in token through the same verification step our login uses: about 28 seconds of processing before, about a thousandth of a second after.
• The Go vulnerability scanner found 1 issue our code reaches and 2 in libraries we include before this change, and 0 of either after.
• One older finding remains: an unmaintained encryption package inside a Go library. It has no fix and our code never uses it. This PR doesn't change it.

Risk

Low. These are patch releases on versions we already use. The one behaviour change to know about: go-jose 4.1.6 refuses signing keys larger than 4096 bits. If an organization's sign-in provider signs with a key larger than that, its single sign-on would stop working until the limit is raised. The common providers use 2048-bit keys, and some use 4096, so we don't expect anyone to be affected. The automated builds pick up the new Go version on their own. The worst realistic outcome is a build or test failure on CI, which we'd see before merge, not a problem in production.

[unidoc-ahall]

Approving 9ff80fb.

What I checked

• The diff is only go.mod, go.sum and devenv/Dockerfile (GO_VERSION 1.26.10). No source changes.
• On Go 1.26.10 (toolchain fetched from the go line): 'go mod verify' reports all modules verified; 'go mod tidy -diff' is clean (go.mod/go.sum are consistent, nothing missing or extra); go build ./... and go vet ./... are clean.
• 'go test ./...' against the test database passes in every package (cmd/isms, api, client, db, i18n, mail, refs, risk, store, tui).
• go-jose 4.1.6: confirmed in the module source that it adds a limit of 4096 bits on RSA key modulus (MaxRSAModulusBits = 4096), which matches the described mitigation and the risk note (providers with larger keys would fail).
• Echo 4.16.3's IP-extraction change: the server sets its own echo IPExtractor (api/server.go), which is what rate limiting reads via c.RealIP(), so the behaviour change in the default does not apply here.

Non-blocking

• The go-jose DoS needs an admin-controlled OIDC provider; worth a line in release notes for operators of shared installs, and for anyone using a provider with a key above 4096 bits.
• Before merging, rebuild the devenv image so local Go matches CI (the Dockerfile fetches the release tarball by version).

What I did not do

• Did not run govulncheck (I did not want to download and execute an external tool here), so the scanner numbers in the description (1 reachable and 2 imported before, 0 after) are not independently verified. Did not reproduce the 28 s vs 1 ms crafted-token measurement, and did not test against a real OIDC provider.