diff --git a/docs/features/secrets.adoc b/docs/features/secrets.adoc
index f1ead155ab..2aa53fac62 100644
--- a/docs/features/secrets.adoc
+++ b/docs/features/secrets.adoc
@@ -150,29 +150,6 @@ Example:
 ${trim:${readFile:/secret/passphrase.txt}}
 ```
 
-=== Security and compatibility considerations
-
-// TODO(oleg_nenashev): Add a link to the advisory once ready
-
-Jenkins configurations might include property definitions,
-e.g. for Token Macro resolution in Mail Ext Plugin.
-Such properties are not supposed to be resolved when importing configurations,
-but the JCasC plugin has no way to determine which variables should be resolved when reading the configurations.
-
-In some cases non-admin users can contribute to JCasC exports if they have some permissions
-(e.g. agent/view configuration or credentials management),
-and they could potentially inject variable expressions in plain text fields like descriptions
-and then see the resolved secrets in Jenkins Web UI if the Jenkins admin exports and imports the configuration without checking contents.
-It led to a security vulnerability which was addressed in JCasC `1.25` (SECURITY-1446).
-
-- When reading configuration YAMLs, JCasC plugin will try to resolve
-  **all** variables having the `${VARNAME}` format.
-- Starting from JCasC `1.25`, JCasC export escapes the internal variable expressions,
-  e.g. as `^${VARNAME}`, so newly exported and then imported configurations are
-  are not subject for this risk
-- For previously exported configurations, Jenkins admins are expected to manually
-  resolve the issues by putting the escape symbol `^` in front of variables which should not be resolved
-
 === Secret sources
 
 In JCasC there is a link:https://jenkins.io/doc/developer/extensions/configuration-as-code/#secretsource[SecretSource extension point] which allows resolving variables passed to JCasC.