diff --git a/mesh/v1alpha1/istio.mesh.v1alpha1.pb.html b/mesh/v1alpha1/istio.mesh.v1alpha1.pb.html
index 968b40a2fb..0c442fe3cf 100644
--- a/mesh/v1alpha1/istio.mesh.v1alpha1.pb.html
+++ b/mesh/v1alpha1/istio.mesh.v1alpha1.pb.html
@@ -4421,6 +4421,20 @@ <h2 id="MeshNetworks">MeshNetworks</h2>
       port: 15443
       locality: us-east-1a
 </code></pre>
+<p>If <code>ENABLE_HCM_INTERNAL_NETWORKS</code> is set to true, MeshNetworks can be used to
+to explicitly define the networks in Envoy&rsquo;s internal address configuration.
+Envoy uses the IPs in the <code>internalAddressConfig</code> to decide whether or not to sanitize
+Envoy headers. If the IP address is listed an internal, the Envoy headers are not
+sanitized. As of Envoy 1.33, the default value for <code>internalAddressConfig</code> is set to
+an empty set. Previously, the default value was the set of all private IPs. Setting
+the <code>internalAddressConfig</code> to all private IPs (via Envoy&rsquo;s previous default behavior
+or via the MeshNetworks) will leave users with an Istio Ingress Gateway potentially
+vulnerable to <code>x-envoy</code> header manipulation by external sources. More information about
+this vulnerability can be found here:
+<a href="https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf">https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf</a>
+To preserve headers, you must explicitly configure MeshNetworks and set
+<code>ENABLE_HCM_INTERNAL_NETWORKS</code> to true. Envoy&rsquo;s <code>internalAddressConfig</code> will be set to
+the endpointed specified by <code>fromCidr</code>.</p>
 
 <table class="message-fields">
 <thead>
diff --git a/mesh/v1alpha1/network.pb.go b/mesh/v1alpha1/network.pb.go
index da259a63b0..5c65c44234 100644
--- a/mesh/v1alpha1/network.pb.go
+++ b/mesh/v1alpha1/network.pb.go
@@ -117,6 +117,21 @@ func (x *Network) GetGateways() []*Network_IstioNetworkGateway {
 //	    locality: us-east-1a
 //
 // ```
+//
+// If `ENABLE_HCM_INTERNAL_NETWORKS` is set to true, MeshNetworks can be used to
+// to explicitly define the networks in Envoy's internal address configuration.
+// Envoy uses the IPs in the `internalAddressConfig` to decide whether or not to sanitize
+// Envoy headers. If the IP address is listed an internal, the Envoy headers are not
+// sanitized. As of Envoy 1.33, the default value for `internalAddressConfig` is set to
+// an empty set. Previously, the default value was the set of all private IPs. Setting
+// the `internalAddressConfig` to all private IPs (via Envoy's previous default behavior
+// or via the MeshNetworks) will leave users with an Istio Ingress Gateway potentially
+// vulnerable to `x-envoy` header manipulation by external sources. More information about
+// this vulnerability can be found here:
+// https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf
+// To preserve headers, you must explicitly configure MeshNetworks and set
+// `ENABLE_HCM_INTERNAL_NETWORKS` to true. Envoy's `internalAddressConfig` will be set to
+// the endpointed specified by `fromCidr`.
 type MeshNetworks struct {
 	state protoimpl.MessageState `protogen:"open.v1"`
 	// The set of networks inside this mesh. Each network should
diff --git a/mesh/v1alpha1/network.proto b/mesh/v1alpha1/network.proto
index 26083d5ed4..1dfafa7e49 100644
--- a/mesh/v1alpha1/network.proto
+++ b/mesh/v1alpha1/network.proto
@@ -114,6 +114,21 @@ message Network {
 //       locality: us-east-1a
 // ```
 //
+// If `ENABLE_HCM_INTERNAL_NETWORKS` is set to true, MeshNetworks can be used to
+// to explicitly define the networks in Envoy's internal address configuration.
+// Envoy uses the IPs in the `internalAddressConfig` to decide whether or not to sanitize
+// Envoy headers. If the IP address is listed an internal, the Envoy headers are not
+// sanitized. As of Envoy 1.33, the default value for `internalAddressConfig` is set to
+// an empty set. Previously, the default value was the set of all private IPs. Setting
+// the `internalAddressConfig` to all private IPs (via Envoy's previous default behavior
+// or via the MeshNetworks) will leave users with an Istio Ingress Gateway potentially
+// vulnerable to `x-envoy` header manipulation by external sources. More information about
+// this vulnerability can be found here:
+// https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf
+// To preserve headers, you must explicitly configure MeshNetworks and set
+// `ENABLE_HCM_INTERNAL_NETWORKS` to true. Envoy's `internalAddressConfig` will be set to
+// the endpointed specified by `fromCidr`.
+//
 message MeshNetworks {
   // The set of networks inside this mesh. Each network should
   // have a unique name and information about how to infer the endpoints in
diff --git a/releasenotes/notes/mesh-network-internal-addr-config.yaml b/releasenotes/notes/mesh-network-internal-addr-config.yaml
new file mode 100644
index 0000000000..eb24cad69b
--- /dev/null
+++ b/releasenotes/notes/mesh-network-internal-addr-config.yaml
@@ -0,0 +1,16 @@
+apiVersion: release-notes/v2
+kind: bug-fix
+area: documentation
+issue:
+  - https://github.com/istio/istio/issues/53402
+
+releaseNotes:
+  - |
+    **Fixed** documentation for using MeshNetworks to configure envoy internal address configuration
+    when ENABLE_HCM_INTERNAL_NETWORKS is set to true. As of Envoy 1.33, the default value for
+    internalAddressConfig is set to an empty set. Previously, the default value was the set of all
+    private IPs. To preserve Envoy headers, you must explicitly configure MeshNetworks
+    or revert to Envoy's prior behavior by setting envoy.reloadable_features.explicit_internal_address_config
+    to false. Setting MeshNetworks to all private IPs or reverting to Envoy's previous behavior will leave
+    users with an Istio Ingress Gateway potentially vulnerable to x-envoy header manipulation by external
+    sources. More information about this vulnerability can be found here: https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf