Python 3.7.4 tightens HTTP input and executable lookup

A missing environment variable can affect which executable runs. An unexpected character in a URL can affect what an HTTP client sends. Python 3.7.4 corrects both behaviors, making this maintenance release relevant to programs that have not changed their own source.

The release page dates Python 3.7.4 to July 8, 2019. The release-tagged notes describe the HTTP correction as CVE-2019-9740 and record a separate Unix executable-search change under bpo-35755. Both affect boundaries where library code interprets information supplied by its caller or environment.

I value the standard library when it removes the need to implement complicated protocol behavior in application code. That dependence also makes patch-level changes material. The same function call can acquire a different rejection rule or search policy after the interpreter changes, even when its signature remains identical.

URL text becomes protocol input

The HTTP correction disallows URL paths containing embedded whitespace or control characters from passing through to the underlying client request. The notes say affected inputs now raise http.client.InvalidURL. They explicitly identify the rejected forms as potential header-injection URLs.

The mechanism matters because URL text eventually participates in a protocol request. Characters that appear to be ordinary input at one layer can have structural meaning at another. Rejecting them before the request proceeds preserves the client's assumptions about how its output is delimited.

This is an input rejection, with a visible exception as the documented result. An application that accepts externally supplied URLs can now encounter that exception where an earlier interpreter accepted the input. The behavior change is part of the correction because continuing with the same malformed text would preserve the ambiguity.

The error also creates an opportunity to report invalid input without starting a network operation. It does not tell the application how to present that failure to its own caller. A command-line downloader, an interactive tool and a service that processes queued work can each have a different error-reporting policy while respecting the same rejection.

A successful request construction still does not establish that a destination is appropriate for an application. The fix concerns whitespace and control characters reaching the HTTP request. Authorization to contact a host remains a separate application decision, so describing the patch as complete URL validation would overstate its purpose.

An unset PATH no longer implies the current directory

On Unix, the executable-search correction affects shutil.which and subprocess when PATH is absent. The release notes say they no longer search for an executable in the current directory in that situation. They also record the removal of that directory from posixpath.defpath.

The updated shutil.which behavior uses os.confstr("CS_PATH") when available and the environment variable is unset. That gives the fallback an operating-system source. The documented condition is an absent variable, which is more specific than a general assertion that Python never searches the current directory.

This changes an implicit dependency on the working directory. A program that asks for an executable by name should not accidentally obtain a different program merely because its inherited environment lacks PATH and its current directory contains a matching file. The correction reduces that particular exposure without changing the meaning of an explicitly supplied executable path.

For callers, the relevant inputs therefore include both the requested name and the search environment. A working directory often exists for data access or output placement. Treating it as an implicit source of executables can give it a security role that the application did not intend.

Scheme restrictions address another route to local files

The release notes also identify CVE-2019-9948. URLopener().open() and URLopener().retrieve() now disallow the local-file:// and local_file:// schemes to avoid file reading through those forms. That is a separate correction from the HTTP path restriction.

The distinction matters because rejecting malformed HTTP request text does not explain local file access through another scheme. These methods interpret a URL to select an operation. Restricting a scheme changes which operation the input can request, while rejecting control characters changes what an HTTP operation can contain.

My preference is to describe these fixes at the level of the actual boundary. It gives a maintainer a way to identify relevant callers without implying that every networking path or process launch shares the same defect. The HTTP client, URL opener and executable lookup have different responsibilities.

Maintenance includes the supplied runtime libraries

The release page records changes to libraries bundled with the Windows and macOS distributions. OpenSSL moves from 1.1.0 to 1.1.1, and SQLite moves to 3.28.0. Those statements concern the supplied distributions, so they should not be generalized to every independently built Python interpreter.

Taken together, the release changes both interpreter-level library behavior and parts of the distributed runtime environment. A caller can now see an explicit invalid-URL exception, and Unix executable lookup has a narrower fallback when PATH is missing. These are concrete reasons to treat the maintenance release as a change in runtime contracts even when an application needs no new Python syntax.