Privileged administrative operations did not declare required roles

Workarounds

• Until the fix is applied, treat every staff account as equivalent to a full administrator and issue accounts on that basis.
• Assign an explicit role when creating accounts. Note that this is record keeping rather than a control, because the affected operations did not check the role.
• Review the audit log. Every affected operation records the acting person, so misuse is detectable after the fact even where it was not preventable.

Solutions

• Update to a build in which every privileged administrative operation declares the roles permitted to perform it.
• The same update makes the publishing authorisation path consult role information, so a role requirement declared there is enforced.
• Operations that only read remain open to any role, which is the intended behaviour.

Exploits

• Authenticate with a staff account holding the lowest-privilege role and invoke an affected administrative operation directly. No role requirement is present to be checked.

Configurations

• Exploitation requires an authenticated staff account of any role, including the lowest-privilege role assigned by default when an account is created without one specified.
• All deployments are affected. There is no setting that enables role enforcement, as the requirement was declared per operation.
• Operations that reach a customer's own installation remain subject to that customer's independent approval, which is unaffected by this issue and continues to apply.
• Operations that change licensing, product catalogue content or published software had no such independent second party, so the missing role requirement was the only control.

Impacts

• Privilege escalation within the administrative surface. An account holding the lowest-privilege role could change customer licensing, publish signed software that deployed installations fetch and trust, alter product catalogue content, and create or modify hosted deployments.

  CAPEC-122

• Access to customer-facing support operations, including requesting command execution on a customer installation. The customer's own approval requirements continue to apply, so this is access to the request rather than unconditional execution.

  CAPEC-233

• A latent enforcement gap in the publishing authorisation path, which did not consult role information, so a role requirement added there would not have taken effect.

  CAPEC-1

Timeline

1. 09/14/2026 00:00

   Identified during an internal security review of GPlatform Control.

2. 09/14/2026 00:30

   Confirmed by analysis. No exploitation was performed against any running deployment, and there is no indication of exploitation in the wild.

3. 09/14/2026 01:00

   Reported to the vendor. Vendor and reporter are the same party, so no external coordination applies.

4. 09/14/2026 02:00

   Remediation began.

5. 09/14/2026 04:40

   Fixed in the product. Every privileged administrative operation now declares the roles permitted to perform it, and the publishing authorisation path now enforces role requirements. Read-only operations remain open to any role by design.