diff --git a/docs/faq/deprecated-features.md b/docs/faq/deprecated-features.md
index 71961aa7dbae..3671baec4eeb 100644
--- a/docs/faq/deprecated-features.md
+++ b/docs/faq/deprecated-features.md
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
| Patch Version | Release Date |
|---------------|---------------|
-| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
+| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
### What can I expect when a feature is marked for deprecation?
diff --git a/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
index 3cf3e0426d50..94f31fa0aa15 100644
--- a/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
+++ b/docs/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
@@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
| Rancher Version | Adapter Version |
|-----------------|:----------------:|
-| v2.9.0 | v104.0.0+up4.0.0 |
+| v2.9.1 | v104.0.0+up4.0.0 |
+| v2.9.0 | v104.0.0+up4.0.0 |
### 1. Gain Access to the Local Cluster
diff --git a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
index 381c4baee7d1..ebdbd0526ebd 100644
--- a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
+++ b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
## Impersonation
+:::caution Known Issue
+
+Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
+
+:::
+
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
diff --git a/docs/reference-guides/rancher-webhook.md b/docs/reference-guides/rancher-webhook.md
index 2dcfd257e299..81afd495fb0c 100644
--- a/docs/reference-guides/rancher-webhook.md
+++ b/docs/reference-guides/rancher-webhook.md
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|-----------------|-----------------|-----------------------|---------------------------|
+| v2.9.1 | v0.5.1 | ✓ | ✓ |
| v2.9.0 | v0.5.0 | ✗ | ✓ |
## Why Do We Need It?
diff --git a/src/pages/versions.md b/src/pages/versions.md
index 081016351028..6d87b0c84834 100644
--- a/src/pages/versions.md
+++ b/src/pages/versions.md
@@ -18,12 +18,12 @@ Here you can find links to supporting documentation for the current released ver
| Community |
- | v2.9.0 |
+ v2.9.1 |
Documentation |
- Release Notes |
- N/A |
+ Release Notes |
N/A |
✓ |
+ ✓ |
@@ -88,6 +88,30 @@ Here you can find links to supporting documentation for the current released ver
### Past Versions
+Here you can find links to supporting documentation for previous versions of Rancher v2.9, and their availability for [Rancher Prime](/v2.9/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
+
+
+
+ | Version |
+ Documentation |
+ Release Notes |
+ Support Matrix |
+ Prime |
+ Community |
+
+
+
+ | v2.9.0 |
+ Documentation |
+ Release Notes |
+ N/A |
+ N/A |
+ ✓ |
+
+
+
+
+
Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
diff --git a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
index d1fd5b1cad1d..591bcccdd673 100644
--- a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
+++ b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
@@ -82,6 +82,12 @@ You will need to use a context defined in this kubeconfig file to access the clu
## Impersonation
+:::caution Known Issue
+
+Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
+
+:::
+
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
diff --git a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
index 8abfd0c9f6cd..9797a3777966 100644
--- a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
+++ b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
@@ -81,6 +81,12 @@ You will need to use a context defined in this kubeconfig file to access the clu
## Impersonation
+:::caution Known Issue
+
+Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
+
+:::
+
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
diff --git a/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
index 08639d4b8197..617236638e53 100644
--- a/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
+++ b/versioned_docs/version-2.8/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
@@ -90,6 +90,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
## Impersonation
+:::caution Known Issue
+
+Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
+
+:::
+
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
diff --git a/versioned_docs/version-2.9/faq/deprecated-features.md b/versioned_docs/version-2.9/faq/deprecated-features.md
index 71961aa7dbae..3671baec4eeb 100644
--- a/versioned_docs/version-2.9/faq/deprecated-features.md
+++ b/versioned_docs/version-2.9/faq/deprecated-features.md
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
| Patch Version | Release Date |
|---------------|---------------|
-| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
+| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
### What can I expect when a feature is marked for deprecation?
diff --git a/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md b/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
index 3cf3e0426d50..94f31fa0aa15 100644
--- a/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
+++ b/versioned_docs/version-2.9/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter.md
@@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
| Rancher Version | Adapter Version |
|-----------------|:----------------:|
-| v2.9.0 | v104.0.0+up4.0.0 |
+| v2.9.1 | v104.0.0+up4.0.0 |
+| v2.9.0 | v104.0.0+up4.0.0 |
### 1. Gain Access to the Local Cluster
diff --git a/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
index 381c4baee7d1..ebdbd0526ebd 100644
--- a/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
+++ b/versioned_docs/version-2.9/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
## Impersonation
+:::caution Known Issue
+
+Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
+
+:::
+
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
diff --git a/versioned_docs/version-2.9/reference-guides/rancher-webhook.md b/versioned_docs/version-2.9/reference-guides/rancher-webhook.md
index 2dcfd257e299..81afd495fb0c 100644
--- a/versioned_docs/version-2.9/reference-guides/rancher-webhook.md
+++ b/versioned_docs/version-2.9/reference-guides/rancher-webhook.md
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|-----------------|-----------------|-----------------------|---------------------------|
+| v2.9.1 | v0.5.1 | ✓ | ✓ |
| v2.9.0 | v0.5.0 | ✗ | ✓ |
## Why Do We Need It?