2.1.26

A security release. Update.

Fixed​

• 52 standard-library vulnerabilities reachable from the two panels, cleared by building on Go 1.27.1.
• Eight advisories in the webmail's dependencies, four of them in the code path that sends mail.
• A CSRF origin check that was being skipped by the very requests most worth checking.

Changed​

• Fifteen pages added over the last two releases now follow the panel's own layout.

Notes​

Forty advisories were tracked, one ticket each. Thirty-eight were fixed; two were accepted with the reasoning written down, because no fix exists for them.

The scan found more than the alerts did. GitHub's dependency alerts reported ten findings across the project. Running govulncheck — which asks whether the vulnerable code is actually reachable from ours, rather than merely present — found 52 more, every one of them in the Go standard library and invisible to a scanner that only reads declared dependencies. Both panels pinned Go 1.26.0; the newest advisory needed 1.27.0. They are built on 1.27.1 now, and govulncheck reports 0 reachable vulnerabilities for both, down from 29 and 23.

The webmail's were not theoretical. Four nodemailer advisories concern address parsing and recipient-domain validation — decisions this server makes about where mail is allowed to go — and one concerns attachment paths. The upgrade was verified by sending a real message through the deployed copy into a real mailbox and confirming the body, the attachment and the MIME structure arrived intact, because a security patch that quietly breaks the send path is the worst possible outcome. react-router went from 6 to 7, a major version, checked by building the application rather than by reading a changelog.

The CSRF one is worth reading in full. gorilla/csrf has no patched release, so this could not be closed by a version bump. An origin gate already existed here — but it sat behind the exemption branch, so the four paths that skip the CSRF token skipped the gate as well. Three of those are server-to-server and send no Origin anyway. The fourth, /imav/, is reached with this panel's own session cookie, which left a session-authenticated POST that nothing asked the provenance of. Also worth stating plainly: the session cookie is already HttpOnly and SameSite=Lax, so a forged cross-site POST arrives unauthenticated in any current browser. This check is the belt to those braces, not a door that was standing open.

What was not fixed, and why. Two image-size advisories carry a "high" label and have no patched version — 2.0.2 is both what is installed and the newest that exists. It runs at build time, in CI, against images committed to our own repository; nothing a visitor uploads reaches it and it is installed on no server. Pinning it through yarn resolutions was tried and reverted: it changed the audit result not at all, and forced five versions incompatible with what packages actually request. The reasoning is in website/SECURITY-NOTES.md rather than in somebody's memory.