A vulnerability was found in Perl. This security issue occurs while Perl for Windows relies on the system path environment variable to find the shell (cmd.exe). When running an executable that uses the Windows Perl interpreter, Perl attempts to find and execute cmd.exe within the operating system. However, due to path search order issues, Perl initially looks for cmd.exe in the current working directory. This flaw allows an attacker with limited privileges to placecmd.exe in locations with weak permissions, such as C:\ProgramData. By doing so, arbitrary code can be executed when an administrator attempts to use this executable from these compromised locations.
Encode could allow a local authenticated attacker to gain elevated privileges on the system, caused by an untrusted search path flaw. By using a specially-crafted Encode::ConfigLocal library, an attacker could exploit this vulnerability to gain elevated privileges.
Accounts. A logic issue was addressed with improved file handling.
Leon Timmermans: On Mon, Jun 2, 2025 at 10:22 AM Florian Weimer via perl5-porters <perl5-porters () perl org> wrote: Stig Palmquist: References ---------- https://github.com/Perl/perl5/commit/918bfff86ca8d6d4e4ec5b30994451e0bd74aba9.patch Is this fix really correct?
+ ret = fdopendir(dup(mydirfd(dp)));
This does not create a separate open file description, only a second descriptor that shares the read position of the directory stream with the original directory stream. I think you have to use something like this:
ret = fdopendir(openat(mydirfd(dp), ".", ODIRECTORY | OCLOEXEC)); Our thread cloning in general is a terribly awkward business, where "what is the correct behavior" isn't always well defined or possible; I can see the arguments for both to be honest.
For file descriptors we don't create new file descriptions either (we don't even create new file descriptors, we refcount them), so why should we do so for directory handles? I'm not sure that expectation makes sense in that context. That's a fair point. It's more like fork in this regard, which has similar failure cases for DIR objects (shared file description, but unshared buffers and a separate descriptor). And if we did go the openat way, I don't think that seekdir on the new handle with the telldir of the old one is necessarily valid if the directory has been changed (I mean even a rewinddir can invalidate telldir's return value). I don't think we can do a fully correct copy here. Ugh, I had not considered that. Yes, glibc will have to switch to an implementation where telldir offsets are specific to a DIR for certain file systems on 32-bit architectures (because telldir returns long, not offt).
Hopefully sharing the description isn't much of a problem in practice.
Thanks, Florian
A heap buffer overflow vulnerability was discovered in Perl.
When there are non-ASCII bytes in the left-hand-side of the tr operator, Sdotransinvmap can overflow the destination pointer d.
$ perl -e '$ = "\x{FF}" x 1000000; tr/\xFF/\x{100}/;' Segmentation fault (core dumped)
It is believed that this vulnerability can enable Denial of Service and possibly Code Execution attacks on platforms that lack sufficient defenses.
On 2025-04-13 16:47, Solar Designer wrote: [..] As it was mentioned in the advance notification to distros, the issue was introduced in:
https://github.com/Perl/perl5/commit/a311ee08b6781f83a7785f578a26bbc21a7ae457
which is part of tags v5.33.1 to v5.41.10, so I guess those versions are also affected. The fix commit is effectively a revert of the bug commit. Hi Alexander,
Thank you for the feedback. We only considered release branches for the affected versions.
To fix this, the CVE record has been updated to take into account development versions and release candidates:
Versions: from 5.41.0 through 5.41.10 from 5.39.0 before 5.40.2-RC1 from 5.33.1 before 5.38.4-RC1
Best, -- Stig Palmquist
In Perl 5.34.0, function Sfinduninitvar in sv.c has a stack-based crash that can lead to remote code execution or local privilege escalation.
ProcessTable.pm in the Proc::ProcessTable module 0.45 for Perl, when TTY information caching is enabled, allows local users to overwrite arbitrary files via a symlink attack on /tmp/TTYDEVS.
Race condition in the rmtree function in File::Path 1.08 and 2.07 (lib/File/Path.pm) in Perl 5.8.8 and 5.10.0 allows local users to create arbitrary setuid binaries via a symlink attack, a different vulnerability than CVE-2005-0448, CVE-2004-0452, and CVE-2008-2827. NOTE: this is a regression error related to CVE-2005-0448. It is different from CVE-2008-5303 due to affected versions.
Race condition in the rmtree function in File::Path 1.08 (lib/File/Path.pm) in Perl 5.8.8 allows local users to to delete arbitrary files via a symlink attack, a different vulnerability than CVE-2005-0448, CVE-2004-0452, and CVE-2008-2827. NOTE: this is a regression error related to CVE-2005-0448. It is different from CVE-2008-5302 due to affected versions.
The rmtree function in lib/File/Path.pm in Perl 5.10 does not properly check permissions before performing a chmod, which allows local users to modify the permissions of arbitrary files via a symlink attack, a different vulnerability than CVE-2005-0448 and CVE-2004-0452.
Double free vulnerability in Perl 5.8.8 allows context-dependent attackers to cause a denial of service (memory corruption and crash) via a crafted regular expression containing UTF8 characters. NOTE: this issue might only be present on certain operating systems.
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-3626 to the following vulnerability:
Perl 5.10.1 allows context-dependent attackers to cause a denial of service (application crash) via a UTF-8 character with a large, invalid codepoint, which is not properly handled during a regular-expression match.
References: http://rt.perl.org/rt3/Public/Bug/Display.html?id=69973 https://issues.apache.org/SpamAssassin/showbug.cgi?id=6225 http://www.openwall.com/lists/oss-security/2009/10/23/8 http://perl5.git.perl.org/perl.git/commit/0abd0d78a73da1c4d13b1c700526b7e5d03b32d4
Safe.pm 2.24 and earlier, when used in Perl 5.10.0 and earlier, may allow attackers to break out of safe compartment in (1) Safe::reval or (2) Safe::rdo using implicitly called methods (such as DESTROY or AUTOLOAD) on implicitly blessed Perl objects, returned as a result of unsafe code evaluation. These methods could have been executed unrestricted by Safe, when such objects were accessed or destroyed. If a victim was tricked into running a specially-crafted Perl script, using Safe extension module, it could lead to intended Safe module restriction bypass. Different vulnerability than CVE-2010-1447.
Solution: Upgrade to Safe.pm v2.25 or higher.
References: [1] http://search.cpan.org/~rgarcia/Safe-2.27/Safe.pm
Acknowledgements:
Red Hat would like to thank Tim Bunce for responsibly reporting this issue. Upstream acknowledges Nick Cleaton as the original reporter.
It has been reported that Crypt::DSA, a Perl module for DSA signatures and key generation, used cryptographically weak / insecure method for random numbers generation on systems, where /dev/random file was not present. Due this flaw an attacker could be able to discover some portions of / whole secret DSA key, which has been created on such system.
References: [1] http://secunia.com/advisories/46275/ [2] https://rt.cpan.org/Public/Bug/Display.html?id=71421
Proposed upstream patch is to remove the affected fallback code part: [3] https://rt.cpan.org/Public/Bug/Display.html?id=71421#txn-984052 (though not approved yet)
Off-by-one error in the decodexs function in Unicode/Unicode.xs in the Encode module before 2.44, as used in Perl before 5.15.6, might allow context-dependent attackers to cause a denial of service (memory corruption) via a crafted Unicode string, which triggers a heap-based buffer overflow.
The bsdglob function in the File::Glob module for Perl before 5.14.2 allows context-dependent attackers to cause a denial of service (crash) via a glob expression with the GLOBALTDIRFUNC flag, which triggers an uninitialized pointer dereference.
It was found that perl-Data-FormValidator, a HTML form user input validator, used to treat certain invalid fields as valid, when the untaintallconstraints directive was used (default for majority of Data-FormValidator routines). A remote attacker could use this flaw to bypass perl Taint mode protection mechanism via specially-crafted input provided to the HTML form.
References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629511 [2] https://rt.cpan.org/Public/Bug/Display.html?id=61792
A security flaw was found in the way Perl performed laundering of tainted data. A remote attacker could use this flaw to bypass Perl TAINT mode protection mechanism (leading to commands execution on dirty arguments or file system access via contaminated variables) via specially-crafted input provided to the web application / CGI script.
Upstream bug report: http://rt.perl.org/rt3/Public/Bug/Display.html?id=87336
Relevant patch: http://perl5.git.perl.org/perl.git/commitdiff/539689e74a3bcb04d29e4cd9396de91a81045b99
References: [1] https://bugzilla.redhat.com/showbug.cgi?id=692844
Perl 5.10.x allows context-dependent attackers to cause a denial of service (NULL pointer dereference and application crash) by leveraging an ability to inject arguments into a (1) getpeername, (2) readdir, (3) closedir, (4) getsockname, (5) rewinddir, (6) tell, or (7) telldir function call.
Heap-based buffer overflow in the Perlrepeatcpy function in util.c in Perl 5.12.x before 5.12.5, 5.14.x before 5.14.3, and 5.15.x before 15.15.5 allows context-dependent attackers to cause a denial of service (memory consumption and crash) or possibly execute arbitrary code via the 'x' string repeat operator.
A denial of service flaw was found in the way Perl's rehashing code implementation (responsible for recalculation of hash keys and redistribution of hash content) used to react on certain user's input. If a Perl language based application accepted untrusted user input as hash keys, an attacker could use this flaw to cause the perl executable to consume excessive amount of memory (a denial of service via memory exhaustion).
References: [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/03/msg199755.html
Perl might allow context-dependent attackers to bypass the taint protection mechanism in a child process via duplicate environment variables in envp.
(1) cpan/Archive-Tar/bin/ptar, (2) cpan/Archive-Tar/bin/ptardiff, (3) cpan/Archive-Tar/bin/ptargrep, (4) cpan/CPAN/scripts/cpan, (5) cpan/Digest-SHA/shasum, (6) cpan/Encode/bin/enc2xs, (7) cpan/Encode/bin/encguess, (8) cpan/Encode/bin/piconv, (9) cpan/Encode/bin/ucmlint, (10) cpan/Encode/bin/unidump, (11) cpan/ExtUtils-MakeMaker/bin/instmodsh, (12) cpan/IO-Compress/bin/zipdetails, (13) cpan/JSON-PP/bin/jsonpp, (14) cpan/Test-Harness/bin/prove, (15) dist/ExtUtils-ParseXS/lib/ExtUtils/xsubpp, (16) dist/Module-CoreList/corelist, (17) ext/Pod-Html/bin/pod2html, (18) utils/c2ph.PL, (19) utils/h2ph.PL, (20) utils/h2xs.PL, (21) utils/libnetcfg.PL, (22) utils/perlbug.PL, (23) utils/perldoc.PL, (24) utils/perlivp.PL, and (25) utils/splain.PL in Perl 5.x before 5.22.3-RC2 and 5.24 before 5.24.1-RC2 do not properly remove . (period) characters from the end of the includes directory array, which might allow local users to gain privileges via a Trojan horse module under the current working directory.
Buffer overflow in the SgrokbslashN function in regcomp.c in Perl 5 before 5.24.3-RC1 and 5.26.x before 5.26.1-RC1 allows remote attackers to disclose sensitive information or cause a denial of service (application crash) via a crafted regular expression with an invalid '\N{U+...}' escape.
Compiling certain regular expression patterns with the case-insensitive modifier could cause a heap buffer overflow and crash perl.
Upstream patch:
https://perl5.git.perl.org/perl.git/commitdiff/96c83ed78aeea1a0496dd2b2d935869a822dc8a5
Bug report :
https://rt.perl.org/Public/Bug/Display.html?id=131582
Stack-based buffer overflow in the CPerlHost::Add method in win32/perlhost.h in Perl before 5.24.3-RC1 and 5.26.x before 5.26.1-RC1 on Windows allows attackers to execute arbitrary code via a long environment variable.
A denial of service flaw was found in the way Perl's rehashing code implementation (responsible for recalculation of hash keys and redistribution of hash content) used to react on certain user's input. If a Perl language based application accepted untrusted user input as hash keys, an attacker could use this flaw to cause the perl executable to consume excessive amount of memory (a denial of service via memory exhaustion).
References: [1] http://www.nntp.perl.org/group/perl.perl5.porters/2013/03/msg199755.html
End of life: 5/27/2025, End of support: 6/9/2024, Latest version: 5.36.3
End of life: 5/27/2025, End of support: 6/9/2024, Latest version: 5.36.3