diff --git a/content/posts/docker-privilege-escalation.md b/content/posts/docker-privilege-escalation.md
index 1d7b722..88e5bb4 100644
--- a/content/posts/docker-privilege-escalation.md
+++ b/content/posts/docker-privilege-escalation.md
@@ -6,10 +6,14 @@ authorTwitter = "" #do not include @
 cover = ""
 tags = ["Docker", "Security", "Privilege Escalation"]
 keywords = ["", ""]
-description = ""
+description = "How to gain root access by using a Docker engine running with default configuration."
 showFullContent = false
 +++
 
+This blog post is part of a series around [security](/tags/security) & [privilege escalation](/tags/privilege-escalation).
+
+---
+
 I have done a little security audit on a friend VPS last week, he was providing Docker runtime
 to some people, with SSH access, and wanted to know if his setup was secure.
 
@@ -55,7 +59,7 @@ drwx------  6 root root  4096 Aug 25 09:14 .
 -rw-r--r--  1 root root  5774 Aug 25 09:55 .bash_history
 ```
 
-Since Docker has SUID bit set, we were able to mount the whole host disk
+Since Docker has setuid bit set, we were able to mount the whole host disk
 inside the /mnt/root partition (*-v /:/mnt/root*). And since we are root, we can list */root*.
 
 Now let's try to mount again the host filesystem
diff --git a/content/posts/setuid-privilege-escalation.md b/content/posts/setuid-privilege-escalation.md
index 25387f8..2d6f8fc 100644
--- a/content/posts/setuid-privilege-escalation.md
+++ b/content/posts/setuid-privilege-escalation.md
@@ -6,10 +6,14 @@ authorTwitter = "" #do not include @
 cover = ""
 tags = ["Security", "Privilege Escalation"]
 keywords = ["", ""]
-description = ""
+description = "How to gain root access by exploiting wrongly designed setuid executables."
 showFullContent = false
 +++
 
+This blog post is part of a series around [security](/tags/security) & [privilege escalation](/tags/privilege-escalation).
+
+---
+
 [Setuid](https://en.wikipedia.org/wiki/Setuid) is a Unix access rights flag that allow users to run an executable 
 with the file system permissions of the executable's owner.
 
@@ -64,14 +68,14 @@ int main() {
 this executable has been designed by a sysadmin to allows non-root users to update the server packages
 to their latest version (very bad practice btw).
 
-While it may look simple & secure, it has an **important** vulnerability: a path injection vulnerability:
+While it may look simple & secure, it has a **serious** vulnerability.
 
 It uses the [apt](https://manpages.debian.org/buster/apt/apt.8.en.html)
 executable but doesn't invoke directly `/usr/bin/apt` but rather relies on apt to be in the [PATH](https://en.wikipedia.org/wiki/PATH_(variable)).
 
 Let's see how we can use this at our advantages by polluting the PATH.
 
-### How the PATH work exactly?
+### How does the PATH work exactly?
 
 The PATH variable is used to lookup executables when issuing command. It is composed of directories to include
 while searching, separated by a semicolon ':'.
@@ -102,7 +106,8 @@ uid=0(root) gid=1001(creekorful) groups=1001(creekorful)
 When the OS has look up the apt executable it searches in the following location:
 
 - /tmp/foo
-[rest of the path]
+
+*[rest of the path]*
 
 since we have appended /tmp/foo at first, the OS was able to find the apt executable in it
 and has executed it (with root privileges since they are propagated).