I share Kris's opinion. We have already dragged this release a lot and then postponing it to August would mean that a truck load of new PRs would be opened against master, which in turn would need to:
a) be integrated in the 2.1 release and possibly hurt the stability of the codebase which could push the tentative date even further
b) be left alone until we release 2.1
A branch could be created RELEASE_2_1 which is feature-frozen and only for bug fixes and component stabilization towards the release. PR's for new features etc would continue to be contributed to master. When RELEASE_2_1 is ready, it gets tagged, release, and the work gets merged back down into master. Conflict resolutions, compatibility issues etc need to be resolved, but this is true of any scenario.
Bugs affecting (necessary for) the release should be part of the RELEASE_2_1 branch, but if they are sent as PRs to master, there's no reason that it couldn't be cherry-picked for RELEASE_2_1, which makes sense since it's a bug that affects the release.
Further along in the development cycle, when it's feature-freeze time (or other appropriate time) a RELEASE_2_2 branch would be created from master, then lather, rinse, repeat.
If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com