Privilege Escalation via Misconfigured Role Inheritance in ERP Approval Workflows

During a routine internal review of the Enterprise ERP module's custom approval-workflow builder, our security team identified a case where a low-privilege user could, under a specific delegation configuration, end up approving their own high-value transactions rather than escalating them to a genuinely separate approver.

The root cause was a role-inheritance check that resolved a delegate's *effective* approval authority by walking the delegation chain, but didn't re-verify that the resolved approver was distinct from the original requester once delegation was more than one hop deep. In a two-hop delegation (A delegates to B, B delegates to C), the check correctly excluded A, but a specific ordering of delegation-expiry and role changes could cause the chain to resolve back to A under narrow timing conditions.

We found no evidence this was exploited against any client deployment — it was surfaced by our own internal red-team exercise rather than a client-reported incident. All ERP deployments were patched within our standard 30-day remediation window, and the fix adds an explicit terminal-approver identity check independent of the delegation-chain resolution logic, rather than relying on chain-walking alone.

Organizations running heavily customized approval workflows with multi-hop delegation are encouraged to review their delegation configurations and confirm the patch has been applied — reach out to your AftPak engagement lead if you're unsure which version you're running.