https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 00:58:19 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-48035 <p>Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, 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). This issue has been patched in version 1.4.0.</p> <p>Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, 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). This issue has been patched in version 1.4.0.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-48035 https://vulnerability.circl.lu/vuln/ghsa-2mxr-p26x-mj73 <p><strong>Affected:</strong> npm: @hulumi/baseline</p> <p>**Affected:** `@hulumi/baseline` `&lt; 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)**</p> <p>#### Summary</p> <p>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:</p> <p>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: &#34;sandbox&#34;`, 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.</p> <p>#### Impact</p> <p>Consumers using `AccountFoundation` could ship an AWS account whose CloudTrail / Config audit logs were deletable by any S3-delete-capable principal — while believing…</p> <p><strong>Affected:</strong> npm: @hulumi/baseline</p> <p>**Affected:** `@hulumi/baseline` `&lt; 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)**</p> <p>#### Summary</p> <p>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:</p> <p>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: &#34;sandbox&#34;`, 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.</p> <p>#### Impact</p> <p>Consumers using `AccountFoundation` could ship an AWS account whose CloudTrail / Config audit logs were deletable by any S3-delete-capable principal — while believing…</p> https://vulnerability.circl.lu/vuln/ghsa-2mxr-p26x-mj73