Go 1.26.4 fixes parser costs and unescaped error text
The June security release limits repeated work in MIME and hostname parsing and escapes hostile text in protocol errors. These fixes concern resources and diagnostic integrity before an application accepts input.
The Go 1.26.4 release, dated June 2, includes security fixes in mime, net/textproto, and crypto/x509. Its announcement describes three vulnerabilities and publishes Go 1.25.11 alongside it. Two defects concern computational work on hostile inputs. The other concerns what happens when hostile input becomes part of an error message.
I value Go's explicit treatment of errors because it makes operational policy part of ordinary program flow. This release is a useful reminder that an error value can contain information supplied by an attacker. Rejecting an input does not establish that processing it was cheap or that displaying the resulting error is harmless. Those properties need attention alongside the application's acceptance decision.
Preserving malformed MIME text can repeat expensive work
The MIME issue, CVE-2026-42504, describes WordDecoder.DecodeHeader preserving an encoded word when decoding fails. That preservation is intentional behavior. The defect is in how parsing resumes after failure. It consumes the initial =? and then tries to parse the remainder again.
An input with many =?x?y? prefixes and a single final ?= makes that recovery strategy repeat work. The report describes quadratic or nearly quadratic complexity. The security correction improves handling of these malicious malformed headers. It does not establish that preserving undecodable text is itself wrong or that every malformed encoded word causes excessive resource use.
The distinction matters to a maintainer deciding what to test. A test that expects every malformed header to return an error could assert a behavior the function does not promise. A useful regression test must preserve the malformed-input recovery behavior while also exercising the repeated-prefix condition. The compatibility requirement and the resource requirement belong in the same review, even if they use different assertions.
I would also keep ordinary invalid inputs separate from adversarially structured ones in the test data. The first establishes what a caller receives when decoding fails. The second investigates how much work the implementation performs before producing that result. Combining those into a single label saying invalid MIME would hide the reason the security case exists.
Hostname verification repeated an invariant operation
The hostname-verification issue, CVE-2026-27145, concerns repeated splitting of the same hostname. VerifyHostname loops over DNS subject alternative names, and matchHostnames split the candidate hostname on each iteration. Work therefore increased with both the number of certificate names and the size or label count of the hostname.
The announcement identifies the correction as splitting the candidate hostname once. More importantly for exposure analysis, hostname checking occurs before certificate-chain building. An otherwise untrusted certificate can therefore cause this work. The issue identifies TLS clients and direct callers of VerifyHostname or verification with VerifyOptions.DNSName as relevant users.
I find that ordering more useful than a general statement that certificate verification is expensive. It says where rejection fails to bound the earlier computation. A test that ends with an untrusted-chain error can still have exercised the vulnerable path. The expected error should remain part of the test, but it cannot be the only observation when the defect concerns cost before failure.
For an application review, I would ask whether the program accepts a hostname from another party as well as a certificate. Those are separate inputs in the reported cost relationship. I would avoid copying a performance result from one hostname and assuming it covers every other shape. A representative test plan would vary name-list length independently of hostname structure, then explain which part of the workload each variation investigates.
That is a proposed method of evaluation, not a claim about measured performance in my own systems. The published mechanism supplies the reason to vary those inputs. It does not supply a universal latency threshold suitable for every deployment. An operator would need a threshold based on the service's own resource budget and concurrency expectations.
Errors can preserve an attacker's control characters
The text protocol issue, CVE-2026-42507, concerns unescaped input embedded in errors. Downstream users include net/http and net/smtp. The issue describes misleading log content through injected newlines. The announcement also identifies terminal control bytes as possible injected content and gives HTTP response-header parsing as an example of input controlled by a remote party.
That changes what I would consider a complete error-path test. Checking that an HTTP client returns an error only verifies the first part of the path. If the application logs that error, its representation becomes another relevant behavior. I would include an error containing control characters in a logging test and inspect the actual serialized record, not just the error object's existence.
I would also distinguish information supplied by a remote endpoint from the application's own diagnostic context. A remote fragment may help explain the failure, but a reviewer should be able to tell where that fragment begins and ends. Escaping makes the fragment less likely to masquerade as an independent message. The library fix addresses its own errors, while the application remains responsible for how it assembles other remote data into diagnostics.
Validation includes the work done before rejection
These fixes influence how I would review an input-processing component. The MIME decoder needs to preserve its documented recovery result without excessive rescanning. Hostname verification needs to avoid repeating work that does not depend on the current certificate name. Protocol errors need to represent rejected input without giving it unintended control over the output.
For an upgrade, I would identify the application artifacts that contain the affected packages and verify that replacement builds reach their deployments. I would then retain focused tests for the malformed-header and diagnostic cases relevant to the application. Their descriptions should state the input structure and the property under test, so future maintainers can change the implementation without accidentally removing the condition that prompted the test. A test name that says only that parsing fails would provide too little explanation for preserving a long repeated-prefix fixture or an error containing embedded newlines.