Perl's development snapshot carries the interpreter security repairs

A development interpreter needs security corrections even while its language behavior continues to change. Perl 5.39.6 includes the two security repairs documented in the stable maintenance release the previous month. It also rejects a previously accepted parsing arrangement around return. Those changes share a snapshot but make different promises to callers.

The release history records 5.39.6 on December 30. Its release notes identify CVE-2023-47038 and CVE-2023-47039. The earlier 5.38.2 notes already document those issues. December's snapshot is therefore an incorporation event for this development line, not a new public discovery of the flaws.

I value that distinction because version numbers can obscure the purpose of an update. A newer development interpreter can include a necessary security repair and still change other behavior under development. Its security contents do not turn the whole snapshot into an ordinary stable-branch patch.

Pattern compilation remains the affected stage

CVE-2023-47038 concerns an illegal user-defined Unicode property in a crafted regular expression. The notes describe a one-byte attacker-controlled overflow in a heap buffer during compilation, with the stated affected stable-version range running from 5.30.0 through 5.38.0.

That timing matters to callers that accept patterns as input. Compiling an attacker-selected regex enters the parser before the application has a match result to inspect. A policy about what to do after matching cannot by itself correct a defect reached during compilation.

The advisory's wording also distinguishes a pattern from the text searched by that pattern. Here the relevant crafted input is the expression being compiled. Nothing in the release notes claims that every ordinary subject string can exploit every fixed regex. Exposure depends on reaching the affected compiler behavior.

The December notes repeat the security account without claiming a different overwrite size or a newly established exploit outcome. That limits the conclusion appropriately. The development snapshot contains the repair, while the public description still identifies the same reported memory-safety problem.

Shell identity depends on executable resolution

CVE-2023-47039 concerns Windows Perl finding cmd.exe in the current working directory before the intended system shell. The notes describe an attacker placing a same-named executable in a location with weak permissions. A more privileged user then invoking the affected program from that location can execute the attacker's binary.

The selected shell is the security boundary in that account. Even a legitimate command can reach the wrong executable if lookup accepts a program from a directory controlled by a less privileged actor. Checking whether the command's text looks ordinary does not establish which binary handles it.

This issue has Windows-specific preconditions that the regex compilation issue does not share. An application can be affected by one path without using the other. Carrying both repairs in the same snapshot is a release-management fact, not evidence that their mechanisms or exposure conditions are interchangeable.

For developers using the 5.39 series, the snapshot's notes now account for both fixes explicitly. That makes it possible to identify the documented development artifact without treating a stable-branch announcement as proof about an arbitrary earlier development build.

Return loses an accidental indirect object

The same release's incompatible-change section rejects indirect objects after return. Its example begins with an undefined sum name in an expression intended to return a sum over filtered positive arguments. Previously the parser could treat that bareword as an extra typeglob argument, followed by the filtered values.

The reported result includes *main::sum followed by the positive arguments. That is substantially different from calling a summation function. The source can look plausible while the parser has accepted a meaning the author did not intend.

Perl 5.39.6 rejects that arrangement. Its new diagnostic says a comma is missing after the first argument to return, and explains that return is not an operator accepting a filehandle or indirect object ahead of its argument list. The correction makes the unexpected parse fail instead of returning the accidental list.

This is distinct from a claim that normal function calls in return expressions are prohibited. The release note concerns the indirect-object parse illustrated by the undefined bareword. Understanding that trigger gives the diagnostic a more precise meaning than saying that the interpreter has generally tightened returns.

I prefer an explicit rejection in this case because the previously accepted result conceals the missing function declaration behind valid-looking output. That is a judgment about the example's failure mode. It does not erase the need to recognize the change as incompatible for source that relied on the old parse.

Diagnostics describe the operation that failed

The release also improves several allocation-failure messages. Places that previously reported only a generic out-of-memory error now identify Perl and the general allocation area. A separate diagnostic describes an oversized vec extension in lvalue context. These messages distinguish implementation failures that previously offered less context.

Those diagnostic changes fit the snapshot's development role alongside the parser adjustment. The security section records repairs to existing vulnerabilities, while other sections describe behavior and observability still evolving. Perl 5.39.6 provides all of that information in one versioned account, with each change retaining its own scope and compatibility implications.