Dev.to Security 🔐 Cybersecurity 👁 0 📖 3 min read

Building 3 Custom Slither Detectors for Smart Contract Security (v0.4.0 Release)

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 detector

Building 3 Custom Slither Detectors for Smart Contract Security (v0.4.0 Release)

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

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.