Race Condition in Concurrent Firewall Rule Deployment

AftPak's custom firewall rule engine distributes rule-set changes across a cluster of enforcement nodes as an atomic deployment. We identified a race condition where two administrators deploying independent rule changes to the same cluster within a short window — under default settings, inside the same few-hundred-millisecond deployment cycle — could result in a subset of nodes applying one administrator's rule set while the remaining nodes applied the other's, rather than the cluster converging on a single consistent rule set.

This was not an authentication or access-control failure — both administrators had legitimate deployment authority — but the resulting inconsistent state meant a firewall cluster could briefly enforce different rules on different nodes, which is exactly the kind of ambiguity a rule engine is meant to prevent.

This was identified during internal load-testing of concurrent multi-administrator deployment scenarios, not through a client-reported incident. The fix introduces a per-cluster deployment lock: a second deployment attempted while one is already in flight is now queued and applied as a genuinely sequential change, rather than racing against the first.

This affected only deployments with multiple administrators actively pushing rule changes to the same cluster concurrently — a low-frequency but real operational pattern for larger security teams. No customer action is required; the fix is enforced cluster-side.