<?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>Alex Neviarouskaya Blog on Alex Neviarouskaya</title>
    <link>https://aneviaro.eu/</link>
    <description>Recent content in Alex Neviarouskaya Blog 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/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>
