As a maintainer, I want the merge target to come from the list the user was actually offered, so that a merge cannot be aimed somewhere the UI deliberately excluded.
Part of #4852 (Sandbox DevX epic).
What's wrong
The sandbox management screen builds its merge target options by filtering the workspace: it leaves out the sandbox itself, its descendants, and any project scheduled for deletion. Then, when the merge is confirmed, it resolves the chosen target by searching every project in the workspace rather than that filtered list.
So the filtering only holds as long as the client sends back one of the values it was given. A crafted confirm event can name a project the list deliberately left out, including the sandbox itself and a project already scheduled for deletion.
How bad
Not an escalation. The merge is still authorised against the target, so this needs editor or above on whatever project is named, and it cannot reach a project the user has no rights on. It predates the current sandbox work.
It matters more than it did, though, because a merge now also writes to the source project. #5139 records a version row on each source workflow a merge carried, so a merge aimed somewhere unintended writes there too.
What to fix
Resolve the target from the same filtered options the screen offered, and refuse anything else.
Acceptance criteria
As a maintainer, I want the merge target to come from the list the user was actually offered, so that a merge cannot be aimed somewhere the UI deliberately excluded.
Part of #4852 (Sandbox DevX epic).
What's wrong
The sandbox management screen builds its merge target options by filtering the workspace: it leaves out the sandbox itself, its descendants, and any project scheduled for deletion. Then, when the merge is confirmed, it resolves the chosen target by searching every project in the workspace rather than that filtered list.
So the filtering only holds as long as the client sends back one of the values it was given. A crafted confirm event can name a project the list deliberately left out, including the sandbox itself and a project already scheduled for deletion.
How bad
Not an escalation. The merge is still authorised against the target, so this needs editor or above on whatever project is named, and it cannot reach a project the user has no rights on. It predates the current sandbox work.
It matters more than it did, though, because a merge now also writes to the source project. #5139 records a version row on each source workflow a merge carried, so a merge aimed somewhere unintended writes there too.
What to fix
Resolve the target from the same filtered options the screen offered, and refuse anything else.
Acceptance criteria