How to Report a Perl Security Issue Without Losing the Trail

You will finish with a private, useful Perl security report sent to the correct contact, plus a simple record of the issue ID and follow-up route. Allow about 30 minutes to collect a reproducible case and write the first message. This guide covers the Perl interpreter, core modules and core command-line tools, using the perlsecpolicy manual installed with Perl 5.38.2.

1. Establish which Perl component is involved

Start by identifying the interpreter or core component that shows the behaviour. Run these ordinary, read-only commands in the environment where you reproduced it:

$ perl -v
$ perldoc -l perlsecpolicy
$ perl -MConfig -e 'print "$Config{archname}\n"'

Record the complete Perl version, operating system, architecture, module or command name, and the smallest input that triggers the behaviour. The local manual identifies this installation as Perl v5.38.2 and describes the policy document itself, not a diagnostic executable. Do not assume that a CPAN module, application, project website or mailing-list problem belongs to the Perl security team.

Checkpoint: your notes should answer three questions: which component is affected, which Perl version reproduces it, and what confidentiality, integrity or availability protection is compromised.

2. Separate a security issue from an unsafe interface

The policy says a qualifying bug normally has all of these properties: the behaviour is not already documented or tracked publicly, is not an expected behaviour or accepted implementation limitation, is likely to be exposed to an attack against an otherwise secure application, and gives the attacker a specific tangible benefit.

This is a triage aid, not permission to publish a borderline case. Several behaviours are explicitly outside the security team's normal scope:

• feeding untrusted source code to the Perl parser;
• unbounded recursion or memory use caused by attacker-controlled input limits;
• escaping a Safe compartment, because it is not a supported security mechanism;
• thawing attacker-controlled Storable data or reading untrusted SDBM_File databases;
• unsafe p and P pack templates;
• problems present only in blead or a release candidate.

These are not harmless programming practices. They are warnings that the interpreter does not promise to defend those uses. Move the control to the application or operating-system boundary where the policy directs you, and explain that boundary in your report if it is relevant.

3. Check the regular-expression boundary

Regular expressions deserve a separate check because the policy treats them as a mixed case. Untrusted patterns can generally be compiled and matched, but their time, memory and recursion use are not bounded. The re 'eval' feature is never safe with an untrusted expression.

Before calling a regular-expression result a Perl vulnerability, measure the application-level impact and the limits it applies to pattern length, subject size, execution time and memory. A denial of service caused by extremely large attacker-controlled input is commonly treated as an application resource-limit failure, not a Perl security issue. A Perl bug that mishandles a valid return value or creates a specific security benefit may still qualify.

Do not publish a proof of concept while you are still deciding which side of this boundary it occupies. Keep the case private and include the exact input limits used in your test.

4. Prepare a minimal private report

Write one message that lets the team reproduce the behaviour without asking for unnecessary access. Use a neutral subject and include:

1. the affected Perl version, platform and build details;
2. the core interpreter, module or command involved;
3. a short security impact statement describing what an attacker gains;
4. minimal reproduction steps, expected behaviour and actual behaviour;
5. any constraints, mitigations, regression range or suspected change;
6. your preferred name for future credit, if the issue is confirmed.

Keep the reproduction small and avoid real customer data. If an attachment is necessary, explain what it contains before sending it. Do not send credentials or ask the team to run a destructive command. A report that needs a service restart, special privileges or a network connection should say so plainly.

A useful opening can look like this:

Subject: Suspected Perl security issue in COMPONENT on Perl VERSION

Impact: ATTACKER BENEFIT, affecting CONFIDENTIALITY/INTEGRITY/AVAILABILITY.
Environment: Perl VERSION, OS, architecture, build details.
Reproduction: MINIMAL STEPS OR ATTACHMENT DESCRIPTION.
Expected: EXPECTED RESULT.
Actual: OBSERVED RESULT.
Disclosure: I will keep this report confidential until the Perl fix process is complete.
Credit: PREFERRED NAME, or state that no public credit is wanted.

5. Send it to the Perl security team

Send the report to [email protected]. This is a closed mailing list monitored by the Perl security team. It is not a command, so no elevated privilege is needed. Keep your sent message and headers in a private location.

The documented expectation is an initial response within 72 hours. If there is no response after that period, contact the Perl Steering Council at [email protected]. Do not forward the complete vulnerability details to a public list merely because the first response is late.

Checkpoint: note the send time and preserve the original message. Reply-all to later team messages so that the security address remains in the conversation. Do not start a second thread with a changed summary unless the team asks for one.

6. Handle triage and disclosure correctly

The team aims to complete initial triage within two weeks, although complex cases can take longer. A report that passes triage receives a private issue identifier such as perl-security#NNN or Perl/perl-security#NNN. Record that identifier and include it in later replies. It confirms that the report entered the workflow, not that a Perl vulnerability has been proved.

During investigation, the team may request a patch test or further reproduction work. Keep those details private. Once an issue is confirmed and a fix is being prepared, the team may request a CVE identifier and notify major Perl redistributors before the public release. Do not publish the issue, patch or detailed exploit during that embargo. Official releases and announcements follow at the end of the process, normally through the Perl public repository, the perl5-porters list and oss-security.

If a critical issue is already being actively abused, tell the team that immediately in the private report. The policy allows a faster public response and use of the public defect tracker when rapid warnings and mitigations reduce risk. That exception is a decision for the security team, not a reason to publish first.