Which versions of @hulumi/baseline are affected by CVE-2026-48035?

@hulumi/baseline versions prior to 1.4.0 allow insiders with S3 permissions to permanently delete CloudTrail and AWS Config records without trace, undermining the immutability protections required…. A patch is available.

How to fix or mitigate CVE-2026-48035?

Within 24 hours: Inventory all applications and infrastructure using @hulumi/baseline and document current versions in your environment. Within 7 days: Update all affected instances to @hulumi/baseline version 1.4.0 or later, and validate patch application in non-production environments first. Within 30 days: Conduct a cloud access review to restrict S3 delete permissions on audit buckets to only authorized personnel, and implement additional Object Lock controls beyond defaults.

@hulumi/baseline CVE-2026-48035

HIGH

Insufficient Technical Documentation (CWE-1059)

2026-06-10 https://github.com/kerberosmansour/hulumi

GHSA-2mxr-p26x-mj73

Information Disclosure

Lifecycle Timeline

Source Code Evidence Fetched

Jun 10, 2026 - 14:18 vuln.today

Analysis Generated

Jun 10, 2026 - 14:18 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 npm packages depend on @hulumi/baseline (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 1.4.0.

DescriptionCVE.org

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:

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.)
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.
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/baseline@1.4.0. 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.

AnalysisAI

Audit log tamper-resistance failure in @hulumi/baseline versions prior to 1.4.0 allows any S3-delete-capable principal in the AWS account to silently erase CloudTrail and AWS Config forensic records that the AccountFoundation construct was advertised to protect. Three compounding defects - hard-coded objectLock:false on the startup-hardened tier, unrestricted propagation of forceDestroy/logBucketForceDestroy to the audit bucket, and a sandbox tier that omitted Object Lock, server access logging, and the CloudTrail-Lake EventDataStore entirely - left consumers believing they had immutable audit capture when they did not. No public exploit identified at time of analysis, no CVSS or EPSS published, and the issue is a defense-in-depth/forensic-integrity weakness rather than a remote code execution path.

Technical ContextAI

The affected component is @hulumi/baseline, an npm-distributed Pulumi infrastructure-as-code library whose AccountFoundation construct provisions a baseline AWS account including an S3 bucket that receives CloudTrail trail delivery and AWS Config history/snapshot objects. The root cause is classified as CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency): the SecureBucket abstraction documented tamper-resistance for the startup-hardened tier but its implementation disabled S3 Object Lock bucket-wide to accommodate the AWS Config write-then-delete probe (ConfigWritabilityCheckFile), forwarded the destructive forceDestroy flag through to the audit bucket, and silently degraded the sandbox tier by skipping Object Lock, access logging, and the independent CloudTrail-Lake EventDataStore mirror. The 1.4.0 fix introduces an invariant in SecureBucket that triggers whenever awsServiceLogDelivery.cloudTrail or .config is true, rejecting forceDestroy on the hardened tier, always emitting the EventDataStore, and adding a deny s3:DeleteObject* bucket-policy statement scoped to the CloudTrail and Config prefixes (with the Config probe key excluded so write-then-delete still functions).

RemediationAI

Upgrade to @hulumi/baseline 1.4.0, which is the vendor-released patch and applies the SecureBucket invariant that rejects forceDestroy on the hardened tier, always provisions the CloudTrail-Lake EventDataStore (restoring immutable audit capture for sandbox accounts), and adds a deny s3:DeleteObject* bucket-policy statement scoped to the CloudTrail and AWS Config history/snapshot prefixes while excluding the ConfigWritabilityCheckFile probe key so Config's write-then-delete probe continues to function; review the CHANGELOG Migration notes since the forceDestroy behaviour changed and downstream stacks setting logBucketForceDestroy:true on the hardened tier will now fail closed. Patch details and the fix are in PR #178 (https://github.com/kerberosmansour/hulumi/pull/178) and the advisory at https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-2mxr-p26x-mj73. As a partial workaround while upgrading, replicate audit logs out-of-account to an Object-Locked archive bucket - this preserves a tamper-resistant copy but does not retroactively cover logs deleted before replication and does not address the sandbox-tier missing EventDataStore.