Package Instance

SQL Injection
In Symfony HTTP Methods provided as verbs or using the override header may be treated as trusted input, but they are not validated, possibly causing SQL injection or XSS.

Cross-site Scripting
In Symfony, validation messages are not escaped, which can lead to XSS when user input is included.

Cross-site Scripting
The debug handler in Symfony has an XSS via an array key during exception pretty printing in `ExceptionHandler.php`, as demonstrated by a `/_debugbar/open?op`=get` URI.

Cross-Site Request Forgery (CSRF)
By default, a user's session is invalidated when the user is logged out. This behavior can be disabled through the `invalidate_session` option. In this case, CSRF tokens were not erased during logout which allowed for CSRF token fixation.

URL Redirection to Untrusted Site (Open Redirect)
The security handlers in the Security component in Symfony have an Open redirect vulnerability when `security.http_utils` is inlined by a container.

Unrestricted Upload of File with Dangerous Type
When using the scalar type hint `string` in a setter method (e.g. `setName(string$name)`) of a class that's the `data_class` of a form, and when a file upload is submitted to the corresponding field instead of a normal text input, then `UploadedFile::__toString()` is called which will then return and disclose the path of the uploaded file. If combined with a local file inclusion issue in certain circumstances this could escalate it to a Remote Code Execution.

Attacker can read all files content on the server
When a form is submitted by the user, the request handler classes of the Form component merge POST data (known as the `$_POST` array in plain PHP) and uploaded files data (known as the `$_FILES` array in plain PHP) into one array. This big array forms the data that are then bound to the form. At this stage there is no difference anymore between submitted POST data and uploaded files. A user can send a crafted HTTP request where the value of a `FileType` is sent as normal `POST` data that could be interpreted as a locale file path on the server-side (for example, `file:///etc/passwd`). If the application did not perform any additional checks about the value submitted to the `FileType`, the contents of the given file on the server could have been exposed to the attacker.