At least one user experienced automated cloning failures on repositories configured with ZTNA or Egress connectivity, which left the affected roots stuck in a QUEUED state and prevented automated scanners from retrieving recent changes, causing vulnerability reporting for those repositories to go stale. The issue started on 2026-08-06 at 17:48 (UTC-5) and was reactively discovered 1.9 days later by a staff member who received a help-desk report that a customer's root had been stuck in a "Cloning queued..." state for more than two hours with no vulnerabilities being displayed. The problem was resolved within an additional 1.8 days, resulting in a total window of exposure of 3.7 days. 26 groups were identified with affected repositories.
As part of a scheduled secrets rotation cycle, the WARP connector credentials were rotated to values that were not valid for the connector's registration. The rotation procedure documented for this credential pair was not followed, and the new values were never validated against the connector before being deployed. With an invalid registration, the connector could not establish the tunnel to the customer network prior to cloning, and every cloning job on the affected queue failed. Two properties of the platform kept the failure invisible: the connector error was unhandled, so the root's cloning status was never transitioned out of QUEUED and the interface continued to display "Cloning queued..." instead of a failure state; and a credential error inside the root-filtering step caused cloning to abort for every root in the group rather than only those bound to the broken credential. No alert was raised for the sustained cloning failures, so the outage only became visible when a customer escalation reached the help desk.
The credential rotation was reverted to the previous valid value, restoring the connector's registration and unblocking cloning for the affected roots. Cloning was then hardened so that failures of this class cannot be silent again: group cloning actions were wrapped in a general exception handler so that an unexpected failure in one group no longer blocks the rest; roots are now partitioned by credential health before validation, so a credential error marks only its own roots as failed instead of aborting the entire group gather; and logging was upgraded to emit real tracebacks on failures. A proper rotation process for this credential pair will be established with tighter controls and a step-by-step guide, and sustained cloning failures will now trigger an explicit alert.
A credential rotation performed outside its documented procedure disabled the connector's network registration. Because the resulting cloning failures were neither surfaced in the root status nor alerted on, the outage persisted until a customer escalated it. Validating rotated credentials against the services that consume them before deployment, and alerting on sustained cloning failures, would have contained this within hours instead of days. ROTATION_FAILURE < MISSING_ALERT < INCOMPLETE_PERSPECTIVE