PERLSECPOLICY(1perl)

💖 perlsecpolicy(1perl) 💖 — Perl security report handling policy

🌸 NAME 🌸

perlsecpolicy - Perl security report handling policy

✨ DESCRIPTION ✨

Okay so real talk: the Perl project takes security issues seriously. 💖

The responsibility for handling security reports in a timely and effective manner has been delegated to a security team composed of a subset of the Perl core developers.

This document describes how the Perl security team operates and how the team evaluates new security reports.

---

🚨 REPORTING SECURITY ISSUES IN PERL 🚨

If you believe you have found a security vulnerability in the Perl interpreter or modules maintained in the core Perl codebase, email the details to perl-security@perl.org (mailto:perl-security@perl.org). This address is a closed membership mailing list monitored by the Perl security team.

You should receive an initial response to your report within 72 hours. If you do not receive a response in that time, please contact the Perl Steering Council steering-council@perl.org (mailto:steering-council@perl.org).

When members of the security team reply to your messages, they will generally include the perl-security@perl.org address in the "To" or "CC" fields of the response. This allows all of the security team to follow the discussion and chime in as needed. Use the "Reply-all" functionality of your email client when you send subsequent responses so that the entire security team receives the message.

The security team will evaluate your report and make an initial determination of whether it is likely to fit the scope of issues the team handles. General guidelines about how this is determined are detailed in the "WHAT ARE SECURITY ISSUES" section.

If your report meets the team's criteria, you will be provided the issue's CVE ID(s). Issue identifiers have the form CVE-YYYY-NNNNN, where YYYY is the year the CVE was reported, and NNNNN is a unique number. Include this identifier with any subsequent messages you send.

The security team will send periodic updates about the status of your issue and guide you through any further action that is required to complete the vulnerability remediation process. The stages vulnerabilities typically go through are explained in the "HOW WE DEAL WITH SECURITY ISSUES" section.

---

🔍 WHAT ARE SECURITY ISSUES 🔍

A vulnerability is a behavior of a software system that compromises the system's expected confidentiality, integrity or availability protections.

A security issue is a bug in one or more specific components of a software system that creates a vulnerability.

Software written in the Perl programming language is typically composed of many layers of software written by many different groups. It can be very complicated to determine which specific layer of a complex real-world application was responsible for preventing a vulnerable behavior, but this is an essential part of fixing the vulnerability.

🫶 Software covered by the Perl security team 🫶

The Perl security team handles security issues in:

• The Perl interpreter
• The Perl modules shipped with the interpreter that are developed in the core Perl repository
• The command line tools shipped with the interpreter that are developed in the core Perl repository

Files under the cpan/ directory in Perl's repository and release tarballs are developed and maintained independently. The Perl security team does not directly handle security issues for these modules, but since this code is bundled with Perl, we will assist in forwarding the issue to the relevant maintainer(s) and you can still report these issues to us in secrecy.

👀 Bugs that may qualify as security issues in Perl 👀

Perl is designed to be a fast and flexible general purpose programming language. The Perl interpreter and Perl modules make writing safe and secure applications easy, but they do have limitations.

As a general rule, a bug in Perl needs to meet all of the following criteria to be considered a security issue:

• The vulnerable behavior is not mentioned in Perl's documentation or public issue tracker.
• The vulnerable behavior is not implied by an expected behavior.
• The vulnerable behavior is not a generally accepted limitation of the implementation.
• The vulnerable behavior is likely to be exposed to attack in otherwise secure applications written in Perl.
• The vulnerable behavior provides a specific tangible benefit to an attacker that triggers the behavior.

💀 Bugs that do not qualify as security issues in Perl 💀

There are certain categories of bugs that are frequently reported to the security team that do not meet the criteria listed above.

The following is a list of commonly reported bugs that are not handled as security issues.

Feeding untrusted code to the interpreter

The Perl parser is not designed to evaluate untrusted code. If your application requires the evaluation of untrusted code, it should rely on an operating system level sandbox for its security.

Stack overflows due to excessive recursion

Excessive recursion is often caused by code that does not enforce limits on inputs. The Perl interpreter assumes limits on recursion will be enforced by the application.

Out of memory errors

Common Perl constructs such as pack, the x operator, and regular expressions accept numeric quantifiers that control how much memory will be allocated to store intermediate values or results. If you allow an attacker to supply these quantifiers and consume all available memory, the Perl interpreter will not prevent it.

Escape from a Safe compartment

Opcode restrictions and Safe compartments are not supported as security mechanisms. The Perl parser is not designed to evaluate untrusted code.

Use of the "p" and "P" pack templates

These templates are unsafe by design.

Stack not reference-counted issues

These bugs typically present as use-after-free errors or as assertion failures on the type of a SV. Stack not reference-counted crashes usually occur because code is both modifying a reference or glob and using the values referenced by that glob or reference.

This type of bug is a long standing issue with the Perl interpreter that seldom occurs in normal code. Examples of this type of bug generally assume that attacker-supplied code will be evaluated by the Perl interpreter.

Thawing attacker-supplied data with Storable

Storable is designed to be a very fast serialization format. It is not designed to be safe for deserializing untrusted inputs.

Using attacker supplied SDBM_File databases

The SDBM_File module is not intended for use with untrusted SDBM databases.

Badly encoded UTF-8 flagged scalars

This type of bug occurs when the ":utf8" PerlIO layer is used to read badly encoded data, or other mechanisms are used to directly manipulate the UTF-8 flag on an SV.

A badly encoded UTF-8 flagged SV is not a valid SV. Code that creates SV's in this fashion is corrupting Perl's internal state.

Issues that exist only in blead, or in a release candidate

The blead branch and Perl release candidates do not receive security support. Security defects that are present only in pre-release versions of Perl are handled through the normal bug reporting and resolution process.

CPAN modules or other Perl project resources

The Perl security team is focused on the Perl interpreter and modules maintained in the core Perl codebase. The team has no special access to fix CPAN modules, applications written in Perl, Perl project websites, Perl mailing lists or the Perl IRC servers.

Emulated POSIX behaviors on Windows systems

The Perl interpreter attempts to emulate fork, system, exec and other POSIX behaviors on Windows systems. This emulation has many quirks that are extensively documented in Perl's public issue tracker. Changing these behaviors would cause significant disruption for existing users on Windows.

🧚 Bugs that require special categorization 🧚

Some bugs in the Perl interpreter occur in areas of the codebase that are both security sensitive and prone to failure during normal usage.

Regular expressions

Untrusted regular expressions are generally safe to compile and match against with several caveats. The following behaviors of Perl's regular expression engine are the developer's responsibility to constrain.

The evaluation of untrusted regular expressions while use re 'eval'; is in effect is never safe.

Regular expressions are not guaranteed to compile or evaluate in any specific finite time frame.

Regular expressions may consume all available system memory when they are compiled or evaluated.

Regular expressions may cause excessive recursion that halts the perl interpreter.

As a general rule, do not expect Perl's regular expression engine to be resistant to denial of service attacks.

DB_File, ODBM_File, or GDBM_File databases

These modules rely on external libraries to interact with database files.

Bugs caused by reading and writing these file formats are generally caused by the underlying library implementation and are not security issues in Perl.

Bugs where Perl mishandles unexpected valid return values from the underlying libraries may qualify as security issues in Perl.

Algorithmic complexity attacks

The perl interpreter is reasonably robust to algorithmic complexity attacks. It is not immune to them.

Algorithmic complexity bugs that depend on the interpreter processing extremely large amounts of attacker supplied data are not generally handled as security issues.

See "Algorithmic Complexity Attacks" in perlsec for additional information.

---

🛡️ HOW WE DEAL WITH SECURITY ISSUES 🛡️

The Perl security team follows responsible disclosure practices. Security issues are kept secret until a fix is readily available for most users. This minimizes inherent risks users face from vulnerabilities in Perl.

Hiding problems from the users temporarily is a necessary trade-off to keep them safe. Hiding problems from users permanently is not the goal.

When you report a security issue privately to the perl-security@perl.org (mailto:perl-security@perl.org) contact address, we normally expect you to follow responsible disclosure practices in the handling of the report. If you are unable or unwilling to keep the issue secret until a fix is available to users you should state this clearly in the initial report.

The security team's vulnerability remediation workflow is intended to be as open and transparent as possible about the state of your security report.

🔐 Perl's vulnerability remediation workflow 🔐

Initial contact

New vulnerability reports get a first reply within 72 hours of landing in the security team's mailing list — bestie, that's the clock. If that window passes and you've heard nothing, hit up the Perl Steering Council at steering-council@perl.org. 📬

That first response just confirms your message made it and gives you a rough idea of when the team's triage analysis will happen. Basic courtesy, but iconic.

🩺 Initial triage

The security team reads the report and figures out whether it's even likely to meet the criteria for being handled as a security issue. Vibe check, basically.

Goal: complete the initial triage within two weeks. Complex issues that need a lot of discussion or research? Yeah, those take longer. 🐌

If the report can't be reproduced, or it just doesn't meet the team's criteria for a security issue, you'll get an email about it — and you get a chance to respond. No ghosting here. 💖

🏷️ CVE assignment

Reports that survive initial triage get turned into CVEs. When a report levels up to this stage, the security team reserves one or more CVEs. The identifiers look like CVE-YYYY-NNNNN, where YYYY is the year the CVE was reported and NNNNN is a unique number. Every bit of communication about the issue from then on uses that CVE.

⚠️ Heads up: getting one of these IDs does not confirm the report is actually a vulnerability in Perl. Lots of reports need way more analysis before anyone can say that. And at this stage? The vulnerability should not be discussed publicly. Zip it. 🤐

An internal ticket also gets opened. Those identifiers look like perl-security#NNN or Perl/perl-security#NNN.

The issues in the security team's private tracker are where details about the problem get collected and progress toward a resolution gets tracked. When the issue is resolved, those notes and other details do not go public. Why? Because keeping the notes private lets the team talk freely about attack methods, attack tools, and other related private issues. ✨

🛠️ Development of patches

Security team members dig into the report and the related code, in detail, to build fixes for supported versions of Perl.

If the team finds at this stage that the reported issue doesn't meet their criteria, you get emailed and you get a chance to respond before the issue gets closed. That's the door, respectfully. 🚪

The team may also talk through potential fixes with you, or hand you patches to test, during this stretch.

📝 The CVE is drafted

Once an issue is fully confirmed and a potential fix exists, the security team talks to the CPAN Security Group CNA at https://security.metacpan.org/.

Details get gathered: things like the range of vulnerable Perl versions and the identities of the people who discovered the flaw.

The team may ask you to clarify the exact name to use when crediting discovery. The "Vulnerability credit and bounties" section of this document breaks down the preferred format for that credit. 🎀

📢 Pre-release notifications

Once the team is satisfied that the fix is ready to go public, a pre-release notification announcement goes out to the Openwall Distros List at https://oss-security.openwall.org/wiki/mailing-lists/distros. Other repackagers get notified too.

📌 NOTE: Any embargoed information sent to the Openwall Distros List expires within 2 weeks of disclosure to that location.

That pre-release announcement contains a list of the Perl versions affected by the flaw, an analysis of the risks to users, the patches the security team produced, and any info the team has about mitigations or backporting fixes to older versions of Perl.

It also includes a specific target date for the public announcement. The gap between the pre-release announcement and that release date is what lets redistributors prep and test their own updates and announcements. During this period the vulnerability details and fixes are embargoed (peep "Embargo Period" below) and should not be shared publicly. And yes — that "Embargo Period" can get extended further if testing turns up problems. 😬

You get sent the portions of pre-release announcements relevant to the specific issue you reported. That email includes the target release date. If the target release date changes, you get more updates. You stay in the loop, fr fr. 🫶

🧪 Pre-release testing

Real talk: the Perl security team does not directly produce official Perl releases. The team releases security fixes by placing commits in Perl's public git repository and sending announcements.

But lots of users and redistributors prefer official Perl releases over applying patches to an older release. So the security team works with Perl's release managers to make that happen. Teamwork, slay. 🤝

New official releases of Perl are generally produced and tested on private systems during the pre-release "Embargo Period".

🚀 Release of fixes and announcements

The "Embargo Period" ends when the security fixes get committed to Perl's public git repository. Announcements go out to the perl5-porters mailing list (https://lists.perl.org/list/perl5-porters.html) and the oss-security mailing list (https://oss-security.openwall.org/wiki/mailing-lists/oss-security).

If official Perl releases are ready, they get published at this time and announced on the perl5-porters mailing list (https://lists.perl.org/list/perl5-porters.html).

Once the release process is finished, the security team sends a follow-up notification to everyone who took part in the pre-release "Embargo Period". Vulnerability reporters and Perl redistributors should not publish their own announcements or fixes until the Perl security team's release process is complete. Wait your turn, bestie. ⏳

---

🌐 Publicly known and zero-day security issues

The security team's vulnerability remediation workflow assumes issues are reported privately and kept secret until they're resolved. That's not always how life goes — sometimes info leaks before a fix is ready. 🙈

When that happens, the team has to decide whether operating in secret increases or decreases the risk to Perl users. Sometimes being open about the risk lets users defend against it. Other times, calling attention to an unresolved security issue just makes it more likely to get misused. It's a whole thing.

💀 Zero-day security issues

If an unresolved critical security issue in Perl is being actively abused to attack systems, the security team sends out announcements as fast as humanly possible, along with any mitigations the team has on hand.

Perl's public defect tracker gets used to handle the issue so that additional information, fixes, and CVE IDs are visible to affected users ASAP. 🔥

🫧 Other leaks of security issue information

Depending on how prominent the revealed info about a security issue is, and how likely that issue is to become a zero-day attack, the security team may skip all or part of its normal remediation workflow. Yeah, straight to the point.

If the security team learns about a significant security issue after it's already been identified and resolved in Perl's public issue tracker, the team will request a CVE ID and send an announcement to inform users.

---

💐 Vulnerability credit and bounties

The Perl project genuinely appreciates the effort security researchers pour into making Perl safe and secure. Like, actually appreciates it. 🥹

Since so much of this work is hidden from the public, crediting researchers publicly is an important part of the vulnerability remediation process. You did the thing, you get the flowers. 🌸

🎤 Credits in vulnerability announcements

When security issues get fixed, the team attempts to credit the specific researcher(s) who discovered the flaw in the announcements.

Credits go out using the researcher's preferred full name.

If the researcher's contributions were funded by a specific company or part of an organized vulnerability research project, the team will include a short name for that group — at the researcher's request.

Perl's announcements are written in the English language using the 7bit ASCII character set, so they stay reproducible across a variety of formats. That means no hyperlinks, no domain names and no marketing material in these acknowledgments. Keep it clean. ✨

And in the event that proper credit for vulnerability discovery can't be established, or there's a disagreement between the Perl security team and the researcher about how the credit should be given — it gets omitted from announcements. Awkward, but there it is. 💀

💸 Bounties for Perl vulnerabilities

The Perl project is a non-profit volunteer effort. We do not provide any monetary rewards for reporting security issues in Perl. No bag, sorry bestie. 🫶

---

🤫 Embargo Period

In the context of Perl's coordinated vulnerability disclosure process, an "embargo" is the period of time during which information about a reported vulnerability stays confidential. The embargo begins when a security issue is reported to the Perl security team and lasts until a fix has been developed and that fix is provided in a public location.

The whole point of the embargo is to let the security team work on a fix and prepare a coordinated release without the risk of the vulnerability being exploited or disclosed prematurely. It helps ensure users of Perl and its modules are protected from potential attacks while the security issue is being dealt with. Protective era. 🛡️

Embargo lengths vary depending on how complex the issue is and how long the fix takes to build. The security team communicates the expected duration of the embargo to the reporter and to any other parties involved.

As a goal, the security team aims to keep the total embargo period to less than 60 days. It may get extended, though, due to these factors:

• The complexity of the issue 🧩
• The time required to develop a fix ⏱️
• The need for additional testing or validation 🧪
• The availability of resources to address the issue 🫂
• Public holidays which might affect the ability of end users to apply the fix 🎉

During this period:

• Details of the vulnerability are shared only with a restricted group of trusted contributors (such as core maintainers, toolchain maintainers, and packagers), solely for the purpose of preparing and testing a fix. 🔐
• Reporters are asked not to disclose the issue publicly or share details with third parties until the embargo is lifted. 🤐
• The duration of the embargo may vary depending on the severity and complexity of the issue, but typically lasts until the relevant security patch is released and announced. ⏳
• Breaking the embargo — by prematurely disclosing details — undermines the coordinated disclosure process and can hinder the coordinated effort to protect users effectively. Don't do it. Seriously, don't. 💔

The Perl security team is so committed to squashing vulns fast, and they're respectfully begging everyone in the chat to honor the embargo period — it's literally there to protect users and downstream distributions, bestie. Respect the embargo, protect the people. 🤝

---

🦋 Example Release Process 🦋

okay so here's a little ✨storytime✨ — a totally hypothetical example of how a security issue reported by a third party might get handled by the Perl security team, all the way from the first report to the final release. Buckle up. 🎀

Step 1: Reporting the Vulnerability 💌

A security researcher discovers a vulnerability in the Perl interpreter that lets an attacker cause a denial of service under specific conditions. (Not iconic of the interpreter, ngl.) The researcher emails all the deets to perl-security@perl.org — including a proof-of-concept script and a description of the impact. Slay, that's exactly the move.

Step 2: Initial Response 📬

Within 72 hours, the security team acknowledges receipt of the report and confirms the issue is under investigation. The researcher gets informed of the expected timeline for triage. Communication? Chef's kiss. 💅

Step 3: Initial Triage 🔍

The security team reproduces the issue using the provided proof-of-concept and determines that it meets the criteria for handling as a security issue. One or more CVEs get reserved in coordination with the CPAN Security Group CNA (https://security.metacpan.org/2025/02/25/cpansec-is-cna-for-perl-and-cpan.html). Then the team notifies the researcher, referencing the CVE IDs. Receipts delivered. 📎

Step 4: Development of a Fix 🛠️

The security team analyzes the affected code and develops a patch to address the vulnerability. That patch gets tested against various scenarios to make sure it resolves the issue without introducing regressions — because a fix that breaks everything else is NOT the vibe. The researcher is invited to test the patch privately and provide feedback. 🫶

Step 5: Pre-Release Notification 📢

The security team prepares a pre-release notification — including details of the vulnerability, the affected Perl versions, and the patch. This notification is sent to major redistributors of Perl under embargo, giving them time to prepare their own updates. Quietly getting ready behind the scenes, main character energy fr fr. 👑

Step 6: Pre-Release Testing 🧪

During the remaining embargo period, pre-notified redistributors prepare packages for release and test the patch to ensure compatibility with their systems. Teamwork makes the dream work. 🌈

Step 7: Public Release 🎉

On the scheduled release date, the patch is committed to Perl's public git repository. An official announcement is sent to the perl5-porters (https://lists.perl.org/list/perl5-porters.html) and oss-security (https://oss-security.openwall.org/wiki/mailing-lists/oss-security) mailing lists. If applicable, a new Perl release containing the fix is published. It's giving drop day. ✨

The security team will notify CPAN Security Group CNA to publish the CVE.

Step 8: Vendor and Third-Party Updates 🚚

Vendors and third-party maintainers incorporate the patch or updated Perl release into their distributions. The security team follows up with all parties involved to ensure the issue is resolved and users are protected. And that's the whole loop, closed and cute. 💖

---

and that's a wrap on the whole page, bestie!! 🎀 This was perl version v5.44.0, dated 2026-10-17 — go forth and report responsibly, protect the users, honor the embargo, and stay iconic. 💅🦋🌸