diff --git a/pages/site/releases/3.0.md b/pages/site/releases/3.0.md
index 54bde09..e5f6a8f 100644
--- a/pages/site/releases/3.0.md
+++ b/pages/site/releases/3.0.md
@@ -6,7 +6,8 @@
 toc: true
 ---
 
-Download: **[3.0.13](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.13.war)**
+Download: **[3.0.15](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.15.war)**
+| [3.0.13](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.13.war)
 | [3.0.12](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.12.war)
 | [3.0.11](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.11.war)
 | [3.0.10](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.10.war)
@@ -21,7 +22,8 @@
 | [3.0.1](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.1.war)
 | [3.0.0](https://gerrit-releases.storage.googleapis.com/gerrit-3.0.0.war)
 
-Documentation: **[3.0.13](https://gerrit-documentation.storage.googleapis.com/Documentation/3.0.13/index.html)**
+Documentation: **[3.0.15](https://gerrit-documentation.storage.googleapis.com/Documentation/3.0.15/index.html)**
+| [3.0.13](https://gerrit-documentation.storage.googleapis.com/Documentation/3.0.13/index.html)
 | [3.0.12](https://gerrit-documentation.storage.googleapis.com/Documentation/3.0.12/index.html)
 | [3.0.11](https://gerrit-documentation.storage.googleapis.com/Documentation/3.0.11/index.html)
 | [3.0.10](https://gerrit-documentation.storage.googleapis.com/Documentation/3.0.10/index.html)
@@ -212,6 +214,55 @@
 
 ## Bugfix Releases
 
+### 3.0.15
+
+* Security Fixes
+
+  * [Issue 13621](https://bugs.chromium.org/p/gerrit/issues/detail?id=13621):
+  Make `PermissionBackend#ForRef` authoritative.
+
+    Fixes a misconception that leads to data being accessible through Gerrit
+    APIs that should be locked down.
+
+    Gerrit had two components for determining if a Git ref is visible to a
+    user: `(Default)RefFilter` and `PermissionBackend#ForRef` (e.g.,
+    `RefControl`). The former was always capable of providing correct results
+    for all refs. The latter only had logic to decide if a Git ref is visible
+    according to the Gerrit `READ` permissions. This includes all refs under
+    `refs/heads` as well as any other ref that isn't a database ref or a Git
+    tag. This component was unaware of Git tags and notedb-related refs. Hence,
+    when asked for a database reference such as `refs/changes/xx/yyyyxx/meta`,
+    the logic would allow access if the user has `READ` permissions on any of
+    the ref prefixes (such as the default "read refs/* Anonymous Users").
+
+    That was problematic, because it bypassed
+    [documented behavior](http://gerrit-documentation.storage.googleapis.com/Documentation/3.0.15/access-control.html)
+    where a user should only have access to a change if he can see the
+    destination ref. The same goes for other database references.
+
+  * [Issue 13514](https://bugs.chromium.org/p/gerrit/issues/detail?id=13514):
+  Work around Gitiles bug on `All-Users` visibility.
+
+    Gitiles has a special `FilteredRepository` wrapper that allows carefully
+    hiding refs based on the project's ACLs. There is however an optimization
+    that skips the filtering in case a user has `READ` permissions on every ACL
+    pattern(s). When the target repository is `All-Users`, the optimization
+    turns into a security issue because it allows seeing all personal information
+    associated with all accounts, i.e.:
+
+    * draft comments
+    * draft edits
+    * personally identifiable information (PII) of all users
+    * external ids
+
+    This fix now blocks Gitiles or any other part of Gerrit to abuse this power
+    when the target repository is `All-Users`, where nobody can be authorized
+    to skip the ACLs evaluation anyway.
+
+### 3.0.14
+
+This minor release has been withdrawn.
+
 ### 3.0.13
 
 * Breaking Changes