Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Affected: @hulumi/policies < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-284 (Improper Access Control) Summary HULUMI-H1 forbids raw aws:s3:Bucket outside of Hulumi's SecureBucket component, with one exemption: a raw bucket that's a child of a SecureBucket is allowed because the component is responsible for the hardening. HULUMI-H5 is the defence-in-depth check that closes the H1 exemption — for any raw bucket claiming it, H5 verifies the five hardening sibling resources a real SecureBucket always emits (public-access block, SSE-KMS, ownership controls, versioning, TLS-only bucket policy) are actually present. The bug: H5 only checked the siblings' types. It never verified that those siblings actually applied to the bucket being exempted. A consumer (or compromised PR) could pair an unhardened raw bucket with five hardening sibling resources whose bucket property pointed at a completely different bucket, and H5 would report no violation while the actual bucket shipped with zero…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected: @hulumi/policies < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-693 (Protection Mechanism Failure) Summary Pulumi gives every cloud resource a structured URN that includes the resource's type chain (hulumi:baseline:aws:SecureBucket$aws:s3/bucketV2:BucketV2) and the logical name the developer freely chose (anything after the final ::). Several Hulumi policy rules used the URN to grant exemptions — for example, "if this raw bucket is a child of SecureBucket, skip the raw-bucket rule because the parent component handles hardening." The bug: the rules looked for a substring like hulumi:baseline:aws:SecureBucket$ anywhere in the URN. That substring can also appear in the developer-controlled logical-name portion. A developer (or compromised PR) could simply name a raw resource so its logical name carried the trusted substring, and every rule that used this check would treat the resource as if it were inside the trusted parent and skip its hardening check. Codex reported this…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected: @hulumi/policies < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-697 (Incorrect Comparison) Summary AWS IAM trust policies can list more than one federated identity provider — for example, a role that accepts BOTH GitHub Actions OIDC and Google's OIDC. The GOIDC1 and GOIDC2 policy rules are supposed to flag IAM roles whose GitHub-OIDC trust is too permissive (e.g. wildcard sub: conditions that would let any branch or any pull request assume the role). The bug: when the role's Principal.Federated field was a JSON array of multiple providers, the rules failed to recognise that GitHub Actions was one of them. The providers list was coerced into a single comma-joined string, the matcher only looked at the start, and the GitHub OIDC hostname was lost in the join. Both rules concluded "this isn't a GitHub-OIDC role" and skipped the wildcard check. Impact A trust policy that listed the real GitHub OIDC provider ARN alongside any second provider would slip past both detectors.…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact: @hulumi/policies versions before 1.3.2 used stack-wide evidence shortcuts in several Cloudflare and deployment-governance validators. Unrelated compliant-looking evidence could suppress violations for different zones, hostnames, origins, or repositories in the same stack. Patched in 1.3.2: validators now correlate evidence to the specific protected resource and include regression coverage for unrelated-evidence bypasses. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
Recommended action: Upgrade to 1.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact: @hulumi/policies versions before 1.3.2 only checked exact AWS IAM StringLike/StringEquals condition operator keys in GOIDC1. Set-qualified operators such as ForAnyValue:StringLike could hide wildcard GitHub Actions OIDC sub conditions from the mandatory guardrail. Patched in 1.3.2: the AWS trust-policy inspector now evaluates set-qualified string operators and rejects unsafe GitHub OIDC sub conditions. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
Recommended action: Upgrade to 1.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact: @hulumi/policies versions before 1.3.2 did not fully inspect inline and attached IAM policy evidence for the administrator-policy guardrail, so some admin-equivalent policy paths could pass policy evaluation. Patched in 1.3.2: the validator inspects the affected policy shapes and includes regression tests. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
Recommended action: Upgrade to 1.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact: @hulumi/policies versions before 1.3.2 could accept spoofed SecureBucket parent evidence for HULUMI-H1, allowing policy evaluation to miss an unsafe bucket shape. Patched in 1.3.2: the validator now correlates evidence to the expected component/resource relationship and includes regression coverage. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
Recommended action: Upgrade to 1.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.