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

CVE-2026-48035 — @hulumi/baseline

Fix: kerberosmansour/hulumi#178

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

Hulumi: AccountFoundation audit-delivery S3 bucket could be silently weakened

Also known asGHSA-2mxr-p26x-mj73
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • 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-48035.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs38th percentile — riskier than 38% of all scored CVEsHighest risk
0.00%0.32%0.63%0.95%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.

1other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@hulumi/baselinenpm
41downloads / week

Description

Affected: @hulumi/baseline < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)

Summary

The S3 bucket that AccountFoundation creates to receive CloudTrail and AWS Config audit logs is meant to be tamper-resistant — if someone with delete access can erase from it, the forensic trail is gone. There were three independent ways the protection could be silently weakened:

  1. No Write-Once-Read-Many on the startup-hardened audit bucket. The startup-hardened tier hard-coded objectLock: false on the audit bucket. (The reason was real — bucket-wide Object Lock blocks an AWS Config write-then-delete probe — but the fix was a sledgehammer that disabled WORM for all objects, not just the probe key.)
  2. forceDestroy was forwarded to the audit bucket. Nothing prevented a downstream stack from setting logBucketForceDestroy: true, which made pulumi destroy purge every audit-log object on teardown.
  3. Sandbox tier dropped everything. Sandbox-tier AccountFoundation created its audit bucket with tier: "sandbox", which skipped Object Lock, server access logging, AND the CloudTrail-Lake EventDataStore (the independent immutable mirror) — leaving sandbox accounts with no audit immutability at all.

Impact

Consumers using AccountFoundation could ship an AWS account whose CloudTrail / Config audit logs were deletable by any S3-delete-capable principal — while believing the startup-hardened tier guaranteed tamper-resistance. Sandbox-tier deployments had no audit immutability at all (defects 1 and 3 compounded).

Patches

Upgrade to @hulumi/[email protected]. A single invariant in SecureBucket now fires whenever the bucket actually backs CloudTrail/Config delivery (i.e. awsServiceLogDelivery.cloudTrail === true || .config === true):

  • refuses forceDestroy: true on the startup-hardened tier;
  • emits the CloudTrail-Lake EventDataStore regardless of parent tier (so sandbox accounts regain immutable audit capture);
  • adds a deny-s3:DeleteObject* bucket-policy statement scoped to the CloudTrail and Config history/snapshot prefixes (a retention floor on the audit objects). The deny excludes the AWS Config ConfigWritabilityCheckFile probe key so Config's write-then-delete still works, which is why bucket-wide Object Lock is intentionally NOT re-enabled.

Workarounds

Replicating audit logs out-of-account to an Object-Locked archive bucket partially mitigates while you upgrade.

Resources

  • PR #178 (Cluster C); see CHANGELOG ### Migration for the forceDestroy behaviour change.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@hulumi/baselineall versions1.4.0npm install @hulumi/baseline@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/baseline, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @hulumi/baseline to 1.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-48035 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/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)** #### Summary The S3 bucket that `AccountFoundation` creates to receive CloudTrail and AWS Config audit logs is meant to be tamper-resistant — if someone with delete access can erase from it, the forensic trail is gone. There were three independent ways the protection could be silently weakened: 1. **No Write-Once-Read-Many on the startup-hardened audit bucket.** The startup-hardened tier hard-coded `objectLock: false` on the
O3 Security · Impact-Aware SCA

Is CVE-2026-48035 in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2026-48035: @hulumi/baseline — Fixed in 1.4.0