GHSA-32g3-35g9-wc9g
Fix: kerberosmansour/hulumi#178GHSA-32g3-35g9-wc9g is a CWE-755 vulnerability in @hulumi/drift. O3 Security confirms whether GHSA-32g3-35g9-wc9g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
@hulumi/drift: Drift classifier fails open on adapter errors and over-promotes Mixed verdicts
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-32g3-35g9-wc9g.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@hulumi/driftnpmDescription
Affected: @hulumi/drift < 1.4.0 — Fixed in: 1.4.0 — Severity: Medium — CWE-755 (Improper Handling of Exceptional Conditions)
Summary
@hulumi/drift runs four adapters that each ask a different question about whether a resource has drifted (Pulumi-state diff, provider-version change, CloudTrail event, etc.). A classifier combines the adapters' answers into a verdict like None / none, ConsoleBreakGlass / high, or Mixed / high, and caches the verdict for 6 hours by default.
Two related bugs from one root cause — the classifier only read each adapter's detected: true/false field and ignored whether the adapter itself succeeded:
- Cached "all clear" on adapter failure. When an adapter failed (e.g. transient network error from the Automation API), the classifier read
detected: false, concluded "no drift", and cached the verdict asNone / nonefor 6 hours. A single transient failure could mask real console-break-glass mutations for the rest of the window. - Mixed verdicts without real evidence. The
Mixed / highandConsoleBreakGlass / highverdicts (incident severity) could fire on the "the CloudTrail probe round-tripped successfully" signal rather than actual evidence that anything had been changed via the console. Normal provider-API churn could end up falsely escalated to incident severity.
Impact
Consumers running drift detection in CI / cron could see transient adapter failures silently cached as "all clear" — masking real attacks for up to six hours — or see ordinary provider-version churn falsely promoted to incident severity. Either way, the verdict source was unreliable for downstream incident workflows that gate on it.
Patches
Upgrade to @hulumi/[email protected]. Classifier-only fix (the TLA+-verified 6-row verdict matrix is byte-identical):
- adapter failures now fail closed to
Unknown / low, and degraded verdicts are not written to the cache; - the
Mixed/ConsoleBreakGlasspromotion now requires real CloudTrail event evidence rather than probe liveness.
Workarounds
Setting options.minConfidence: "medium" on the classifier call prevents the degraded None / none from being cached (it doesn't meet the threshold), partially mitigating case (1). No workaround for case (2).
Resources
- PR #178 (Cluster D); regression tests in
packages/drift/tests/classifier-fail-closed.test.ts.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @hulumi/drift | all versions | 1.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @hulumi/drift. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @hulumi/drift to 1.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-32g3-35g9-wc9g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-32g3-35g9-wc9g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-32g3-35g9-wc9g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-32g3-35g9-wc9g in your dependencies?
O3 detects GHSA-32g3-35g9-wc9g across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.