@hulumi/policies EUVD-2026-68449

Exploitation requires the ability to submit arbitrary policy evaluation input to an application that uses @hulumi/policies for SecureBucket (HULUMI-H1) policy checks - specifically, the attacker must be able to control the evidence object passed to the validator. The CVSS 4.0 vector specifies PR:N and UI:N, meaning no privileges or user interaction are required against the vulnerable library itself; however, whether that translates to unauthenticated access in practice depends entirely on how the consuming application exposes its policy evaluation endpoint (i.e., whether callers must authenticate at the application layer before their evidence is processed). Exploitation is limited to systems running @hulumi/policies versions below 1.3.2 where SecureBucket policy evaluation is actively used. Systems that do not invoke the HULUMI-H1 policy check are not affected.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) yields a base score of 8.7, reflecting network-reachable, low-complexity, unauthenticated exploitation with high confidentiality impact on the vulnerable system. No integrity or availability impact is recorded, and no subsequent-system impact is indicated - suggesting the blast radius is confined to the policy-evaluated resource itself. No EPSS score was provided in the source data; risk extrapolation from EPSS is therefore not possible. The vulnerability is not listed in CISA KEV and no public exploit code has been identified, meaningfully reducing the probability of opportunistic mass exploitation. Real-world severity is further constrained by the product's niche deployment footprint - this is not a broadly distributed enterprise library. In aggregate: the CVSS score reflects a worst-case ceiling; actual organizational exposure is likely low for most environments unless @hulumi/policies is a direct dependency in a security-sensitive policy pipeline.

An attacker with access to an application endpoint that accepts policy evaluation input constructs a crafted request containing a SecureBucket parent evidence object that passes the shape check but misrepresents the actual bucket's parent relationship. The @hulumi/policies validator accepts the forged evidence as legitimate, evaluates the policy as safe, and grants access or suppresses alerts for what is in reality an unsafe bucket configuration. No public proof-of-concept code has been identified at time of analysis, but the attack logic is straightforward given the vulnerability description.