https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 10:23:05 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-341052 EUVD-2026-341052 https://cve.radiocsirt.org/vuln/euvd-2026-341052 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48036 <p>Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, consumers running drift detection in CI / cron could see transient adapter failures silently cached as &#34;all clear&#34; — masking real attacks for up to six hours — or see ordinary provider-version churn falsely promoted to incident severity. Either way, the verdict source was unreliable for downstream incident workflows that gate on it. This issue has been patched in version 1.4.0.</p> <p>Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, consumers running drift detection in CI / cron could see transient adapter failures silently cached as &#34;all clear&#34; — masking real attacks for up to six hours — or see ordinary provider-version churn falsely promoted to incident severity. Either way, the verdict source was unreliable for downstream incident workflows that gate on it. This issue has been patched in version 1.4.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48036 https://cve.radiocsirt.org/vuln/ghsa-32g3-35g9-wc9g <p><strong>Affected:</strong> npm: @hulumi/drift</p> <p>**Affected:** `@hulumi/drift` `&lt; 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-755 (Improper Handling of Exceptional Conditions)**</p> <p>#### Summary</p> <p>`@hulumi/drift` runs four adapters that each ask a different question about whether a resource has drifted (Pulumi-state diff, provider-version change, CloudTrail event, etc.). A classifier combines the adapters&#39; answers into a verdict like `None / none`, `ConsoleBreakGlass / high`, or `Mixed / high`, and caches the verdict for 6 hours by default.</p> <p>Two related bugs from one root cause — the classifier only read each adapter&#39;s `detected: true/false` field and ignored whether the adapter itself succeeded:</p> <p>1. **Cached &#34;all clear&#34; on adapter failure.** When an adapter failed (e.g. transient network error from the Automation API), the classifier read `detected: false`, concluded &#34;no drift&#34;, and cached the verdict as `None / none` for 6 hours. A single transient failure could mask real console-break-glass mutations for the rest of the window. 2. **Mixed verdicts without real evidence.** The `Mixed / high` and `ConsoleBreakGlass / high` verdicts (incident severity) could fire on the &#34;the CloudTrail probe round-tripped successfully&#34; signal rather than actual evidence that anything had been changed via the console. Normal provider-API churn could end up falsely escalated to incident severity.</p> <p>#### Impact</p> <p>Consumers running drift detection in CI / cron could see transient adapter failures silently cached as &#34;all clear&#34; — ma…</p> <p><strong>Affected:</strong> npm: @hulumi/drift</p> <p>**Affected:** `@hulumi/drift` `&lt; 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** Medium — **CWE-755 (Improper Handling of Exceptional Conditions)**</p> <p>#### Summary</p> <p>`@hulumi/drift` runs four adapters that each ask a different question about whether a resource has drifted (Pulumi-state diff, provider-version change, CloudTrail event, etc.). A classifier combines the adapters&#39; answers into a verdict like `None / none`, `ConsoleBreakGlass / high`, or `Mixed / high`, and caches the verdict for 6 hours by default.</p> <p>Two related bugs from one root cause — the classifier only read each adapter&#39;s `detected: true/false` field and ignored whether the adapter itself succeeded:</p> <p>1. **Cached &#34;all clear&#34; on adapter failure.** When an adapter failed (e.g. transient network error from the Automation API), the classifier read `detected: false`, concluded &#34;no drift&#34;, and cached the verdict as `None / none` for 6 hours. A single transient failure could mask real console-break-glass mutations for the rest of the window. 2. **Mixed verdicts without real evidence.** The `Mixed / high` and `ConsoleBreakGlass / high` verdicts (incident severity) could fire on the &#34;the CloudTrail probe round-tripped successfully&#34; signal rather than actual evidence that anything had been changed via the console. Normal provider-API churn could end up falsely escalated to incident severity.</p> <p>#### Impact</p> <p>Consumers running drift detection in CI / cron could see transient adapter failures silently cached as &#34;all clear&#34; — ma…</p> https://cve.radiocsirt.org/vuln/ghsa-32g3-35g9-wc9g