fix links

src/pentesting-ci-cd/github-security/README.md

@@ -51,7 +51,7 @@ Tools (each tool contains its list of regexes):
 
 ### External Forks
 
-It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](./#execution-from-a-external-fork).
+It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](#execution-from-a-external-fork).
 
 ### Github Leaks in deleted/internal forks
 
@@ -116,7 +116,7 @@ Note that **2FA may be used** so you will only be able to access this informatio
 > [!NOTE]
 > Note that if you **manage to steal the `user_session` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
 
-Check the section below about [**branch protections bypasses**](./#branch-protection-bypass) in case it's useful.
+Check the section below about [**branch protections bypasses**](#branch-protection-bypass) in case it's useful.
 
 ### With User SSH Key
 

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -153,7 +153,7 @@ It's possible to check the permissions given to a Github Token in other users re
 > [!NOTE]
 > This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**.
 >
-> If you are in this scenario you can just check the [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action).
+> If you are in this scenario you can just check the [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
 
 ### Execution from Repo Creation
 
@@ -248,7 +248,7 @@ We have mentioned all the ways an external attacker could manage to make a githu
 
 ### Untrusted checkout execution
 
-In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](./#pull_request).
+In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](#pull_request).
 
 In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**.