Table of Contents

Security Issues

This document explains how Symfony security issues are handled by theSymfony core team (Symfony being the code hosted on the mainsymfony/symfonyGit repository).

Reporting a Security Issue

If you think that you have found a security issue in Symfony, don't use thebug tracker and don't publish it publicly. Instead, all security issues mustbe sent tosecurity [at] symfony.com. Emails sent to this address areforwarded to the Symfony core team private mailing-list.

The following issues are not considered security issues and should be handledas regular bug fixes (if you have any doubts, don't hesitate to send us anemail for confirmation):

Any security issues found in debug tools that must never be enabled inproduction (including the web profiler or anything enabled whenAPP_DEBUGis set totrue orAPP_ENV set to anything butprod);
Any security issues found in classes provided to help for testing that shouldnever be used in production (like for instance mock classes that containMock in their name or classes in theTest namespace);
Any fix that can be classified assecurity hardening like routeenumeration, login throttling bypasses, denial of service attacks, timingattacks, or lack ofSensitiveParameter attributes.

In any case, the core team has the final decision on which issues areconsidered security vulnerabilities.

Security Bug Bounties

Symfony is an Open-Source project where most of the work is done by volunteers.We appreciate that developers are trying to find security issues in Symfony andreport them responsibly, but we are currently unable to pay bug bounties.

Resolving Process

For each report, we first try to confirm the vulnerability. When it isconfirmed, the core team works on a solution following these steps:

Send an acknowledgment to the reporter;
Work on a patch;
Get a CVE identifier frommitre.org;
Write a security announcement for the official Symfonyblog about thevulnerability. This post should contain the following information:
- a title that always include the "Security release" string;
- a description of the vulnerability;
- the affected versions;
- the possible exploits;
- how to patch/upgrade/workaround affected applications;
- the CVE identifier;
- credits.
Send the patch and the announcement to the reporter for review;
Apply the patch to all maintained versions of Symfony;
Package new versions for all affected versions;
Publish the post on the official Symfonyblog (it must also be added tothe "`Security Advisories`_" category);
Update the publicsecurity advisories database maintained by theFriendsOfPHP organization and which is used bythe check:security command.

Note

Releases that include security issues should not be done on Saturday orSunday, except if the vulnerability has been publicly posted.

Note

While we are working on a patch, please do not reveal the issue publicly.

Note

The resolution takes anywhere between a couple of days to a month dependingon its complexity and the coordination with the downstream projects (seenext paragraph).

Collaborating with Downstream Open-Source Projects

As Symfony is used by many large Open-Source projects, we standardized the waythe Symfony security team collaborates on security issues with downstreamprojects. The process works as follows:

After the Symfony security team has acknowledged a security issue, itimmediately sends an email to the downstream project security teams toinform them of the issue;
The Symfony security team creates a private Git repository to ease thecollaboration on the issue and access to this repository is given to theSymfony security team, to the Symfony contributors that are impacted bythe issue, and to one representative of each downstream projects;
All people with access to the private repository work on a solution tosolve the issue via pull requests, code reviews, and comments;
Once the fix is found, all involved projects collaborate to find the bestdate for a joint release (there is no guarantee that all releases willbe at the same time but we will try hard to make them at about the sametime). When the issue is not known to be exploited in the wild, a periodof two weeks is considered a reasonable amount of time.

The list of downstream projects participating in this process is kept as smallas possible in order to better manage the flow of confidential informationprior to disclosure. As such, projects are included at the sole discretion ofthe Symfony security team.

As of today, the following projects have validated this process and are partof the downstream projects included in this process:

Drupal (releases typically happen on Wednesdays)
eZPublish

Issue Severity

In order to determine the severity of a security issue we take into accountthe complexity of any potential attack, the impact of the vulnerability andalso how many projects it is likely to affect. This score out of 15 is thenconverted into a level of: Low, Medium, High, Critical, or Exceptional.

Attack Complexity

Score of between 1 and 5 depending on how complex it is to exploit thevulnerability

4 - 5 Basic: attacker must follow a set of simple steps
2 - 3 Complex: attacker must follow non-intuitive steps with a high levelof dependencies
1 - 2 High: A successful attack depends on conditions beyond the attacker'scontrol. That is, a successful attack cannot be accomplished at will, butrequires the attacker to invest in some measurable amount of effort inpreparation or execution against the vulnerable component before a successfulattack can be expected.

Impact

Scores from the following areas are added together to produce a score. Thescore for Impact is capped at 6. Each area is scored between 0 and 4.

Integrity: Does this vulnerability cause non-public data to be accessible?If so, does the attacker have control over the data disclosed? (0-4)
Disclosure: Can this exploit allow system data (or data handled by thesystem) to be compromised? If so, does the attacker have control overmodification? (0-4)
Code Execution: Does the vulnerability allow arbitrary code to be executedon an end-users system, or the server that it runs on? (0-4)
Availability: Is the availability of a service or application affected? Isit reduced availability or total loss of availability of a service /application? Availability includes networked services (e.g. databases) orresources such as consumption of network bandwidth, processor cycles, ordisk space. (0-4)

Affected Projects

Scores from the following areas are added together to produce a score. Thescore for Affected Projects is capped at 4.

Will it affect some or all using a component? (1-2)
Is the usage of the component that would cause such a thing alreadyconsidered bad practice? (0-1)
How common/popular is the component (e.g. Console vs HttpFoundation vsLock)? (0-2)
Are a number of well-known open source projects using Symfony affectedthat requires coordinated releases? (0-1)