It was found that the server or host controller did not properly authorize a user performing a shut down. A user with the role Monitor, Deployer, or Auditor could use this flaw to shut down the EAP server, which is an action restricted to users in other roles.
The following commit introduced this issue:
The context.getServiceRegistry(true) call, which throws an exception when write authorization fails, was replaced with a call to context.authorize, which only returns an authorization result. Nothing was then done with the authorization result.
The same flaw exists in the handling of the cancel-active-operation op, although there this only means the admin could cancel an in-progress operation, perhaps initiated by a different admin. It also lets the admin cancel his own operation, which is arguably a benefit. But losing that benefit is an acceptable price to having a consistent RBAC scheme. (Note: CLI users whose own operations are hanging can always cancel them by doing a soft kill of the CLI process. Users of custom clients that use ModelControllerClient can cancel their own ops by using the ModelControllerClient executeAsync API and cancelling the Future returned thereby.)