7.1

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-48035

CVE-2026-48035: @hulumi/baseline: AccountFoundation audit-delivery S3 bucket could be silently weakened

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.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-48035

CVE-2026-48035:

7.1

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
@hulumi/baseline	npm	< 1.4.0	1.4.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability stems from insufficient security invariants within the Infrastructure-as-Code (IaC) components responsible for creating the AWS S3 bucket for audit logs. The analysis of the patch commit 03a46b9a13d11c792fc8470444dac6feaf3119f4 reveals that the SecureBucket component, and by extension the AccountFoundation component that consumes it, were the sources of the vulnerability.

Prior to the patch, the SecureBucket.constructor had three main flaws:

It did not prevent the forceDestroy option from being enabled on production-tier (startup-hardened) audit buckets, allowing for the complete deletion of audit logs upon stack destruction.
It did not enforce a tamper-resistance mechanism like a deny-delete bucket policy, making existing audit logs deletable by any principal with S3 delete permissions.
For sandbox tier deployments, it skipped the creation of a CloudTrail-Lake EventDataStore, which serves as an independent, immutable mirror of the audit trail.

The AccountFoundation.constructor was also identified as a vulnerable function because it directly utilized the flawed SecureBucket component and exposed its weaknesses, such as the forceDestroy option, to end-users.

The patch rectifies these issues by introducing new invariants within the SecureBucket constructor. These invariants are keyed on the bucket's declared function (awsServiceLogDelivery) rather than just its deployment tier. This ensures that any bucket designated as an audit log sink receives the necessary tamper-resistance protections, such as blocking forceDestroy and applying a scoped deny-delete bucket policy, regardless of whether it's in a startup-hardened or sandbox environment. It also ensures the CloudTrail-Lake EventDataStore is created for all audit buckets, restoring immutability for sandbox accounts.

Vulnerable functions

SecureBucket.constructor

packages/baseline/src/aws/secure-bucket.ts

The constructor for the `SecureBucket` component was responsible for creating an S3 bucket for audit logs but lacked sufficient security enforcement. It allowed `forceDestroy` to be enabled on production-tier audit buckets, did not apply a bucket policy to prevent object deletion (making logs tamperable), and failed to create an immutable CloudTrail-Lake `EventDataStore` for sandbox-tier buckets. These flaws made the audit trail vulnerable to deletion.

AccountFoundation.constructor

packages/baseline/src/aws/account-foundation.ts

The `AccountFoundation` component uses the `SecureBucket` component to provision the audit log bucket. It directly exposed the vulnerabilities of `SecureBucket` to its consumers. For example, it accepted a `logBucketForceDestroy: true` parameter and passed it to the underlying `SecureBucket`, which prior to the patch, would configure the audit bucket to be completely purgeable when the stack is destroyed.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.