<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Posts on Alex Neviarouskaya</title>
    <link>https://aneviaro.eu/posts/</link>
    <description>Recent content in Posts on Alex Neviarouskaya</description>
    <generator>Hugo -- 0.156.0</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 21 Feb 2026 11:19:21 +0100</lastBuildDate>
    <atom:link href="https://aneviaro.eu/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The Hidden Risk of GCP Viewer Role: Cross-Project Disk Replication</title>
      <link>https://aneviaro.eu/posts/the-hidden-risk-of-gcp-viewer-role-cross-project-disk-replication/</link>
      <pubDate>Sat, 21 Feb 2026 11:19:21 +0100</pubDate>
      <guid>https://aneviaro.eu/posts/the-hidden-risk-of-gcp-viewer-role-cross-project-disk-replication/</guid>
      <description>&lt;p&gt;&lt;strong&gt;TL;DR:&lt;/strong&gt; The legacy Basic &lt;code&gt;roles/viewer&lt;/code&gt; is riskier than you think. It grants &lt;code&gt;compute.disks.useReadOnly&lt;/code&gt;, which allows an attacker to clone disks (even CMEK encrypted ones) into an external project, effectively removing the CMEK encryption and bypassing specific KMS permissions you would expect to prevent this.&lt;/p&gt;
&lt;p&gt;While Google patched the direct disk cloning bypass following my disclosure, I have discovered a new workaround using snapshots that still allows attackers to strip CMEK encryption.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
