{ "content": [ { "type": "text", "text": "# PERLSECPOLICY (man)\n\n## NAME\n\nperlsecpolicy - Perl security report handling policy\n\n## DESCRIPTION\n\nThe Perl project takes security issues seriously.\n\n## Sections\n\n- **NAME**\n- **DESCRIPTION**\n- **REPORTING SECURITY ISSUES IN PERL**\n- **WHAT ARE SECURITY ISSUES** (4 subsections)\n- **HOW WE DEAL WITH SECURITY ISSUES** (3 subsections)\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "PERLSECPOLICY", "section": "", "mode": "man", "summary": "perlsecpolicy - Perl security report handling policy", "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 8, "subsections": [] }, { "name": "REPORTING SECURITY ISSUES IN PERL", "lines": 28, "subsections": [] }, { "name": "WHAT ARE SECURITY ISSUES", "lines": 11, "subsections": [ { "name": "Software covered by the Perl security team", "lines": 15 }, { "name": "Bugs that may qualify as security issues in Perl", "lines": 19 }, { "name": "Bugs that do not qualify as security issues in Perl", "lines": 78 }, { "name": "Bugs that require special categorization", "lines": 43 } ] }, { "name": "HOW WE DEAL WITH SECURITY ISSUES", "lines": 15, "subsections": [ { "name": "Perl's vulnerability remediation workflow", "lines": 110 }, { "name": "Publicly known and zero-day security issues", "lines": 28 }, { "name": "Vulnerability credit and bounties", "lines": 31 } ] } ], "sections": { "NAME": { "content": "perlsecpolicy - Perl security report handling policy\n", "subsections": [] }, "DESCRIPTION": { "content": "The Perl project takes security issues seriously.\n\nThe responsibility for handling security reports in a timely and effective manner has been\ndelegated to a security team composed of a subset of the Perl core developers.\n\nThis document describes how the Perl security team operates and how the team evaluates new\nsecurity reports.\n", "subsections": [] }, "REPORTING SECURITY ISSUES IN PERL": { "content": "If you believe you have found a security vulnerability in the Perl interpreter or modules\nmaintained in the core Perl codebase, email the details to perl-security@perl.org\n. This address is a closed membership mailing list monitored\nby the Perl security team.\n\nYou should receive an initial response to your report within 72 hours. If you do not receive\na response in that time, please contact the Perl Steering Council .\n\nWhen members of the security team reply to your messages, they will generally include the\nperl-security@perl.org address in the \"To\" or \"CC\" fields of the response. This allows all of\nthe security team to follow the discussion and chime in as needed. Use the \"Reply-all\"\nfunctionality of your email client when you send subsequent responses so that the entire\nsecurity team receives the message.\n\nThe security team will evaluate your report and make an initial determination of whether it\nis likely to fit the scope of issues the team handles. General guidelines about how this is\ndetermined are detailed in the \"WHAT ARE SECURITY ISSUES\" section.\n\nIf your report meets the team's criteria, an issue will be opened in the team's private issue\ntracker and you will be provided the issue's ID number. Issue identifiers have the form\nperl-security#NNN. Include this identifier with any subsequent messages you send.\n\nThe security team will send periodic updates about the status of your issue and guide you\nthrough any further action that is required to complete the vulnerability remediation\nprocess. The stages vulnerabilities typically go through are explained in the \"HOW WE DEAL\nWITH SECURITY ISSUES\" section.\n", "subsections": [] }, "WHAT ARE SECURITY ISSUES": { "content": "A vulnerability is a behavior of a software system that compromises the system's expected\nconfidentiality, integrity or availability protections.\n\nA security issue is a bug in one or more specific components of a software system that\ncreates a vulnerability.\n\nSoftware written in the Perl programming language is typically composed of many layers of\nsoftware written by many different groups. It can be very complicated to determine which\nspecific layer of a complex real-world application was responsible for preventing a\nvulnerable behavior, but this is an essential part of fixing the vulnerability.\n", "subsections": [ { "name": "Software covered by the Perl security team", "content": "The Perl security team handles security issues in:\n\n• The Perl interpreter\n\n• The Perl modules shipped with the interpreter that are developed in the core Perl\nrepository\n\n• The command line tools shipped with the interpreter that are developed in the core Perl\nrepository\n\nFiles under the cpan/ directory in Perl's repository and release tarballs are developed and\nmaintained independently. The Perl security team does not directly handle security issues for\nthese modules, but since this code is bundled with Perl, we will assist in forwarding the\nissue to the relevant maintainer(s) and you can still report these issues to us in secrecy.\n" }, { "name": "Bugs that may qualify as security issues in Perl", "content": "Perl is designed to be a fast and flexible general purpose programming language. The Perl\ninterpreter and Perl modules make writing safe and secure applications easy, but they do have\nlimitations.\n\nAs a general rule, a bug in Perl needs to meet all of the following criteria to be considered\na security issue:\n\n• The vulnerable behavior is not mentioned in Perl's documentation or public issue tracker.\n\n• The vulnerable behavior is not implied by an expected behavior.\n\n• The vulnerable behavior is not a generally accepted limitation of the implementation.\n\n• The vulnerable behavior is likely to be exposed to attack in otherwise secure\napplications written in Perl.\n\n• The vulnerable behavior provides a specific tangible benefit to an attacker that triggers\nthe behavior.\n" }, { "name": "Bugs that do not qualify as security issues in Perl", "content": "There are certain categories of bugs that are frequently reported to the security team that\ndo not meet the criteria listed above.\n\nThe following is a list of commonly reported bugs that are not handled as security issues.\n\nFeeding untrusted code to the interpreter\n\nThe Perl parser is not designed to evaluate untrusted code. If your application requires the\nevaluation of untrusted code, it should rely on an operating system level sandbox for its\nsecurity.\n\nStack overflows due to excessive recursion\n\nExcessive recursion is often caused by code that does not enforce limits on inputs. The Perl\ninterpreter assumes limits on recursion will be enforced by the application.\n\nOut of memory errors\n\nCommon Perl constructs such as \"pack\", the \"x\" operator, and regular expressions accept\nnumeric quantifiers that control how much memory will be allocated to store intermediate\nvalues or results. If you allow an attacker to supply these quantifiers and consume all\navailable memory, the Perl interpreter will not prevent it.\n\nEscape from a Safe compartment\n\nOpcode restrictions and Safe compartments are not supported as security mechanisms. The Perl\nparser is not designed to evaluate untrusted code.\n\nUse of the \"p\" and \"P\" pack templates\n\nThese templates are unsafe by design.\n\nStack not reference-counted issues\n\nThese bugs typically present as use-after-free errors or as assertion failures on the type of\na \"SV\". Stack not reference-counted crashes usually occur because code is both modifying a\nreference or glob and using the values referenced by that glob or reference.\n\nThis type of bug is a long standing issue with the Perl interpreter that seldom occurs in\nnormal code. Examples of this type of bug generally assume that attacker-supplied code will\nbe evaluated by the Perl interpreter.\n\nThawing attacker-supplied data with Storable\n\nStorable is designed to be a very fast serialization format. It is not designed to be safe\nfor deserializing untrusted inputs.\n\nUsing attacker supplied SDBMFile databases\n\nThe SDBMFile module is not intended for use with untrusted SDBM databases.\n\nBadly encoded UTF-8 flagged scalars\n\nThis type of bug occurs when the \":utf8\" PerlIO layer is used to read badly encoded data, or\nother mechanisms are used to directly manipulate the UTF-8 flag on an SV.\n\nA badly encoded UTF-8 flagged SV is not a valid SV. Code that creates SV's in this fashion is\ncorrupting Perl's internal state.\n\nIssues that exist only in blead, or in a release candidate\n\nThe blead branch and Perl release candidates do not receive security support. Security\ndefects that are present only in pre-release versions of Perl are handled through the normal\nbug reporting and resolution process.\n\nCPAN modules or other Perl project resources\n\nThe Perl security team is focused on the Perl interpreter and modules maintained in the core\nPerl codebase. The team has no special access to fix CPAN modules, applications written in\nPerl, Perl project websites, Perl mailing lists or the Perl IRC servers.\n\nEmulated POSIX behaviors on Windows systems\n\nThe Perl interpreter attempts to emulate \"fork\", \"system\", \"exec\" and other POSIX behaviors\non Windows systems. This emulation has many quirks that are extensively documented in Perl's\npublic issue tracker. Changing these behaviors would cause significant disruption for\nexisting users on Windows.\n" }, { "name": "Bugs that require special categorization", "content": "Some bugs in the Perl interpreter occur in areas of the codebase that are both security\nsensitive and prone to failure during normal usage.\n\nRegular expressions\n\nUntrusted regular expressions are generally safe to compile and match against with several\ncaveats. The following behaviors of Perl's regular expression engine are the developer's\nresponsibility to constrain.\n\nThe evaluation of untrusted regular expressions while \"use re 'eval';\" is in effect is never\nsafe.\n\nRegular expressions are not guaranteed to compile or evaluate in any specific finite time\nframe.\n\nRegular expressions may consume all available system memory when they are compiled or\nevaluated.\n\nRegular expressions may cause excessive recursion that halts the perl interpreter.\n\nAs a general rule, do not expect Perl's regular expression engine to be resistant to denial\nof service attacks.\n\nDBFile, ODBMFile, or GDBMFile databases\n\nThese modules rely on external libraries to interact with database files.\n\nBugs caused by reading and writing these file formats are generally caused by the underlying\nlibrary implementation and are not security issues in Perl.\n\nBugs where Perl mishandles unexpected valid return values from the underlying libraries may\nqualify as security issues in Perl.\n\nAlgorithmic complexity attacks\n\nThe perl interpreter is reasonably robust to algorithmic complexity attacks. It is not immune\nto them.\n\nAlgorithmic complexity bugs that depend on the interpreter processing extremely large amounts\nof attacker supplied data are not generally handled as security issues.\n\nSee \"Algorithmic Complexity Attacks\" in perlsec for additional information.\n" } ] }, "HOW WE DEAL WITH SECURITY ISSUES": { "content": "The Perl security team follows responsible disclosure practices. Security issues are kept\nsecret until a fix is readily available for most users. This minimizes inherent risks users\nface from vulnerabilities in Perl.\n\nHiding problems from the users temporarily is a necessary trade-off to keep them safe. Hiding\nproblems from users permanently is not the goal.\n\nWhen you report a security issue privately to the perl-security@perl.org contact address, we normally expect you to follow responsible disclosure\npractices in the handling of the report. If you are unable or unwilling to keep the issue\nsecret until a fix is available to users you should state this clearly in the initial report.\n\nThe security team's vulnerability remediation workflow is intended to be as open and\ntransparent as possible about the state of your security report.\n", "subsections": [ { "name": "Perl's vulnerability remediation workflow", "content": "Initial contact\n\nNew vulnerability reports will receive an initial reply within 72 hours from the time they\narrive at the security team's mailing list. If you do not receive any response in that time,\ncontact the Perl Steering Council .\n\nThe initial response sent by the security team will confirm your message was received and\nprovide an estimated time frame for the security team's triage analysis.\n\nInitial triage\n\nThe security team will evaluate the report and determine whether or not it is likely to meet\nthe criteria for handling as a security issue.\n\nThe security team aims to complete the initial report triage within two weeks' time. Complex\nissues that require significant discussion or research may take longer.\n\nIf the security report cannot be reproduced or does not meet the team's criteria for handling\nas a security issue, you will be notified by email and given an opportunity to respond.\n\nIssue ID assignment\n\nSecurity reports that pass initial triage analysis are turned into issues in the security\nteam's private issue tracker. When a report progresses to this point you will be provided the\nissue ID for future reference. These identifiers have the format perl-security#NNN or\nPerl/perl-security#NNN.\n\nThe assignment of an issue ID does not confirm that a security report represents a\nvulnerability in Perl. Many reports require further analysis to reach that determination.\n\nIssues in the security team's private tracker are used to collect details about the problem\nand track progress towards a resolution. These notes and other details are not made public\nwhen the issue is resolved. Keeping the issue notes private allows the security team to\nfreely discuss attack methods, attack tools, and other related private issues.\n\nDevelopment of patches\n\nMembers of the security team will inspect the report and related code in detail to produce\nfixes for supported versions of Perl.\n\nIf the team discovers that the reported issue does not meet the team's criteria at this\nstage, you will be notified by email and given an opportunity to respond before the issue is\nclosed.\n\nThe team may discuss potential fixes with you or provide you with patches for testing\npurposes during this time frame. No information should be shared publicly at this stage.\n\nCVE ID assignment\n\nOnce an issue is fully confirmed and a potential fix has been found, the security team will\nrequest a CVE identifier for the issue to use in public announcements.\n\nDetails like the range of vulnerable Perl versions and identities of the people that\ndiscovered the flaw need to be collected to submit the CVE ID request.\n\nThe security team may ask you to clarify the exact name we should use when crediting\ndiscovery of the issue. The \"Vulnerability credit and bounties\" section of this document\nexplains our preferred format for this credit.\n\nOnce a CVE ID has been assigned, you will be notified by email. The vulnerability should not\nbe discussed publicly at this stage.\n\nPre-release notifications\n\nWhen the security team is satisfied that the fix for a security issue is ready to release\npublicly, a pre-release notification announcement is sent to the major redistributors of\nPerl.\n\nThis pre-release announcement includes a list of Perl versions that are affected by the flaw,\nan analysis of the risks to users, patches the security team has produced, and any\ninformation about mitigations or backporting fixes to older versions of Perl that the\nsecurity team has available.\n\nThe pre-release announcement will include a specific target date when the issue will be\nannounced publicly. The time frame between the pre-release announcement and the release date\nallows redistributors to prepare and test their own updates and announcements. During this\nperiod the vulnerability details and fixes are embargoed and should not be shared publicly.\nThis embargo period may be extended further if problems are discovered during testing.\n\nYou will be sent the portions of pre-release announcements that are relevant to the specific\nissue you reported. This email will include the target release date. Additional updates will\nbe sent if the target release date changes.\n\nPre-release testing\n\nThe Perl security team does not directly produce official Perl releases. The team releases\nsecurity fixes by placing commits in Perl's public git repository and sending announcements.\n\nMany users and redistributors prefer using official Perl releases rather than applying\npatches to an older release. The security team works with Perl's release managers to make\nthis possible.\n\nNew official releases of Perl are generally produced and tested on private systems during the\npre-release embargo period.\n\nRelease of fixes and announcements\n\nAt the end of the embargo period the security fixes will be committed to Perl's public git\nrepository and announcements will be sent to the perl5-porters\n and oss-security mailing lists.\n\nIf official Perl releases are ready, they will be published at this time and announced on the\nperl5-porters mailing list.\n\nThe security team will send a follow-up notification to everyone that participated in the\npre-release embargo period once the release process is finished. Vulnerability reporters and\nPerl redistributors should not publish their own announcements or fixes until the Perl\nsecurity team's release process is complete.\n" }, { "name": "Publicly known and zero-day security issues", "content": "The security team's vulnerability remediation workflow assumes that issues are reported\nprivately and kept secret until they are resolved. This isn't always the case and information\noccasionally leaks out before a fix is ready.\n\nIn these situations the team must decide whether operating in secret increases or decreases\nthe risk to users of Perl. In some cases being open about the risk a security issue creates\nwill allow users to defend against it, in other cases calling attention to an unresolved\nsecurity issue will make it more likely to be misused.\n\nZero-day security issues\n\nIf an unresolved critical security issue in Perl is being actively abused to attack systems\nthe security team will send out announcements as rapidly as possible with any mitigations the\nteam has available.\n\nPerl's public defect tracker will be used to handle the issue so that additional information,\nfixes, and CVE IDs are visible to affected users as rapidly as possible.\n\nOther leaks of security issue information\n\nDepending on the prominence of the information revealed about a security issue and the\nissue's risk of becoming a zero-day attack, the security team may skip all or part of its\nnormal remediation workflow.\n\nIf the security team learns of a significant security issue after it has been identified and\nresolved in Perl's public issue tracker, the team will request a CVE ID and send an\nannouncement to inform users.\n" }, { "name": "Vulnerability credit and bounties", "content": "The Perl project appreciates the effort security researchers invest in making Perl safe and\nsecure.\n\nSince much of this work is hidden from the public, crediting researchers publicly is an\nimportant part of the vulnerability remediation process.\n\nCredits in vulnerability announcements\n\nWhen security issues are fixed we will attempt to credit the specific researcher(s) that\ndiscovered the flaw in our announcements.\n\nCredits are announced using the researcher's preferred full name.\n\nIf the researcher's contributions were funded by a specific company or part of an organized\nvulnerability research project, we will include a short name for this group at the\nresearcher's request.\n\nPerl's announcements are written in the English language using the 7bit ASCII character set\nto be reproducible in a variety of formats. We do not include hyperlinks, domain names or\nmarketing material with these acknowledgments.\n\nIn the event that proper credit for vulnerability discovery cannot be established or there is\na disagreement between the Perl security team and the researcher about how the credit should\nbe given, it will be omitted from announcements.\n\nBounties for Perl vulnerabilities\n\nThe Perl project is a non-profit volunteer effort. We do not provide any monetary rewards for\nreporting security issues in Perl.\n\nperl v5.38.2 2026-06-12 PERLSECPOLICY(1)" } ] } } } }