PERLSECPOLICY(1)

🎀 NAME 🎀

perlsecpolicy — Perl security report handling policy. 💖 Also, hey bestie, this is from the Perl Programmers Reference Guide, so you know it's official-ish. 🌸

---

🌸 DESCRIPTION 🌸

Okay so first thing: the Perl project takes security issues seriously. Periodt. 💅 The responsibility for handling security reports in a timely and effective manner has been delegated to a security team made up of a subset of the Perl core developers.

This document is basically the team's whole vibe: how the Perl security team operates and how the team evaluates new security reports. ✨

---

🚨 REPORTING SECURITY ISSUES IN PERL 🚨

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

You should get an initial response to your report within 72 hours. If you don't get a response in that time, please contact the Perl Steering Council at steering-council@perl.org (the mailto:steering-council@perl.org address). 🫶

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 lets all of the security team 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. No cap.

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 (the 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

Bestie, new reports get an initial reply within <strong>72 hours</strong></strong> of landing in the security team's mailing list. 💖 If that window goes by and you've heard nothing, hit up the Perl Steering Council at steering-council@perl.org.

That first reply from the security team will confirm they got your message and give you an estimated timeframe for their triage analysis. 🫶

---

✨ Initial triage ✨

The security team evaluates the report and decides whether it's likely to meet the criteria for handling as a security issue.

Their goal is to finish initial report triage within <strong>two weeks</strong>. Complex issues needing serious discussion or research? Yeah, those can take longer. 😭

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

✨ CVE assignment ✨

Security reports that pass initial triage analysis get turned into CVEs. When a report levels up to this stage, the security team reserves one or more CVEs. Issue identifiers look like CVE-YYYY-NNNNN, where YYYY is the year the CVE was reported and NNNNN is a unique number. That CVE gets used in all the follow-up communications about the issue.

Heads up bestie: getting one of these IDs does <strong>not</strong> confirm that the security report is actually a vulnerability in Perl. Many reports need further analysis before anyone can say that. And at this stage — do not discuss the vulnerability publicly. 🤫

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

Issues in the security team's private tracker are how they collect details about the problem and track progress toward a fix. Those notes and other details are <strong>not</strong> made public when the issue is resolved. Keeping them private lets the team talk freely about attack methods, attack tools, and other related private issues. 🔥

✨ Development of patches ✨

Members of the security team inspect the report and the related code in detail to produce fixes for supported versions of Perl.

If, at this stage, the team figures out the reported issue doesn't meet their criteria — you'll be emailed and given a chance to respond before the issue gets closed.

During this timeframe the team may discuss potential fixes with you, or hand you patches for testing purposes. 👑

✨ The CVE is drafted ✨

Once an issue is fully confirmed and a potential fix has been found, the security team will communicate with the CPAN Security Group CNA (https://security.metacpan.org/).

Details like the range of vulnerable Perl versions, and the identities of the people who discovered the flaw, all need to be collected. 🎀

The security team may ask you to clarify the exact name they should use when crediting the discovery of the issue. The "Vulnerability credit and bounties" section of this document explains the preferred format for that credit.

✨ Pre-release notifications ✨

When the security team is satisfied that the fix for a security issue is ready to release publicly, a pre-release notification announcement goes out to the Openwall Distros List (https://oss-security.openwall.org/wiki/mailing-lists/distros). Additional other repackagers are notified too.

<strong>NOTE:</strong> Any embargoed information sent to the Openwall Distros List expires within <strong>2 weeks</strong> of disclosure to that location. ⏳

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

The pre-release announcement also includes a specific target date for when the issue will be announced publicly. The time between the pre-release announcement and the release date is so redistributors can prepare and test their own updates and announcements. During this period the vulnerability details and fixes are <strong>embargoed</strong> (see "Embargo Period") and should not be shared publicly. This "Embargo Period" may be extended further if problems show up during testing. 😬

You'll be sent the portions of pre-release announcements that are relevant to the specific issue you reported. That email includes the target release date, and more updates get sent if the target release date changes.

✨ Pre-release testing ✨

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

Lots of users and redistributors prefer using official Perl releases instead of applying patches to an older release. The security team works with Perl's release managers to make that possible. 🫶

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 are committed to Perl's public git repository. Announcements go out 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 official Perl releases are ready, they get published at this time and announced on the perl5-porters (https://lists.perl.org/list/perl5-porters.html) mailing list.

Once the release process is finished, the security team sends a follow-up notification to everyone who participated in the pre-release "Embargo Period". Vulnerability reporters and Perl redistributors should <strong>not</strong> publish their own announcements or fixes until the Perl security team's release process is complete. Periodt. 💅

---

👑 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 isn't always how it goes down — sometimes information leaks out before a fix is ready. 🙈

In these situations the team has to decide whether operating in secret increases or decreases the risk to users of Perl. Sometimes being open about the risk a security issue creates lets users defend against it; other times, calling attention to an unresolved security issue makes it more likely to be misused.

✨ 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 rapidly as possible, with any mitigations the team has available. 🚨

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

✨ Other leaks of security issue information ✨

Depending on how prominent the revealed information about a security issue is, and the issue's risk of becoming a zero-day attack, the security team may skip all or part of its normal remediation workflow.

If the security team learns of 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 appreciates the effort security researchers invest in making Perl safe and secure. 💖

Since so much of this work is hidden from the public, crediting researchers publicly is an important part of the vulnerability remediation process.

✨ Credits in vulnerability announcements ✨

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

Credits are announced 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, we'll 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're reproducible in a variety of formats. We do <strong>not</strong> include hyperlinks, domain names or marketing material with these acknowledgments. 🚫

If 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, the credit gets omitted from announcements.

✨ Bounties for Perl vulnerabilities ✨

The Perl project is a non-profit volunteer effort. We do <strong>not</strong> provide any monetary rewards for reporting security issues in Perl. 🫶 (the currency here is gratitude and a banger of a commit message)

---

🦋 Embargo Period 🦋

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

The purpose 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. This helps make sure users of Perl and its modules are protected from potential attacks while the security issue is being addressed. 💜

Embargo lengths can vary depending on the complexity of the issue and the time required to develop a fix. The security team will communicate the expected duration of the embargo to the reporter and any other parties involved in the process.

As a goal, the security team aims to keep the total embargo period to <strong>less than 60 days</strong>. This may be extended due to the following 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. 💀

The Perl security team is not playing around — they try to squash vulnerabilities fast, and they're asking every single party involved to please, pretty please, respect the embargo period, because that's what keeps users and downstream distributions safe. It's giving teamwork, bestie. 🫶

---

✨ Example Release Process ✨

Okay so here's a whole little storytime: this is an example of how an issue reported by a third party might get handled by the Perl security team, all the way from the first "hey I found something" email to the final release. Think of it as the group chat transcript of a security fix. 💖

🎀 Step 1: Reporting the Vulnerability

A security researcher finds a vulnerability in the Perl interpreter that lets an attacker cause a denial of service under specific conditions. Iconic of them to notice, honestly. They email all the deets — including a proof-of-concept script and a description of the impact — to perl-security@perl.org. 💌

🌸 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 told the expected timeline for triage, so nobody's left on read. Communication slay. ✨

🦋 Step 3: Initial Triage

The team reproduces the issue using the proof-of-concept that was provided, and determines whether it actually meets the criteria for being handled as a security issue. If it does, one or more CVEs are 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 those CVE IDs. Receipts, but official. 🧚

💅 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 fixes the issue without introducing regressions — because a fix that breaks stuff is not the vibe. The researcher is invited to test the patch privately and give feedback. Collab era. 👑

🌈 Step 5: Pre-Release Notification

The team prepares a pre-release notification with the details of the vulnerability, the affected Perl versions, and the patch. That notification goes out to major redistributors of Perl — under embargo — so they get time to prepare their own updates. Secret little heads-up. 🤫

⭐ Step 6: Pre-Release Testing

For the rest of the embargo period, the pre-notified redistributors build packages for release and test the patch to make sure it plays nice with their systems. Vibes check, but for software. 🍓

🔥 Step 7: Public Release

On the scheduled release date, the patch is committed to Perl's public git repository. An official announcement goes out 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. And if it applies, a new Perl release containing the fix gets published. 🎉

The security team will also notify the CPAN Security Group CNA so they can publish the CVE. 💖

💜 Step 8: Vendor and Third-Party Updates

Vendors and third-party maintainers fold the patch — or the updated Perl release — into their distributions. The security team follows up with everyone involved to make sure the issue is actually resolved and users are protected. Closing the loop, periodt. 🫶

---

No cap: that embargo period in Step 5 and Step 6? Respect it. It exists so users and downstream distributions don't get caught out before a fix is ready. 💀➡️💖

---

And that's the whole page, bestie — this was PERLSECPOLICY(1), brought to you by perl v5.42.3, dated 2026-08-03. Go forth and report responsibly. 💅✨