Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

CVE-2026-48036 — @hulumi/drift

Fix: kerberosmansour/hulumi#178

CVE-2026-48036 is a CWE-755 vulnerability in @hulumi/drift. A fix is available for @hulumi/drift — see the affected versions and patch details below.

Hulumi: Drift classifier fails open on adapter errors and over-promotes Mixed verdicts

Also known asGHSA-32g3-35g9-wc9g
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 CVE-2026-48036.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs43th percentile — riskier than 43% of all scored CVEsHighest risk
0.00%0.34%0.67%1.01%0.3%0.3%0.5%0.5%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

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.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@hulumi/driftnpm
37downloads / week

Description

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:

  1. 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 as None / none for 6 hours. A single transient failure could mask real console-break-glass mutations for the rest of the window.
  2. Mixed verdicts without real evidence. The Mixed / high and ConsoleBreakGlass / high verdicts (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 / ConsoleBreakGlass promotion 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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@hulumi/driftall versions1.4.0npm install @hulumi/drift@1.4.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @hulumi/drift, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @hulumi/drift to 1.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-48036 is resolved across your whole dependency graph.

  3. 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.

Frequently Asked Questions

**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 `detecte
O3 Security · Impact-Aware SCA

Is CVE-2026-48036 in your dependencies?

Find it across npm, including transitive dependencies.

CVE-2026-48036: @hulumi/drift — Fixed in 1.4.0