The vulnerability in @hulumi/drift stems from improper handling of exceptional conditions within the DriftClassifier. The root cause is twofold, both located in packages/drift/src/classifier.ts.
First, the primary vulnerable function is DriftClassifier.classify. It was responsible for aggregating signals from various 'adapters' to produce a drift verdict. The flaw was that it only considered the detected boolean from an adapter's signal, while ignoring the ok boolean which indicates if the adapter executed successfully. In case of a transient error (e.g., network issue), an adapter would return {detected: false, ok: false}. The classify function would incorrectly interpret this as a valid 'no drift' signal, generate a None/none verdict, and cache it. This created a fail-open condition where a single transient error could mask real infrastructure changes or attacks for up to six hours (the default cache TTL).
Second, the meetsMinConfidence function aided this fail-open behavior. It is used to decide whether a verdict should be cached. The incorrect None/none verdict generated during an adapter failure has a confidence level of none. The original implementation of meetsMinConfidence allowed such verdicts to be cached if the caller didn't specify a minConfidence threshold. The patch corrects this by explicitly preventing any verdict with none confidence from being cached, regardless of the caller's configuration.
Additionally, the classify function had a second logic flaw where it would escalate verdicts to Mixed/high or ConsoleBreakGlass/high based on the liveness of a probe (snapshot.eventDelivered) rather than requiring concrete evidence of a console event from the CloudTrail adapter (ct.detected). This led to false positives, incorrectly escalating normal API churn to incident-level severity. The patch corrects this by making the escalation strictly dependent on ct.detected being true.