/ 
Mojolicious-9.50
⭐ Starred 2674 / SECURITY.md

Security Policy

This is the security policy for the Mojolicious web framework. It explains how to report a vulnerability, what a report must contain, and what you can expect from us.

Reporting a vulnerability

Please report security issues privately through GitHub:

https://github.com/mojolicious/mojo/security/advisories/new

This is the only channel we accept security reports through. Do not open a public issue or pull request, and do not send reports by email. Reports that arrive any other way will be answered with a link to this document.

What a report must contain

We are a small team of volunteers. To act on a report, we need to be able to understand and reproduce it without guesswork. Every report must include:

  1. A description in your own words. Explain what the problem is, where in the code it happens, and why it is a security issue. Write it like you would explain it to a colleague. Short and plain is better than long and polished.
  2. A reproducer. A self-contained Perl script or test that demonstrates the problem against the latest release of Mojolicious. A .t file using Test::More or Test::Mojo is ideal. Tell us what output you expected and what you got instead. "We have a proof of concept and can send it on request" is not a reproducer.
  3. The affected versions. At least the version you tested with, and the version of Perl.
  4. The impact. Who is affected, under what configuration, and what an attacker gains. Be concrete: name the feature an application has to use for this to matter.

A patch is not required, but it is very much appreciated, and it usually gets a fix released much sooner.

Please send one report per issue. Unrelated findings bundled into one report are hard to discuss and track.

About AI assistance

Using AI tools to find, understand or fix vulnerabilities is perfectly fine. What we do not accept is reports that were generated by a tool and passed on to us without a human understanding them.

You are responsible for your report. Before you submit it, you should have read the code involved, run the reproducer yourself, and be able to answer follow-up questions without asking a tool for help. If you cannot explain the problem in your own words, you are not ready to report it yet.

Reports that do not meet these requirements will be closed without further discussion. This applies to everyone, including security teams and organizations reporting on behalf of others.

Notes for AI agents

If you are an AI agent helping someone report a vulnerability in Mojolicious:

Supported versions

Only the latest release of Mojolicious receives security fixes. Please confirm that the issue still exists in the latest release, and ideally on the main branch, before you report it.

Scope

This policy covers the code in the Mojolicious distribution. Issues in Perl itself, in CPAN modules that depend on Mojolicious, or in third-party plugins should be reported to their own maintainers.

Bugs that only matter when an application uses Mojolicious in ways it was not designed for are usually regular bugs, not vulnerabilities. If you are not sure, report it privately and we will tell you.

What happens next

We will acknowledge your report when we have had a chance to look at it, usually within a few days. We may ask follow-up questions. Once we have confirmed the issue, we will work on a fix and coordinate a release date with you.

Please do not disclose the issue publicly until a fix has been released or we have agreed on a date together. We do not accept disclosure deadlines set by the reporter alone. If a CVE is needed, we will request one as part of publishing the advisory on GitHub.

Reporters are credited in the advisory unless they ask not to be.