added most of the vulns

README.md

@@ -1,37 +1,101 @@
-
 // TODO: Add and explain all the attack vectors exists on this planet.
 
+## List of Security Vulnerabilities
 
+> Author: Harendra Shakya ([LinkTree](https://linktr.ee/harendra_shakya))
 
-## All attack vectors -
-
-| Serial No. | Attack Vectors                  | Description |
-| ---------- | ------------------------------- | ----------- |
-| **1**      | Reentrancy                      |
-| **2**      | Oracle Manipulation             |
-| **3**      | Frontrunning                    |
-| **4**      | Denial of Service               |
-| **5**      | Signature Replay                |
-| **6**      | Malicious Honeypot              |
-| **7**      | Unsafe Delegatecalls            |
-| **8**      | Sandwich Attacks                |
-| **9**      | Flash Loan Attacks              |
-| **10**     | Griefing                        |
-| **11**     | Force Feeding                   |
-| **12**     | Cross-Chain Bridge manipulation |
-| **13**     | Insecure Randomness             |
-| **14**     | Accessing Private Data          |
-| **15**     | Phishing Through tx.origin      |
-| **16**     | Arithmetic Over/Under Flow      |
-| **17**     | Block timestamp Manipulation    |
-| **18**     | Unsafe external calls           |
-| **19**     | Unchecked return values         |
-| **20**     | Proxy Storage Collision         |
-| **21**     | Loops Gas Limit                 |
+- Reentrancy
+- Oracle Manipulation
+- Access Control
+  - Authentication With tx.origin
+  - Default Visibility
+  - Signature Verification
+  - Unprotected Ether Withdrawal
+  - Unprotected SELFDESTRUCT Instruction
+  - Missed Modifier
+  - Incorrect Modifier Names
+  - Overpowered Roles
+- Signature Replay
+- Unsafe Delegatecalls
+- Sandwich Attacks
+- Flash Loan Attacks
+- Griefing
+- Force Feeding
+- Account Existence Check for low level calls
+- Cross-Chain Bridge manipulation
+- Insecure Randomness
+- Accessing Private Data
+- Authentication With tx.origin
+- Delegatecall
+- Integer Arithmetic
+- Block timestamp Manipulation
+- Unsafe external calls
+- Unchecked return values
+- Proxy Storage Collision
+- Floating Point Arithmetic
+- Code Injection via delegatecall
+- Unchecked External Calls
+- Insufficient Gas Attacks
+- DOS
+  - Unexpected Revert
+  - Block Gas Limit
+  - External Calls without Gas Stipends
+- Offline Owner
+- Entropy Illusion
+- Privacy Illusion
+- Miner Attacks
+  - Transaction Ordering / Frontrunning
+  - Timestamp Manipulation
+- Unexpected Ether
+- External Contract Referencing
+- Uninitialized Storage Pointers
+- Writes to Arbitrary Storage Locations
+- Incorrect Interface
+- Arbitrary Jumps with Function Variables
+- Variable Shadowing
+- Assert Violation
+- Dirty Higher Order Bits
+- Complex Modifiers
+- Outdated Compiler
+- Use of Deprecated Solidity Functions
+- Function Selector Abuse
+- Experimental Language Features
+- Constructor call
+- Frontend (Off Chain) Attacks
+  - Short Address Attack
+- Historic Attacks
+  - Constructor Names
+  - Call Depth Attack
+  - Constantinople Reentrancy
+  - Solidity Abi Encoder v2 Bug
+- Payable Multicall
+- Bypass Contract Size Check
+- Code With No Effects
+- Logical Issues
+- Floating Pragma
+- Hash Collisions With Multiple Variable Length Arguments
+- Improper Array Deletion
+- Insufficient gas griefing
+- Unsafe Ownership Transfer
+- Loop through long arrays
+- Message call with hardcoded gas amount
+- Precision Loss in Calculations
+- Hiding Malicious Code with External Contract
+- Public burn
+- Requirement Violation
+- Right-To-Left-Override control character (U+202E)
+- Signature Malleability
+- Transaction Order Dependence
+- Typographical Error
+- Unprotected Upgrades
+- Unused Variable
+- Wrong inheritance
+- Governance Attack
+- Honeypot
 
 #
 
-# Resources
+# References
 
 [Rekt news](https://rekt.news/)
 

attack vectors/Access_Control.md

@@ -0,0 +1,49 @@
+# Access Control
+
+There are a number of common mistakes relating to access control.
+
+## Default Visibility
+
+The default visibility of solidity functions/state variables is `public`. Developers may forget to specify the visibility for a function/state variable that is intended to be private.
+
+## Authentication With tx.origin
+
+Sometimes developer use tx.origin instead of msg.sender. Tx.origin returns the address of the account that originally sent the call. Use this varible for authenticating leaves contract vulnerable to a phising-like attack.
+
+- [Sigmaprime: tx.origin Authentication](https://blog.sigmaprime.io/solidity-security.html#tx-origin)
+
+## Signature Verification
+
+It is a common pattern for smart contract systems to allow users to sign messages off-chain instead of directly requesting users to do an on-chain transaction because of the flexibility and increased transferability that this provides. Smart contract systems that process signed messages have to implement their own logic to recover the authenticity from the signed messages before they process them further. A limitation for such systems is that smart contracts can not directly interact with them because they can not sign messages. Some signature verification implementations attempt to solve this problem by assuming the validity of a signed message based on other methods that do not have this limitation. An example of such a method is to rely on msg.sender and assume that if a signed message originated from the sender address then it has also been created by the sender address. This can lead to vulnerabilities especially in scenarios where proxies can be used to relay transactions.
+
+- [SWC Registry: Lack of Proper Signature Verification](https://swcregistry.io/docs/SWC-122)
+
+### Remediation
+
+It is not recommended to use alternate verification schemes that do not require proper signature verification through `ecrecover()`.
+
+## Unprotected Ether Withdrawal
+
+Due to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account.
+
+This bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.
+
+- [SWC Registry: Unprotected Ether Withdrawal](https://swcregistry.io/docs/SWC-105)
+
+## Unprotected SELFDESTRUCT Instruction
+
+Due to missing or insufficient access controls, malicious parties can self-destruct the contract.
+
+- [SWC Registry: Unprotected SELFDESTRUCT](https://swcregistry.io/docs/SWC-106)
+
+## Missed Modifier
+
+It is important to have access control validations on critical functions that execute actions like modifying the owner, transfer of funds and tokens, pausing and unpausing the contracts, etc. Missing validations either in the modifier or inside require or conditional statements will most probably lead to compromise of the contract or loss of funds.
+
+## Missed Modifier
+
+Due to the developer’s mistakes and spelling errors, it may happen that the name of the modifier or function is incorrect than intended. Malicious actors may also exploit it to call the critical function without the modifier, which may lead to loss of funds or change of ownership depending on the function’s logic.
+
+## Missed Modifier
+
+Allowing users to have overpowered roles may lead to vulnerabilities. The practice of least privilege must always be followed in assigning privileges.

attack vectors/Flash_Loan_Attack.md

@@ -0,0 +1 @@
+A flash loan attack is an abuse of the smart contract security of a particular platform in which an attacker usually borrows a lot of funds that don’t require collateral. They then manipulate the price of a crypto asset on one exchange and quickly resell it on another one.

attack vectors/Frontrunning.md

@@ -0,0 +1,5 @@
+# Transaction Ordering / Frontrunning
+
+Miners can see transactions for a short time before they get included in a block, and exploit this information. They can also alter the order of transactions within a block. Users also have some influence over this process by setting gas prices. This can often pose a security risk, especially in systems where users are bidding or otherwise competing for something.
+
+- [Sigmaprime: Block Timestamp Manipulation](https://blog.sigmaprime.io/solidity-security.html#block-timestamp)

attack vectors/Hidden_malicious_code.md

@@ -0,0 +1,5 @@
+Developer of the contract can hide the code. Developers of a dApp publish their code and contract address to etherscan.io for everyone to have a look at it and audit. This creates some sort of trust for the project but, there is a way using which the developer can hide the malicious code.
+
+This kind of attack may fool many of the auditors out there. So, one good solution is to review the code for any external unverified address called via the constructor.
+
+- [Hiding Malicious Code](https://coinsbench.com/hiding-malicious-code-hack-solidity-8-db2cb93c843)

attack vectors/Honeypoy.md

@@ -0,0 +1,3 @@
+Honeypots are traps basically deployed to catch hold of the attacker.
+
+- [Honeypot | Hack Solidity #10](https://coinsbench.com/honeypot-hack-solidity-9-69bb7faddecd)

attack vectors/Sandwich_Attach.md

@@ -0,0 +1,4 @@
+At its core, a sandwich attack is a form of front-running that primarily targets decentralized finance protocols and services.
+In a sandwich attack, a nefarious trader looks for a pending transaction on the network of their choice, e.g., Ethereum. The sandwiching occurs by placing one order right before the trade and one right after it. In essence, the attacker will front-run and back-run simultaneously, with the original pending transaction sandwiched in between.
+
+The purpose of placing these two orders and surrounding pending transactions is to manipulate asset prices. First, the culprit will buy the asset the user is swapping to — e.g., using LINK to exchange to ETH — with their knowledge of ETH's price increasing. Then, the culprit will buy ETH for a lower price in order to let the victim buy at a higher value. The attacker will then sell ETH at a higher price afterward.

attack vectors/Signature_Replay.md

@@ -0,0 +1,6 @@
+# Signature Replay
+
+If a smart contract system performs any sort of signature verification, it may be vulnerable to signature replay attacks. (Keep in mind that any signature sent to a contract via calldata will be publicly available.) Keeping track of processed signatures in storage is a simple way to prevent such attacks. Furthermore, in some cases, signatures may be malleable, i.e. an attacker may be able to modify them (so that they may be replayed) without destroying their validity.
+
+- [SWC Registry: Missing Protection Against Signature Replay Attacks](https://swcregistry.io/docs/SWC-121)
+- [SWC Registry: Signature Malleability](https://swcregistry.io/docs/SWC-117)

attack vectors/Unsafe_Delegatecall.md

@@ -0,0 +1,5 @@
+Solidity allows calling external contracts via the DELEGATECALL opcode, which executes the code of an external contract in the persistent context of the present contract. Certain contracts perform DELEGATECALL calls using user-provided call data, which can effectively give full control to an attacker.
+
+-[Sigmaprime: delegatecall](https://blog.sigmaprime.io/solidity-security.html#delegatecall)
+
+- [SWC Registry: delegatecall to Untrusted Callee](https://swcregistry.io/docs/SWC-112)