**Affected:** `@hulumi/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-693 (Protection Mechanism Failure)** #### Summary `AccountFoundation` can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. **GuardDuty reuse.** If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive `guardDutyDetectorId` output as if the baseline were active. 2. **Security Hub reuse.** Although the account import was read-only, Hulumi unconditionally created the CIS / NIST `StandardsSubscription` resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a later `pulumi destroy` of the stack would call `BatchDisableStandards`, unsubscribing the account from CIS / NIST compliance monitoring even on accounts that had those subscriptions before Hulumi ever ran. #### Impact Consumers using `AccountFoundation`'s reuse mode could: - ship deployments that appeared to enable a detective baseline but actually weren't (case 1), or - accidentally turn off CIS / NIST compliance monitoring on an existing account just by destroying a Hulumi stack (case 2 — no malicious intent needed; a normal stack teardown was enough). #### Patches Upgrade to `@hulumi/[email protected]`. - GuardDuty reuse now asserts the imported detector is `ENABLED` with `findingPublishingFrequency: FIFTEEN_MINUTES`. Wrong posture fails the deploy at preview time. - Security Hub reuse creates the CIS / NIST `StandardsSubscription` resources with `retainOnDelete: true`, so destroying a reused stack no longer unsubscribes the account. Net-new (non-reuse) deployments are unchanged. #### Workarounds Don't reuse pre-existing detective services with `AccountFoundation` before upgrading. If reuse is unavoidable, manually verify detector posture out-of-band. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster G); regression tests in `packages/baseline/tests/guardduty-reuse-posture.test.ts` and `packages/baseline/tests/securityhub-reuse-retain.test.ts`.
**Affected:** `@hulumi/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-693 (Protection Mechanism Failure)** #### Summary `AccountFoundation` can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. **GuardDuty reuse.** If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive `guardDutyDetectorId` output as if the baseline were active. 2. **Security Hub reuse.** Although the account import was read-only, Hulumi unconditionally created the CIS / NIST `StandardsSubscription` resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a later `pulumi destroy` of the stack would call `BatchDisableStandards`, unsubscribing the account from CIS / NIST compliance monitoring even on accounts that had those subscriptions before Hulumi ever ran. #### Impact Consumers using `AccountFoundation`'s reuse mode could: - ship deployments that appeared to enable a detective baseline but actually weren't (case 1), or - accidentally turn off CIS / NIST compliance monitoring on an existing account just by destroying a Hulumi stack (case 2 — no malicious intent needed; a normal stack teardown was enough). #### Patches Upgrade to `@hulumi/[email protected]`. - GuardDuty reuse now asserts the imported detector is `ENABLED` with `findingPublishingFrequency: FIFTEEN_MINUTES`. Wrong posture fails the deploy at preview time. - Security Hub reuse creates the CIS / NIST `StandardsSubscription` resources with `retainOnDelete: true`, so destroying a reused stack no longer unsubscribes the account. Net-new (non-reuse) deployments are unchanged. #### Workarounds Don't reuse pre-existing detective services with `AccountFoundation` before upgrading. If reuse is unavoidable, manually verify detector posture out-of-band. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster G); regression tests in `packages/baseline/tests/guardduty-reuse-posture.test.ts` and `packages/baseline/tests/securityhub-reuse-retain.test.ts`.
**Affected:** `@hulumi/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-693 (Protection Mechanism Failure)** #### Summary `AccountFoundation` can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. **GuardDuty reuse.** If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive `guardDutyDetectorId` output as if the baseline were active. 2. **Security Hub reuse.** Although the account import was read-only, Hulumi unconditionally created the CIS / NIST `StandardsSubscription` resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a later `pulumi destroy` of the stack would call `BatchDisableStandards`, unsubscribing the account from CIS / NIST compliance monitoring even on accounts that had those subscriptions before Hulumi ever ran. #### Impact Consumers using `AccountFoundation`'s reuse mode could: - ship deployments that appeared to enable a detective baseline but actually weren't (case 1), or - accidentally turn off CIS / NIST compliance monitoring on an existing account just by destroying a Hulumi stack (case 2 — no malicious intent needed; a normal stack teardown was enough). #### Patches Upgrade to `@hulumi/[email protected]`. - GuardDuty reuse now asserts the imported detector is `ENABLED` with `findingPublishingFrequency: FIFTEEN_MINUTES`. Wrong posture fails the deploy at preview time. - Security Hub reuse creates the CIS / NIST `StandardsSubscription` resources with `retainOnDelete: true`, so destroying a reused stack no longer unsubscribes the account. Net-new (non-reuse) deployments are unchanged. #### Workarounds Don't reuse pre-existing detective services with `AccountFoundation` before upgrading. If reuse is unavoidable, manually verify detector posture out-of-band. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster G); regression tests in `packages/baseline/tests/guardduty-reuse-posture.test.ts` and `packages/baseline/tests/securityhub-reuse-retain.test.ts`.
**Affected:** `@hulumi/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-693 (Protection Mechanism Failure)** #### Summary `AccountFoundation` can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. **GuardDuty reuse.** If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive `guardDutyDetectorId` output as if the baseline were active. 2. **Security Hub reuse.** Although the account import was read-only, Hulumi unconditionally created the CIS / NIST `StandardsSubscription` resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a later `pulumi destroy` of the stack would call `BatchDisableStandards`, unsubscribing the account from CIS / NIST compliance monitoring even on accounts that had those subscriptions before Hulumi ever ran. #### Impact Consumers using `AccountFoundation`'s reuse mode could: - ship deployments that appeared to enable a detective baseline but actually weren't (case 1), or - accidentally turn off CIS / NIST compliance monitoring on an existing account just by destroying a Hulumi stack (case 2 — no malicious intent needed; a normal stack teardown was enough). #### Patches Upgrade to `@hulumi/[email protected]`. - GuardDuty reuse now asserts the imported detector is `ENABLED` with `findingPublishingFrequency: FIFTEEN_MINUTES`. Wrong posture fails the deploy at preview time. - Security Hub reuse creates the CIS / NIST `StandardsSubscription` resources with `retainOnDelete: true`, so destroying a reused stack no longer unsubscribes the account. Net-new (non-reuse) deployments are unchanged. #### Workarounds Don't reuse pre-existing detective services with `AccountFoundation` before upgrading. If reuse is unavoidable, manually verify detector posture out-of-band. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster G); regression tests in `packages/baseline/tests/guardduty-reuse-posture.test.ts` and `packages/baseline/tests/securityhub-reuse-retain.test.ts`.
Update @hulumi/baseline to 1.4.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@hulumi/baseline: AccountFoundation reuse paths silently downgrade GuardDuty / Security Hub posture affects @hulumi/baseline (npm). Severity is medium. **Affected:** `@hulumi/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-693 (Protection Mechanism Failure)** #### Summary `AccountFoundation` can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. **GuardDuty reuse.** If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive `guardDutyDetectorId` output as if the baseline were active. 2. **Security Hub reuse.** Although the account import was read-only, Hulumi unconditionally created the CIS / NIST `StandardsSubscription` resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a later `pulumi destroy` of the stack would call `BatchDisableStandards`, unsubscribing the account from CIS / NIST compliance monitoring even on accounts that had those subscriptions before Hulumi ever ran. #### Impact Consumers using `AccountFoundation`'s reuse mode could: - ship deployments that appeared to enable a detective baseline but actually weren't (case 1), or - accidentally turn off CIS / NIST compliance monitoring on an existing account just by destroying a Hulumi stack (case 2 — no malicious intent needed; a normal stack teardown was enough). #### Patches Upgrade to `@hulumi/[email protected]`. - GuardDuty reuse now asserts the imported detector is `ENABLED` with `findingPublishingFrequency: FIFTEEN_MINUTES`. Wrong posture fails the deploy at preview time. - Security Hub reuse creates the CIS / NIST `StandardsSubscription` resources with `retainOnDelete: true`, so destroying a reused stack no longer unsubscribes the account. Net-new (non-reuse) deployments are unchanged. #### Workarounds Don't reuse pre-existing detective services with `AccountFoundation` before upgrading. If reuse is unavoidable, manually verify detector posture out-of-band. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster G); regression tests in `packages/baseline/tests/guardduty-reuse-posture.test.ts` and `packages/baseline/tests/securityhub-reuse-retain.test.ts`.
AI coding agents often install or upgrade packages automatically in npm. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @hulumi/baselinenpm | <1.4.0 | 1.4.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate @hulumi/baseline to 1.4.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@hulumi/baseline: AccountFoundation reuse paths silently downgrade GuardDuty / Security Hub posture affects @hulumi/baseline (npm). Severity is medium. **Affected:** `@hulumi/baseline` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-693 (Protection Mechanism Failure)** #### Summary `AccountFoundation` can either create AWS detective services (GuardDuty for threat detection, Security Hub for compliance dashboards) or reuse pre-existing ones via opt-in flags. The reuse paths just imported the existing resources and reported success — they never checked whether the existing services were actually doing their job. 1. **GuardDuty reuse.** If the existing detector was suspended, or set to the slower 6-hour publishing cadence instead of the baseline 15-minute one, or otherwise misconfigured — Hulumi never noticed. The deployment succeeded with a misleadingly-positive `guardDutyDetectorId` output as if the baseline were active. 2. **Security Hub reuse.** Although the account import was read-only, Hulumi unconditionally created the CIS / NIST `StandardsSubscription` resources with default delete behaviour. Pulumi then treated those subscriptions as its own — a later `pulumi destroy` of the stack would call `BatchDisableStandards`, unsubscribing the account from CIS / NIST compliance monitoring even on accounts that had those subscriptions before Hulumi ever ran. #### Impact Consumers using `AccountFoundation`'s reuse mode could: - ship deployments that appeared to enable a detective baseline but actually weren't (case 1), or - accidentally turn off CIS / NIST compliance monitoring on an existing account just by destroying a Hulumi stack (case 2 — no malicious intent needed; a normal stack teardown was enough). #### Patches Upgrade to `@hulumi/[email protected]`. - GuardDuty reuse now asserts the imported detector is `ENABLED` with `findingPublishingFrequency: FIFTEEN_MINUTES`. Wrong posture fails the deploy at preview time. - Security Hub reuse creates the CIS / NIST `StandardsSubscription` resources with `retainOnDelete: true`, so destroying a reused stack no longer unsubscribes the account. Net-new (non-reuse) deployments are unchanged. #### Workarounds Don't reuse pre-existing detective services with `AccountFoundation` before upgrading. If reuse is unavoidable, manually verify detector posture out-of-band. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster G); regression tests in `packages/baseline/tests/guardduty-reuse-posture.test.ts` and `packages/baseline/tests/securityhub-reuse-retain.test.ts`.
AI coding agents often install or upgrade packages automatically in npm. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @hulumi/baselinenpm | <1.4.0 | 1.4.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard