<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 02:23:53 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-341370</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-341370</link>
      <description>EUVD-2026-341370</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-341370</guid>
    </item>
    <item>
      <title>fkie_cve-2026-48032</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-48032</link>
      <description>&lt;p&gt;Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, IAM-role policy checks can be bypassed when the role trusts multiple OIDC providers. This issue has been patched in version 1.4.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Hulumi is an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Prior to version 1.4.0, IAM-role policy checks can be bypassed when the role trusts multiple OIDC providers. This issue has been patched in version 1.4.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-48032</guid>
    </item>
    <item>
      <title>GHSA-g759-4pxw-6692 — @hulumi/policies bypasses IAM-role policy checks when the role trusts multiple OIDC providers</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g759-4pxw-6692</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @hulumi/policies&lt;/p&gt;
&lt;p&gt;**Affected:** `@hulumi/policies` `&amp;lt; 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-697 (Incorrect Comparison)**&lt;/p&gt;
&lt;p&gt;#### Summary&lt;/p&gt;
&lt;p&gt;AWS IAM trust policies can list more than one federated identity provider — for example, a role that accepts BOTH GitHub Actions OIDC and Google&amp;#39;s OIDC. The `G_OIDC_1` and `G_OIDC_2` 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).&lt;/p&gt;
&lt;p&gt;The bug: when the role&amp;#39;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 &amp;#34;this isn&amp;#39;t a GitHub-OIDC role&amp;#34; and skipped the wildcard check.&lt;/p&gt;
&lt;p&gt;#### Impact&lt;/p&gt;
&lt;p&gt;A trust policy that listed the real GitHub OIDC provider ARN alongside any second provider would slip past both detectors. Consumers using `HulumiHardeningPack` or `HulumiGithubHardeningPack` could ship an IAM role with wildcard `sub:` conditions (allowing untrusted PRs from forks to assume the role) while their policy validation reported the stack as compliant. The G_OIDC_2 detector also failed to mark such roles for the cluster-admin / `AdministratorAccess` blast-radius check.&lt;/p&gt;
&lt;p&gt;#### Patches&lt;/p&gt;
&lt;p&gt;Upgrade to `@hulumi/policies@1.4.0`. The shared GitHub-OIDC-provider matcher no…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @hulumi/policies&lt;/p&gt;
&lt;p&gt;**Affected:** `@hulumi/policies` `&amp;lt; 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-697 (Incorrect Comparison)**&lt;/p&gt;
&lt;p&gt;#### Summary&lt;/p&gt;
&lt;p&gt;AWS IAM trust policies can list more than one federated identity provider — for example, a role that accepts BOTH GitHub Actions OIDC and Google&amp;#39;s OIDC. The `G_OIDC_1` and `G_OIDC_2` 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).&lt;/p&gt;
&lt;p&gt;The bug: when the role&amp;#39;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 &amp;#34;this isn&amp;#39;t a GitHub-OIDC role&amp;#34; and skipped the wildcard check.&lt;/p&gt;
&lt;p&gt;#### Impact&lt;/p&gt;
&lt;p&gt;A trust policy that listed the real GitHub OIDC provider ARN alongside any second provider would slip past both detectors. Consumers using `HulumiHardeningPack` or `HulumiGithubHardeningPack` could ship an IAM role with wildcard `sub:` conditions (allowing untrusted PRs from forks to assume the role) while their policy validation reported the stack as compliant. The G_OIDC_2 detector also failed to mark such roles for the cluster-admin / `AdministratorAccess` blast-radius check.&lt;/p&gt;
&lt;p&gt;#### Patches&lt;/p&gt;
&lt;p&gt;Upgrade to `@hulumi/policies@1.4.0`. The shared GitHub-OIDC-provider matcher no…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g759-4pxw-6692</guid>
    </item>
  </channel>
</rss>
