After weeks of development, I'm excited to announce v0.4.0 of my custom Slither detector toolkit — a collection of specialized static analysis tools designed to catch smart contract vulnerabilities that standard detectors sometimes miss.

This release includes 3 production-ready detectors focused on CEX integrations, oracle manipulations, and DeFi security patterns.

🔗 GitHub Repository: https://github.com/rdin777/slither-cex-detector

🎥 Full Video Demo: https://youtu.be/JwPMrYFv454

Why Custom Detectors?

While Slither comes with dozens of built-in detectors, real-world smart contract audits often require specialized checks for specific business logic. For example:

  • CEX integration functions that lack proper access control
  • Oracle price feeds used without validation
  • View functions that might return stale data during external calls

These patterns are common in DeFi protocols but aren't always caught by generic detectors. That's why I built this toolkit.

Detector 1: UnprotectedCEXCallback

What it detects: Functions that handle external data (oracle updates, CEX callbacks) without access control or signature verification.

Why it matters: If an oracle update function is unprotected, anyone can call it and manipulate prices, leading to exploits like flash loan attacks or liquidation manipulation.

Example Vulnerability:

 solidity contract CEXOracle { address public owner; uint256 public price; // ⚠️ VULNERABLE: No access control! function updatePrice(uint256 _newPrice) external { price = _newPrice; // Anyone can call this! } // ✅ SAFE: Proper access control function updatePriceSafe(uint256 _newPrice) external { require(msg.sender == owner, "Not owner"); price = _newPrice; } } Running the Detector: bash python run_detector.py unprotected-cex-callback CEXOracle.sol Output: [!] VULNERABILITIES FOUND: 1 [1] Function updatePrice in CEXOracle handles external data but lacks access control or signature verification. Detector 2: ReadOnlyReentrancy What it detects: View functions that read state variables modified by functions containing external calls (risk of returning stale data). Why it matters: If a contract updates its state AFTER making an external call (violating the Checks-Effects-Interactions pattern), a view function called during that external call could return outdated information. Attackers can exploit this for arbitrage or manipulation. Example Vulnerability: solidity contract VulnerableStaking { mapping(address => uint256) public balances; // ⚠️ VULNERABLE: State update AFTER external call function withdraw(uint256 amount) external { require(balances[msg.sender] >= amount); token.transfer(msg.sender, amount); // External call first! balances[msg.sender] -= amount; // State update too late } // View function can return stale data during transfer function getBalance(address user) external view returns (uint256) { return balances[user]; } } Running the Detector: bash python run_detector.py readonly-reentrancy ReadOnlyReentrancy.sol Note: This is a heuristic detector that may produce false positives. Manual review of execution order is recommended. Detector 3: TaintedDataFlow What it detects: Usage of unvalidated external data in critical operations (transfers, calculations). Why it matters: If data from an external oracle is used without validation (e.g., checking if price > 0), it can lead to division by zero, incorrect calculations, or fund drainage. Example Vulnerability: solidity contract TaintedLending { IPriceFeed public priceFeed; // ⚠️ VULNERABLE: No validation of oracle data function liquidate(address user) external { uint256 price = priceFeed.getPrice(); // External data (tainted) uint256 liquidationAmount = (1000 * 1e18) / price; // Division by zero if price = 0! payable(msg.sender).transfer(liquidationAmount); } // ✅ SAFE: Data is validated function liquidateSafe(address user) external { uint256 price = priceFeed.getPrice(); require(price > 0, "Invalid price"); // Sanitizer! uint256 liquidationAmount = (1000 * 1e18) / price; payable(msg.sender).transfer(liquidationAmount); } } Running the Detector: bash python run_detector.py tainted-data-flow TaintedData.sol Output: [!] VULNERABILITIES FOUND: 1 [1] Function liquidate in TaintedLending uses external data without validation before critical operations. Installation & Usage Requirements: Python 3.8+ Slither (pip install slither-analyzer) Quick Start: bash # Clone the repository git clone https://github.com/rdin777/slither-cex-detector.git cd slither-cex-detector # Create virtual environment python3 -m venv venv source venv/bin/activate # On Windows: venv\Scripts\activate # Install Slither pip install slither-analyzer # Run a detector python run_detector.py unprotected-cex-callback CEXOracle.sol Video Demo I recorded a complete walkthrough of all 3 detectors with real examples: Watch the full demo: https://youtu.be/JwPMrYFv454 What's Next? The roadmap for v0.5.0 includes: Improve ReadOnlyReentrancy to analyze AST execution order and reduce false positives Add GitHub Actions CI/CD workflow for automatic detector runs on PRs Expand Taint Analysis to track multi-hop data flows Add more detectors for common DeFi vulnerabilities Contributing Contributions, issues, and feature requests are welcome! Feel free to check the issues page. GitHub Repository: https://github.com/rdin777/slither-cex-detector Conclusion Building custom static analysis detectors is a powerful way to catch domain-specific vulnerabilities in smart contracts. This toolkit demonstrates how Slither's flexible architecture can be extended to create specialized security tools. If you found this useful, please give the repository a ⭐ and feel free to contribute! Stay secure out there. 🛡️ #solidity #web3security #slither #smartcontracts #cybersecurity #opensource #defi #blockchain