patch rolebindings

Patching the subjects array hits the same escalation prevention as create.

The caller must already hold all referenced permissions, or have bind on the referenced Role or ClusterRole.

roleRef is immutable, so an existing binding cannot be repointed at a more privileged Role.

That requires deleting and recreating it.

Not an independent bypass.

T1 with following verbs:

Membership of an existing high-privilege binding without creating anything

Adding a subject to a RoleBinding is subject to the same escalation prevention as creating one.

bind on the referenced role waives it.

Patching an existing binding is also quieter than creating a new one.

Escalation Paths

Patch the subjects array of an existing RoleBinding to add the attacker.
The roleRef field is immutable, so the Role or ClusterRole it points at cannot be swapped for a more privileged one
Kubernetes applies the same escalation check as create, requiring bind on the referenced Role or ClusterRole, or already holding all of its permissions
Yields whatever that binding already grants, scoped to its namespace.
This is not an independent bypass of the escalation check

Additional rights needed:

none