Go 1.22.1 fixes trust and resource limits in input handling

An HTTP client's redirect policy decides whether credentials can follow a response to another host. A multipart parser decides how much memory an upload can consume before the application handles it. These decisions happen inside library calls whose names do not describe an authorization or resource policy. Go 1.22.1, released on March 5, repairs security defects in these paths and in certificate verification. It also fixes two cases where different interpretations of text can undermine a caller's assumptions.

I value Go's standard library because it makes service behavior relatively easy to inspect. That benefit depends on understanding the policy implemented by a library call. This release is useful reading for the same reason as it is a useful update. Its disclosures identify several points where application intent and library behavior could diverge.

A redirect can change the recipient of credentials

The disclosure for CVE-2023-45289 describes how http.Client forwards sensitive headers during redirects. The intended rule permits forwarding to the original domain or a matching subdomain. A redirect to an unrelated domain should not receive headers such as Authorization or Cookie.

The report gives a concrete comparison. A redirect from foo.com to www.foo.com preserves the authorization header under this policy, while one to bar.com does not. A maliciously crafted redirect could defeat the intended restriction and unexpectedly forward sensitive headers. The release includes fixes in both net/http and net/http/cookiejar.

The security consequence concerns the destination receiving a credential. An application may have correctly chosen to authenticate its initial request while relying on the client to restrict later forwarding. The redirect response introduces another party's choice of destination. Library enforcement must maintain the domain boundary as the request follows that choice.

This is also a reason to distinguish automatic redirects from an application's own request construction. The disclosed defect is in forwarding behavior. It does not establish that every outbound request leaks headers or that every redirect is unsafe. The relevant question is whether the affected client's redirect processing can encounter a crafted destination while carrying sensitive headers or cookies.

A form limit must cover intermediate allocations

CVE-2023-45290 concerns memory exhaustion while parsing multipart forms. The parser had limits on the total size of the parsed form, but those limits did not cover memory consumed while reading a single form line. Crafted input with very long lines could therefore cause arbitrarily large allocations before the intended limit constrained the result.

The distinction between the final parsed structure and the work needed to construct it is the mechanism of the bug. Limiting retained data is insufficient when a parser first builds an unbounded intermediate value. Go 1.22.1 applies a maximum size to form lines as part of the repair.

Calling Request.ParseMultipartForm directly is one affected entry point. The disclosure also names implicit parsing through Request.FormValue, Request.PostFormValue, and Request.FormFile. Application code can therefore enter this path through a convenient field accessor without containing an explicit multipart-parser call.

For a server that accepts multipart input, the consequence is resource consumption before useful application work begins. The attacker does not need the resulting form to be meaningful to the handler. Allocating memory during parsing can itself exhaust the process's available memory. The repair addresses that intermediate allocation, which is a different concern from whether the application accepts the uploaded content.

I find this the most broadly instructive fix in the release. A limit belongs at the operation that consumes the resource. An eventual rejection cannot recover memory that the parser was already permitted to allocate without a bound.

Unknown certificate algorithms should be rejected safely

The CVE-2024-24783 disclosure states that Certificate.Verify could panic when a certificate chain contained a certificate with an unknown public-key algorithm. Certificate verification is an operation expected to encounter material that the verifier cannot trust. The failure mode matters independently of whether that material could ever produce a valid chain.

The advisory identifies all crypto/tls clients as affected. On the server side, it names configurations using VerifyClientCertIfGiven or RequireAndVerifyClientCert. Those settings request verification of client certificates. The default TLS server configuration does not verify client certificates, so the disclosure does not give the same exposure to every TLS server.

This qualification prevents a misleading conclusion about mutual TLS. Verification is the operation that encounters the defective path, but that is not a reason to remove authentication. The correction allows verification to handle an unsupported algorithm without this panic. The practical scope follows the verification configuration and the peer-supplied chain.

Error messages also enter the output language

The html/template report describes an error path in JavaScript-context rendering. When a value has a MarshalJSON method and that method fails, template rendering inserts the error inside a comment. The implementation already replaced closing comment tokens that might appear in the error text.

That treatment did not account for HTML script-closing and comment-opening tags. Those sequences matter to the surrounding HTML parser even when the generated text appears to sit inside a JavaScript comment. The proposed correction escapes the less-than character in those sequences, following the treatment used elsewhere for script contexts.

The mechanism is a disagreement between nested languages. A JavaScript comment does not make every contained byte irrelevant to HTML parsing. An error message can contain user-controlled material, so the exceptional path needs the same contextual care as successful output. Checking only the normal JSON result misses the text produced when serialization fails.

Mail parsing can affect trust decisions

The net/mail issue concerns comments in display names. The report explains that an earlier change admitted special characters into atom syntax where the mail specification disallows them. This also caused comments in display names to remain part of the parsed name instead of being handled as comments.

Its example distinguishes a name containing a parenthesized comment from the display name produced after removing that comment. The maintainers classify the parser mismatch as a public-track security issue because programs using different parsers could make different trust decisions about the same input. That is a narrower claim than asserting a specific authentication bypass in every mail-processing application.

Together, these disclosures make the application-specific scope of the update clear. Redirecting clients need the corrected credential boundary. Multipart handlers need limits during line reading. Certificate-verification callers need unsupported algorithms to fail safely, and consumers of templates or mail names need parsing that respects the surrounding format. The affected operations can occur below the most obvious application call, including a form accessor or a serialization error path.