diff --git a/published/CVE-2019-9901-path-traversal.md b/published/CVE-2019-9901-path-traversal.md
index 0eb3c84..5a0b2a5 100644
--- a/published/CVE-2019-9901-path-traversal.md
+++ b/published/CVE-2019-9901-path-traversal.md
@@ -8,7 +8,7 @@ About a year ago, as a part of a customer project, I started looking at Istio, a
 In fact I liked it so much that I decided to submit a <a href="https://vimeo.com/289667003">talk</a> for it for <a href="https://javazone.no">JavaZone</a> in 2018.
 My favorite thing about Istio was, and still is, the mutualTLS authentication and authorization with workload bound certificates with SPIFFE identities.
 
-Istio has evolved a lot from the first version 0.5.0, which I initially looked at, to the 1.1 release. The 0.5.0 authorization policies came in the form of *deniers*, which sounded a lot like blacklists. The later versions have moved to a positive security model (whitelist), where you can specify which workloads (and/or end-users based on JWT) should be allowed to access certain services. Further restrictions can be specified using a set of protocol based authorization rules. I really like the coarse-grained workload authorization, but I'm not too fond of the protocol based rules. We have seen different parsers interpreting the same thing in different ways way too many times. Some perfect examples of this, are in Orange Tsai brilliant research presented in <a href="Orange Tsai">A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!</a>. I mentioned my concerns about this in some later versions of my Istio talk, but never actually tested it... untill now...
+Istio has evolved a lot from the first version 0.5.0, which I initially looked at, to the 1.1 release. The 0.5.0 authorization policies came in the form of *deniers*, which sounded a lot like deny lists. The later versions have moved to a positive security model (allow list), where you can specify which workloads (and/or end-users based on JWT) should be allowed to access certain services. Further restrictions can be specified using a set of protocol based authorization rules. I really like the coarse-grained workload authorization, but I'm not too fond of the protocol based rules. We have seen different parsers interpreting the same thing in different ways way too many times. Some perfect examples of this, are in Orange Tsai brilliant research presented in <a href="Orange Tsai">A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!</a>. I mentioned my concerns about this in some later versions of my Istio talk, but never actually tested it... untill now...
 
 ## The bug