diff --git a/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn b/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn
index b27eb64d4e..f1884d8f31 100644
--- a/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn
+++ b/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn
@@ -123,30 +123,34 @@ git-annex's url downloading.
 > to see if they used GETURLS. ipfs did, but not in an exploitable way.
 > datalad does; looped in its developers to asess. Rest appear not to.
 
-> TODO document this security issue in special remote protocol page
-
 An external special remote might also make a simple http request to a
 key/value API to download a key, and follow a redirect to file:///
 or http://localhost/.
 
 If the key uses a cryptographic hash, git-annex verifies the content. 
 But, the attacker could have committed a key that doesn't
-use a hash. Also, the attacker could use the hash check as an oracle.
+use a hash. Also, the attacker could use the hash check as an oracle,
+to guess at the content of files.
 
-What if an external special remote uses https to a hardcoded server (either
-fully hardcoded, or configured by the user when they enable the remote),
-and uses a http library that only supports https and http (not file:///).
-Is that good enough? An attacker would need to either compromise the server
-to redirect to a local private webserver, or MITM, and https should prevent
-the MITM.
+If the external special remote is encrypted, the http content is passed
+though gpg. So, whatever location an attacker redirects it to would also
+have to be encrypted. gpg is not told what encryption key the content is
+expected to be encrypted with. (Could it be told somehow for hybrid and
+shared encryption which key to use? pubkey encryption of course uses
+the regular gpg public key). 
 
-This seems to require auditing of all external special remotes.
-git-annex could add a new command to the external protocol, that asks
-the special remote if it's been audited, and refuse to use ones that have
-not.
+So if the attacker knows a file that the user has encrypted with any of
+their gpg keys, they can provide that file, and hope it will be decrypted.
+Note that this does not need a redirect to a local file or web server; the
+attacker can make their web server serve up a gpg encrypted file.
 
-I have emailed all relevant external special remote authors a heads-up and
-some questions.
+So, content downloaded from encrypted special remotes (both internal and
+external) must be rejected unless it can be verified with a hash. Then
+content using WORM and URL keys would not be able to be downloaded from
+them. Might as well also require a hash check for non-encrypted external
+special remotes, to block the redirection attack. There could be a config
+setting to say that the git-annex repository is not being shared with
+untrusted third parties, and relax that check.
 
 > TODO
 
diff --git a/doc/security/CVE-2018-10857.mdwn b/doc/security/CVE-2018-10857.mdwn
index bad9edd5fa..88ec3d36d2 100644
--- a/doc/security/CVE-2018-10857.mdwn
+++ b/doc/security/CVE-2018-10857.mdwn
@@ -1,24 +1,42 @@
 CVE-2018-10857: Some uses of git-annex were vulnerable to a private data
 exposure and exfiltration attack. It could expose the content of files
 located outside the git-annex repository, or content from a private web
-server on localhost or the LAN.
+server on localhost or the LAN. Joey Hess discovered this attack.
+
+Additionally, git-annex encrypted special remotes could be leveraged
+by an attacker to decrypt files that were encrypted to the user's gpg
+key. This attack could be used to expose encrypted data that was never
+stored in git-annex. Daniel Dent discovered this attack in collaboration
+with Joey Hess.
 
 This was fixed in git-annex 6.20180622.
 
 ## details
 
-The attacker needed to have control over one of the remotes of the git-annex
+The attacker needs to have control over one of the remotes of the git-annex
 repository. For example, they may provide a public git-annex repository that
 the victim clones. Or the victim may have paired repositories with them. Or,
 equivilantly, the attacker could have read access to the victim's git-annex
 repository (eg on a server somewhere), and some channel to get commits into it
 (eg a pull requests).
 
-The attacker does `git-annex addurl --relaxed file:///etc/passwd` and commits
-this to the repository in some out of the way place. Then they wait for the
-victim to pull the change. (As well as `file:///` urls, the attacker can
-use urls to private web servers. The url can also be one that the attacker
-controls, that redirects to such urls.)
+To perform the private data and exfiltration attack, the attacker
+runs `git-annex addurl --relaxed file:///etc/passwd` and commits this to
+the repository in some out of the way place. Then they wait for the victim
+to pull the change. (As well as `file:///` urls, the attacker can use urls
+to private web servers. The url can also be one that the attacker controls,
+that redirects to such urls.)
+
+To perform the gpg decryption attack, the attacker also needs to have
+control of an encrypted special remote of the victim's git-annex
+repository. The attacker uses `git annex addurl --relaxed` with
+an innocuous url, and waits for the user's git-annex to download it,
+and upload an (encrypted) copy to the special remote they also control.
+At a later point, when the user downloads the content from the special
+remote, the attacker instead sends them the content of a gpg encrypted
+file they wish to have decrypted in its place. Finally, the attacker
+drops their own copy of the original innocuous url, and waits for the user
+to send them the decrypted form of the file they earlier sent.
 
 The easiest exploit is when the victim is running the git-annex assistant, or
 is periodically doing `git annex sync --content`. The victim may also perform