--- CBOR-XS/XS.pm	2016/11/25 06:13:16	1.62
+++ CBOR-XS/XS.pm	2016/11/25 12:16:12	1.63
@@ -987,7 +987,12 @@
 any buffer overflows. Obviously, this module should ensure that and I am
 trying hard on making that true, but you never know.
 
-Second, you need to avoid resource-starving attacks. That means you should
+Second, CBOR::XS supports object serialisation - decoding CBOR can cause
+calls to I<any> C<THAW> method in I<any> package that exists in your
+process (that is, CBOR::XS will not try to load modules, but any existing
+C<THAW> method or function can be called, so they all have to be secure).
+
+Third, you need to avoid resource-starving attacks. That means you should
 limit the size of CBOR data you accept, or make sure then when your
 resources run out, that's just fine (e.g. by using a separate process that
 can crash safely). The size of a CBOR string in octets is usually a good
@@ -996,7 +1001,7 @@
 too late when you already have it in memory, so you might want to check
 the size before you accept the string.
 
-Third, CBOR::XS recurses using the C stack when decoding objects and
+Fourth, CBOR::XS recurses using the C stack when decoding objects and
 arrays. The C stack is a limited resource: for instance, on my amd64
 machine with 8MB of stack size I can decode around 180k nested arrays but
 only 14k nested CBOR objects (due to perl itself recursing deeply on croak