<?xml version="1.0" encoding="UTF-8"?>

<!-- AUTOGENERATED FILE. DO NOT EDIT. -->

<feed xmlns="http://www.w3.org/2005/Atom">
  <id>tag:google.com,2016:developer-connect-security-bulletins</id>
  <title>Developer Connect - Security Bulletins</title>
  <link rel="self" href="https://docs.cloud.google.com/feeds/developer-connect-security-bulletins.xml"/>
  <author>
    <name>Google Cloud Documentation</name>
  </author>
  <updated>2026-07-13T15:34:30.404844+00:00</updated>


  <entry>
    <title>GCP-2026-048</title>
    <id>tag:google.com,2016:developer-connect-security-bulletins#GCP-2026-048</id>
    <updated>2026-07-13T00:00:00+00:00</updated>
    <link rel="alternate" href="https://docs.cloud.google.com/developer-connect/docs/security-bulletins#GCP-2026-048"/>
    <content type="html"><![CDATA[<p><strong>Published:</strong> 2026-07-13</p><h3 class="hide-from-toc" data-text="Description" id="description" tabindex="-1">Description</h3><table>
<thead>
<tr>
<th>Description</th>
<th>Severity</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<p>When you create or update repository connections, Developer Connect uses
Secret Manager secrets to authenticate to third-party Git providers. For
GitLab Enterprise (GLE) and Bitbucket Data Center (BBDC) connections, these
referenced secrets were previously retrieved by the Developer Connect
service agent (P4SA) on your behalf. This meant that permission checks were
performed against the P4SA's credentials rather than those of the calling
principal. This could allow a principal with limited permissions to read
referenced Secret Manager secrets by pointing the repository
connection host URI to an attacker-controlled endpoint.</p>
<p>To mitigate this vulnerability and adhere to the security principle of least
privilege, Developer Connect now checks permissions against both the calling
principal's credentials (using end-user credentials) and the P4SA when
calling repository connection APIs for GitLab Enterprise (GLE) and Bitbucket Data
Center (BBDC) connections. Specifically, the server now verifies that both the
caller and the P4SA possess the <code dir="ltr" translate="no">secretmanager.versions.access</code>
IAM permission on the referenced Secret Manager
secrets.</p>
<p><b>What should I do?</b></p>
<p>No action is required for existing repository connections. If you encounter permission errors when creating or updating GitLab Enterprise (GLE) or Bitbucket Data Center (BBDC) repository connections, grant the Secret Manager Secret Accessor (<code dir="ltr" translate="no">roles/secretmanager.secretAccessor</code>) role on the referenced secrets to the user or service account creating or updating the connections.</p>
<p><b>What vulnerabilities are addressed by this patch?</b></p>
<p>This vulnerability allowed users with repository connection administrator
access to read referenced Secret Manager secrets because the
permission checks were only performed against the P4SA's credentials. By
requiring permission checks against both the calling principal (using end-user
credentials) and the P4SA for GitLab Enterprise (GLE) and Bitbucket Data Center
(BBDC) connections, only users authorized with the
<code dir="ltr" translate="no">secretmanager.versions.access</code> IAM permission on the
secrets (in addition to the P4SA itself) can use them in repository
connections.</p>
</td>
<td>Medium</td>
<td></td>
</tr>
</tbody>
</table>]]>
    </content>
  </entry>


</feed>
