Go 1.18.3 repairs Windows paths and TLS ticket privacy
June's Go maintenance release fixes Windows command and path handling, a random-reader loop, and missing TLS ticket-age randomization. The defects affect different security properties and call paths.
Cleaning a path is supposed to preserve its meaning while simplifying its spelling. On Windows, Go could remove a leading dot component and expose a drive prefix with a different interpretation. That failure is one of four security corrections in Go 1.18.3, released on 1 June. The same update addresses unintended executable selection, a stalled random read and a TLS privacy omission.
The release history names the affected packages. Dmitri Shuralyov's contemporaneous announcement gives their security descriptions and announces Go 1.17.11 alongside the new maintenance release. Reading the individual mechanisms is more useful than treating the four fixes as equivalent reasons for alarm.
I like Go because it usually makes operational behavior possible to explain from a small amount of code. These corrections show where that explanation must include platform rules and protocol fields. An API's short name does not describe all the assumptions made when its result reaches another component.
A cleaned path acquired a drive interpretation
The path/filepath report demonstrates the problem with Windows paths containing a colon. Cleaning a path beginning with a dot and separator could produce a string beginning with a drive designator. The report includes a rooted example whose output becomes an absolute path and another example involving alternate data stream syntax.
Those examples require precise language. A bare drive designator and a drive-rooted path are not interchangeable descriptions. The report's useful point is that removing the prefix can change the path's interpretation, including making one of its examples absolute. Simplification cannot safely be evaluated only by the number of components it removes.
The report also supplies an HTTP file-serving reproducer. That connects the library behavior to a caller that handles paths supplied through a request. It does not establish that every use of filepath.Clean exposes files. The caller's construction and interpretation of the returned path determine whether the change in meaning crosses an intended directory boundary.
A path helper therefore has a semantic obligation in addition to a textual one. Its output must remain an appropriate representation of the intended location under the destination platform's rules. A transformation that is harmless for one naming scheme can reveal special syntax in another.
That is particularly relevant to portable applications. The same source-level operation can meet different path grammars on different systems. A review based only on ordinary slash-separated components can miss the significance of drive prefixes and colons on Windows.
Missing command configuration selected an executable
The os/exec correction is CVE-2022-30580. According to the announcement, an unset Cmd.Path on Windows could cause a binary named ..com or ..exe in the working directory to execute. Affected entry points include the command's execution and output methods.
The underlying issue states the expected behavior directly. An unset command path should produce an error. That expectation matters because the caller has failed to identify a program to execute. Treating that state as an opportunity to derive another executable name gives the working directory an unintended role in program selection.
This differs from a general claim that command execution always invokes a shell. The advisory describes particular filenames and a missing path on Windows. Preserving those conditions makes the account actionable. It directs attention toward code that constructs command values incompletely and then invokes an execution method.
My preference is for invalid configuration to remain an error at the point where it becomes observable. A process-launching API has substantial authority. Deriving an executable from an empty field can turn a configuration defect into an action the caller did not request.
A large random read stopped making progress
CVE-2022-30634 concerns crypto/rand on Windows. The primary report explains that the operating-system random function accepts a length limited to a 32-bit unsigned value. The Go reader truncated a larger buffer length when requesting bytes.
After an initial partial result, the remaining length could be an exact multiple of the 32-bit range. Truncation then produced zero. The surrounding loop kept retrying without reducing the buffer, so the operation could hang indefinitely. The defect combines an integer-width conversion with an assumption that another successful iteration will make progress.
The report explicitly characterizes the practical impact as limited because the triggering buffer is extremely large. It also says the maintainers found no realistic remotely reachable library path. Those qualifications belong with the mechanism. A security label does not justify turning an unusual local call into an assertion of ordinary remote exploitability.
The case remains useful for understanding batching code. When an interface accepts less than the full request, the caller must deliberately choose a representable chunk. Casting the total length is not equivalent to limiting the chunk to the interface's maximum. A loop's progress condition deserves attention alongside its handling of errors.
Session resumption exposed an unobscured age
The TLS correction, CVE-2022-30629, concerns ticket_age_add in TLS 1.3 session tickets. The issue report identifies a field left at zero. It cites the protocol requirement for a fresh random value in each ticket. The client adds that value to the ticket's age modulo the 32-bit range before transmitting the result during resumption.
Without the random addition, an observer can compare ticket ages to correlate connections. That is the privacy property identified in the release announcement. It is distinct from a failure to encrypt application data or a general authentication bypass. An accurate account should name the information the missing field exposes.
This is also a reminder that successful interoperability does not establish every protocol property. A session can resume while omitting a randomization requirement intended to reduce what an observer can infer. The failure may not appear as a rejected handshake, so an ordinary functional test can miss it.
I regard this release as a set of specific contract repairs. Path normalization must preserve interpretation under Windows rules. Command execution must reject a missing executable choice. Random reads must make progress, and session tickets must carry the randomization their privacy behavior requires. The affected code paths explain why each correction matters to a different set of callers.