GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

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.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/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.
Severity
7.1 (High)
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
Show details on source website
To clipboard 

{
  "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.





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.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.