diff --git a/xep-0115.xml b/xep-0115.xml
index a86b8ff1..922422b4 100644
--- a/xep-0115.xml
+++ b/xep-0115.xml
@@ -2,6 +2,7 @@
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
   <!ENTITY % ents SYSTEM 'xep.ent'>
 %ents;
+<!ENTITY ltwarning "<p class='box'>Note: If the four characters '&amp;', 'l', 't', ';' appear consecutively in any of the factors of the verification string S (e.g., a service discovery identity of 'SomeClient&amp;lt;http://jabber.org/protocol/muc') then that string of characters MUST be treated as literally '&amp;lt;' and MUST NOT be converted to the character '&lt;', because completing such a conversion would open the protocol to trivial attacks.</p>">
 ]>
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
@@ -293,6 +294,7 @@
         <li>Ensure that S is encoded according to the UTF-8 encoding (&rfc3269;).</li>
         <li>Compute the verification string by hashing S using the algorithm specified in the 'hash' attribute (e.g., SHA-1 as defined in &rfc3174;). The hashed data MUST be generated with binary output and encoded using Base64 as specified in Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). <note>The OpenSSL command for producing such output with SHA-1 is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".</note></li>
       </ol>
+      &ltwarning;
     </section2>
     <section2 topic='Simple Generation Example' anchor='ver-gen-simple'>
       <p>Consider an entity whose category is "client", whose service discovery type is "pc", whose service discovery name is "Exodus 0.9.1", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):</p>
@@ -422,6 +424,7 @@
           </ol>
         </li>
       </ol>
+      &ltwarning;
     </section2>
   </section1>
 
@@ -584,6 +587,7 @@
         <li>The attacker would need to propagate the hash V before some other entity with the true input message S could broadcast presence with the relevant entity capabilities data and provide the true service discovery response (thus the attacker might need to subvert the development process of a particular software project or subvert the namespace issuance process of the &REGISTRAR;, or both).</li>
       </ol>
       <p>It currently seems extremely unlikely that an attacker could meet all of the foregoing conditions in the foreseeable future. However, the XMPP Council shall continue to monitor the state of cryptanalysis regarding the mandatory-to-implement hash function as well as the possibility that any vulnerabilities in that function might lead to practical threats against the entity capabilities protocol. If and when it becomes practical (or even possible) to launch effective preimage attacks against the entity capabilities protocol, the XMPP Council shall consider updating this specification to change the mandatory-to-implement hashing algorithm to a safer technology.</p>
+      &ltwarning;
     </section2>
     <section2 topic='Caps Poisoning' anchor='security-poisoning'>
       <p>Adherence to the method defined in the <link url='#ver'>Verification String</link> section of this document for both generation and processing of the 'ver' attribute helps to guard against poisoning of entity capabilities information by malicious or improperly implemented entities.</p>