Go 1.25.2 limits the cost of parsing untrusted input

A bounded input can still produce an excessive amount of work. An HTTP header made of many tiny cookies creates far more parsed objects than a single large cookie with the same byte count. Repeatedly appending to a string can copy earlier content again and again. Go's October security release addresses both patterns across standard-library parsers.

Go 1.25.2, released on October 7, includes ten security fixes, with corresponding work in Go 1.24.8. The announcement covers certificate handling, network syntax, and archive parsing. Several findings share a practical concern about how much memory or CPU a parser spends before it returns a result.

I value Go's standard library because these operations are ordinary dependencies of ordinary programs. A service should not need to implement its own cookie parser to bound the number of resulting objects. The useful question is which unit the implementation counts and at what point it enforces the limit.

Header bytes and cookie objects are different limits

The announcement identifies CVE-2025-58186 as missing cookie-count limits. Even with the default HTTP header byte limit, many short cookie entries could cause substantial allocation. The release adds a default maximum of 3,000 cookies, configurable through httpcookiemaxnum.

The tagged cookie implementation checks the prospective count before splitting and constructing parsed cookies. ParseCookie counts semicolons plus one and returns an explicit error when the count exceeds the configured maximum. Counting before allocation is the relevant ordering because a check after construction would already have incurred the cost.

Existing convenience paths cannot all expose the same error. The source explains that some older cookie-reading functions must return an empty slice on limit failure because their APIs lack an error result. This difference is observable by callers using the existing methods. Applications therefore should not assume every entry point reports excessive input through a returned error. The security boundary and the historical API shape interact.

The count also operates across header lines where the reader combines them. A limit applied independently to each line could leave room for amplification through many lines. The implementation's pre-count makes the number of candidate entries part of its decision before building the result collection.

This is a general distinction between input size and representation size. A byte limit bounds the encoded message. An object-count limit bounds one source of work required to turn that message into application values. Neither quantity can be inferred from the other without considering the encoding's smallest valid units.

Repeated concatenation multiplies work

The release fixes excessive CPU consumption in net/textproto.Reader.ReadResponse, identified as CVE-2025-61724. Its response construction repeatedly concatenated lines. That can make the cost of a later append depend on all the content already accumulated, producing non-linear work as a response grows.

The patched response reader uses strings.Builder. It writes the first line, appends newline separators and subsequent message text, then obtains the result once. The parsing loop retains its responsibility for response codes and continuation lines, while construction no longer expresses the message as repeated immutable-string accumulation.

The same release announcement describes a related issue in mail address domain literals, CVE-2025-61725. A parser can do too much work on one component even when its overall job sounds small. The relevant property is the accumulation algorithm, not whether the input is called an address or a message.

These fixes do not create an unlimited budget for accepted input. They remove avoidable amplification in the construction process. An application can still impose a domain-specific maximum where the protocol allows messages larger than the service needs. The library and application limits address different sources of cost.

Compression changes the relevant input size

The GNU sparse-map advisory identifies CVE-2025-58183 in archive/tar. A reader could consume an unbounded amount of sparse-region metadata from GNU tar pax 1.0 sparse files. Reading through a compressed source could turn a small compressed input into large allocations during parsing.

That mechanism explains why limiting only an uploaded compressed file is insufficient. The parser operates on expanded archive content, and sparse metadata has its own count and storage requirements. A limit at the transport boundary does not automatically constrain every representation produced after decompression.

The relevant correction belongs in archive interpretation because the tar reader knows which bytes describe sparse regions. A generic reader sees only bytes. It cannot determine whether a sequence represents file content or a metadata structure whose entries each require additional memory.

Errors can carry untrusted text

Resource use is not the only parser boundary in this release. The TLS advisory describes CVE-2025-58189, where an ALPN negotiation failure could return attacker-controlled text without escaping it. Programs logging that error without further sanitization could permit injected log content.

An error value is often treated as explanatory text from trusted library code. Here, part of its content came from the peer. Returning an error did not remove the provenance of that data. Formatting it safely matters because the next consumer may interpret control characters or line boundaries differently from the protocol parser.

This is a separate contract from authentication. A handshake can fail as intended while its diagnostic output still creates a problem for the system recording the failure. Review needs to follow rejected input into error construction as well as accepted input into application values.

I see the October release as evidence that parser safety includes the shape and destination of intermediate results. Cookie parsing needs a count before object construction. A response reader needs an accumulation strategy that does not repeatedly copy its history. Archive metadata needs bounds after decompression, and diagnostics need to preserve the distinction between peer text and library explanation. Each fix acts where the implementation has enough information to enforce the relevant condition.