GHSA-2MXR-P26X-MJ73

Vulnerability from github – Published: 2026-06-10 13:38 – Updated: 2026-06-10 13:38
VLAI
Summary
@hulumi/baseline: AccountFoundation audit-delivery S3 bucket could be silently weakened
Details

Affected: @hulumi/baseline < 1.4.0Fixed in: 1.4.0Severity: 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/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.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@hulumi/baseline"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48035"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1059"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T13:38:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "**Affected:** `@hulumi/baseline` `\u003c 1.4.0` \u2014 **Fixed in:** `1.4.0` \u2014 **Severity:** High \u2014 **CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)**\n\n#### Summary\n\nThe S3 bucket that `AccountFoundation` creates to receive CloudTrail and AWS Config audit logs is meant to be tamper-resistant \u2014 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:\n\n1. **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 \u2014 bucket-wide Object Lock blocks an AWS Config write-then-delete probe \u2014 but the fix was a sledgehammer that disabled WORM for all objects, not just the probe key.)\n2. **`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.\n3. **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) \u2014 leaving sandbox accounts with no audit immutability at all.\n\n#### Impact\n\nConsumers using `AccountFoundation` could ship an AWS account whose CloudTrail / Config audit logs were deletable by any S3-delete-capable principal \u2014 while believing the startup-hardened tier guaranteed tamper-resistance. Sandbox-tier deployments had no audit immutability at all (defects 1 and 3 compounded).\n\n#### Patches\n\nUpgrade 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`):\n\n- refuses `forceDestroy: true` on the startup-hardened tier;\n- emits the CloudTrail-Lake `EventDataStore` regardless of parent tier (so sandbox accounts regain immutable audit capture);\n- 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\u0027s write-then-delete still works, which is why bucket-wide Object Lock is intentionally NOT re-enabled.\n\n#### Workarounds\n\nReplicating audit logs out-of-account to an Object-Locked archive bucket partially mitigates while you upgrade.\n\n#### Resources\n\n- [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster C); see CHANGELOG `### Migration` for the `forceDestroy` behaviour change.",
  "id": "GHSA-2mxr-p26x-mj73",
  "modified": "2026-06-10T13:38:37Z",
  "published": "2026-06-10T13:38:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-2mxr-p26x-mj73"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kerberosmansour/hulumi/pull/178"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kerberosmansour/hulumi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@hulumi/baseline: AccountFoundation audit-delivery S3 bucket could be silently weakened"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…