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

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

After the Symfony security team has acknowledged a security issue, it
immediately sends an email to the downstream project security teams to
inform them of the issue;

The Symfony security team creates a private Git repository to ease the
collaboration on the issue and access to this repository is given to the
Symfony security team, to the Symfony contributors that are impacted by
the issue, and to one representative of each downstream projects;

All people with access to the private repository work on a solution to
solve the issue via pull requests, code reviews, and comments;

Once the fix is found, all involved projects collaborate to find the best
date for a joint release (there is no guarantee that all releases will
be at the same time but we will try hard to make them at about the same
time). When the issue is not known to be exploited in the wild, a period
of two weeks is considered a reasonable amount of time.

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

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

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

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

4 - 5 Basic: attacker must follow a set of simple steps

2 - 3 Complex: attacker must follow non-intuitive steps with a high level
of dependencies

1 - 2 High: A successful attack depends on conditions beyond the attacker's
control. That is, a successful attack cannot be accomplished at will, but
requires the attacker to invest in some measurable amount of effort in
preparation or execution against the vulnerable component before a successful
attack can be expected.

Scores from the following areas are added together to produce a score. The
score 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 the
system) to be compromised? If so, does the attacker have control over
modification? (0-4)

Code Execution: Does the vulnerability allow arbitrary code to be executed
on an end-users system, or the server that it runs on? (0-4)

Availability: Is the availability of a service or application affected? Is
it reduced availability or total loss of availability of a service /
application? Availability includes networked services (e.g., databases) or
resources such as consumption of network bandwidth, processor cycles, or
disk space. (0-4)