DEV Community: Heemin Kim

Business Logic Flaws: The Silent Killer of DeFi Security in 2026

Heemin Kim — Tue, 14 Apr 2026 13:23:28 +0000

In the first quarter of 2026, the DeFi ecosystem continues to thrive, but it also faces a chilling reality. An analysis of major hacking incidents over the past three months reveals an interesting shift. While past hacks primarily focused on typical code defects like 'Reentrancy' or 'Integer Overflow,' this year, 'Business Logic Flaws' have emerged as the most lethal threat.

The Quiet Raider of 2026: Business Logic Errors

According to recently collected data (Risk Feed), a significant number of large-scale asset drain incidents earlier this year exploited logical design flaws in smart contracts.

1. AlkemiEarn — 43.45 ETH Drained (March 2026)

The AlkemiEarn case was a classic business logic error. There was a logical flaw in how collateral value was calculated within the protocol's lending logic. Attackers exploited this to borrow significantly more assets than their actual collateral and vanished. The code operated "normally," but the "logic" itself was the problem.

2. SynapLogic — Business Logic Flaw (January 2026)

SynapLogic was also victimized by a business logic vulnerability. A logical path was discovered where permission checks could be bypassed under certain conditions, allowing attackers to access core system settings.

Why Static Analysis Alone Isn't Enough

Excellent static analysis tools like Slither or Semgrep are great at looking at the "shape of the code." However, they struggle to answer questions like, "Is it business-logically correct for this variable to change this way after this function is called?"

Business logic flaws are difficult to detect for the following reasons:

Context Dependency: General pattern matching is difficult because unique rules vary by protocol.
Complexity of State Changes: It requires tracking state changes that occur through a complex interplay of multiple functions.
Ambiguity in Permission Management: The more complex the logic of who can do what and when, the easier it is for gaps to appear.

ContractScan's Multi-Defense Strategy

ContractScan takes an approach beyond simple scanning to identify these 'invisible threats.'

Mythril (Symbolic Execution): Mathematically explores all possible execution paths of the code to find logical paths that can lead to abnormal states.
AI (LLM-based Code Reasoning): Goes beyond simple pattern matching to understand the 'intent' of the code. AI can point out logical contradictions by understanding interactions between functions and the business context.
Real-world Case Mapping (Case-based Detection): We index over 680 real-world hacking cases. If code with a logical structure similar to cases like AlkemiEarn or SynapLogic is found, an immediate alert is sent.

Auditor's Advice

To minimize business logic flaws as a smart contract developer, you must adhere to the following principles:

Principle of Least Privilege: Set clear access controls for every function and do not grant more permissions than necessary.
Define Invariants: Define core rules that the system must always maintain (e.g., "Total supply must always be less than total collateral") and include logic to verify them.
Verify with Diverse Engines: Do not rely on a single tool. Combine static analysis, symbolic execution, and AI-based reviews.

🛡️ Scan Your Contract Now

ContractScan uses Slither, Mythril, Aderyn, Semgrep, and AI engines to perform an in-depth analysis of your code in under 5 minutes.

Scan My Contract for Free

Important Notes
The content of this post is for educational and informational purposes only and does not constitute financial or legal advice. ContractScan is a tool to reduce security risks and does not guarantee the discovery of all vulnerabilities. It is strongly recommended to undergo a manual audit by a professional security firm before deploying high-value projects. We assume no legal liability for any losses incurred through the use of this service.

Beyond MythX: Smart Contract Security Roadmap for 2026

Heemin Kim — Fri, 10 Apr 2026 07:54:44 +0000

MythX shut down on March 31. For many Solidity teams, that meant scrambling to replace CI pipelines, SDK integrations, and audit workflows overnight. Our migration guide covered the immediate fix.

But the MythX shutdown is a symptom of a bigger shift. The smart contract security landscape is changing in ways that matter for every builder deploying code on-chain. This post covers where things are heading — and what we're building at ContractScan to stay ahead of it.

The Post-MythX Landscape

MythX was one of the first commercial smart contract security services. It combined Mythril's symbolic execution with proprietary analysis layers behind a paid API. When it shut down, it left a gap — but also exposed a problem with the single-vendor model.

The lesson: relying on a single security tool, behind a single company's API, is a single point of failure. When MythX went dark, teams that only used MythX had zero coverage overnight.

The move toward open, multi-engine approaches isn't just a trend — it's a risk mitigation strategy.

Trend 1: Multi-Engine Scanning Becomes the Default

No single analysis engine catches every vulnerability class. This has been proven repeatedly:

Engine Type	Catches	Misses
Static analysis (Slither)	Reentrancy, access control, state variable issues	Complex cross-contract logic
Symbolic execution (Mythril)	Path-dependent bugs, integer overflows	Large contracts (timeout)
Pattern matching (Semgrep)	Known vulnerability patterns, custom rules	Novel attack vectors
AI analysis	Business logic flaws, context-dependent issues	May miss low-level EVM edge cases

The Drift Protocol exploit ($285M, Q1 2026) involved governance key compromise — something no static tool would catch, though AI analysis of admin privilege patterns could have flagged the risk surface. Classic reentrancy bugs, by contrast, are textbook cases that static analysis flags instantly.

Where this is going: scanning with 2-3 engines is no longer "nice to have." It's the minimum for any contract holding real value. ContractScan already runs five engines in parallel (Slither, Mythril, Semgrep, Aderyn, and AI). The next step is smarter synthesis — not just merging results, but using cross-engine correlation to reduce false positives and elevate findings that multiple engines agree on.

Trend 2: AI Moves Beyond Pattern Matching

Early AI integration in security tools was essentially "run GPT on the findings list." That's table stakes now. The real value of AI in security analysis is catching things that rule-based tools fundamentally cannot:

Business logic violations: a lending protocol that allows borrowing without sufficient collateral under specific state combinations
Economic attack paths: flash loan sequences that manipulate price oracles across multiple pools
Cross-function state issues: where function A's side effects create an exploitable condition in function B

ContractScan's AI engine currently uses Gemini by default (with BYOK support for Claude and GPT). But the model is less important than what you feed it. We're working on giving the AI engine richer context:

Threat intelligence: our database of 686 real DeFi hack incidents — sourced from DeFiHackLabs and supplemented by a live feed collector — categorized across attack types, informs AI analysis. When the AI sees a pattern that resembles a known exploit, it cites the reference hack.
Cross-contract awareness: analyzing not just the target contract, but its interactions with external protocols and oracles.
Severity calibration: training on real-world loss data to better distinguish "theoretically possible" from "practically exploitable."

Trend 3: Security Shifts Left Into Developer Workflows

The traditional audit model — write code, deploy to testnet, hire an auditor, wait weeks, get a PDF — is too slow for how DeFi teams actually ship. Security needs to be part of the development loop, not a gate at the end.

IDE Integration

Catching a reentrancy bug in your editor is cheaper than catching it in a $50K audit. The upcoming Hardhat plugin will let you scan during development:

# Coming soon
# npm install --save-dev hardhat-contractscan

VS Code extension and MCP server integration are next on the roadmap — the goal is security feedback as fast as linting.

CI/CD as Security Gate

Every PR that touches Solidity should trigger a scan. This isn't new advice, but the tooling is finally good enough to make it practical without drowning in false positives:

# GitHub Actions — scan on every PR
- name: ContractScan Security Check
  run: |
    curl -X POST https://contract-scanner.raccoonworld.xyz/ci/scan \
      -F "file=@contracts/MyContract.sol" \
      -H "X-Api-Key: ${{ secrets.CONTRACTSCAN_API_KEY }}" \
      --fail-with-body

MCP: AI Agents as Security Reviewers

The newest development is Model Context Protocol (MCP) integration. The idea: AI coding assistants like Claude Code call a local ContractScan MCP server during development, getting structured scan results back inline.

"Scan this contract for vulnerabilities before I deploy."

We've built the ContractScan MCP server and it's installable today from source:

pip install -e contractscan_mcp/

PyPI publication and Smithery registry listing are in progress — not live yet. If you want to try it now, the source install path works.

Trend 4: Multi-Chain Is No Longer Optional

Solidity dominates, but the ecosystem is diversifying:

Rust/Near: ContractScan already supports Rust smart contracts via AI-powered analysis. Static analysis tooling for Rust contracts is less mature than Solidity, making AI coverage especially valuable here.
Move (Sui/Aptos): growing ecosystem with distinct vulnerability patterns.
Stylus (Arbitrum): Rust-based smart contracts on Ethereum L2.

The challenge is that each language has different vulnerability classes. Reentrancy looks different in Rust than in Solidity. Access control patterns vary by chain. Security tools need to understand these differences, not just apply Solidity rules to everything.

Our approach: Rust/Near AI analysis is live today. Expanding static analysis support for non-Solidity languages is on the roadmap, prioritized by ecosystem TVL and developer adoption.

What We're Building Next

Transparency about direction matters, especially after MythX showed what happens when a tool disappears without warning. Here's what's actively in progress at ContractScan:

Priority	What	Why
Now	Cross-engine finding correlation	Reduce noise, elevate high-confidence findings
Now	MCP server PyPI/Smithery listing	Source install works today; registry publication in progress
Next	VS Code extension	Real-time security feedback in editor
Next	Enhanced threat intelligence	Link findings to specific historical exploits
Later	Move language support	Follow ecosystem TVL growth
Later	Foundry fuzz integration	Combine static analysis with dynamic testing

We're a small team. That means we ship fast but have to be ruthless about priorities. If you're building on a chain or using a workflow we don't support yet, tell us — real usage data drives the roadmap.

The Bottom Line

The MythX era was about paying for a black-box API. The next era is about:

Multi-engine by default — no single tool is enough
AI as a first-class analysis layer — not a summary bot, but a reasoning engine
Security in the development loop — IDE, CI/CD, and AI assistant integration
Multi-chain readiness — Solidity-only is a shrinking percentage of the market

If you're migrating from MythX, start with a free QuickScan to see how multi-engine scanning compares to what you had. If you're already using ContractScan, the features above are what's coming next.

ContractScan is a multi-engine smart contract security scanner. QuickScan is free and unlimited — no sign-up required. Try it now.

Try ContractScan free at contract-scanner.raccoonworld.xyz

MythX Shutdown: Migration Guide for Smart Contract Security Teams

Heemin Kim — Fri, 10 Apr 2026 07:54:38 +0000

If you've been using MythX for smart contract security analysis, the deadline has passed: MythX (ConsenSys Diligence) officially shut down on March 31, 2026. API access is offline, and existing scans no longer function.

This post walks you through migrating to ContractScan — a free alternative that combines Slither static analysis, Semgrep pattern matching, and AI-powered vulnerability detection in a single scan.

MythX Is Now Offline

MythX was a cloud-based smart contract analysis platform by ConsenSys Diligence. As of April 1, 2026:

All MythX API endpoints are offline
Existing CI/CD pipelines using mythx-cli or the MythX SDK are failing
Paid subscriptions are no longer active

If you have active GitHub Actions or Hardhat plugins built around MythX, they need to be replaced immediately.

Why ContractScan Is a Strong MythX Alternative

Feature	MythX	ContractScan
Static analysis	✅	✅ Slither
Symbolic execution	✅	✅ Mythril (optional)
Pattern-based detection	❌	✅ Semgrep
AI-powered analysis	❌	✅ Claude AI
Free tier	Limited	Unlimited QuickScan, no sign-up
CI/CD integration	✅	✅ (Pro plan)

ContractScan runs multiple engines in parallel and synthesizes results into a single report with a security score, issue severity breakdown, and AI-generated remediation suggestions.

Quickstart: Scan Your First Contract

No account required. Visit contract-scanner.raccoonworld.xyz and paste your Solidity code directly, or scan by contract address.

For example, to scan the canonical reentrancy vulnerability:

pragma solidity ^0.8.0;
contract Vault {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        (bool ok,) = msg.sender.call{value: balances[msg.sender]}("");
        require(ok);
        balances[msg.sender] = 0; // state updated AFTER external call — reentrancy bug
    }
}

ContractScan will flag the reentrancy pattern, explain the exploit path, and suggest the Checks-Effects-Interactions fix — all in one report.

Replacing MythX in Your GitHub Actions CI/CD

The fastest free replacement for MythX in CI is Slither via the official GitHub Action:

# FREE: Slither static analysis (replaces MythX static layer)
- name: Run Slither
  uses: crytic/slither-action@v0.4.0
  with:
    target: 'contracts/'

Slither is the open-source static analyzer from Trail of Bits that MythX was partially built on. It catches most of the same vulnerability patterns.

ContractScan CI API (Paid Plans)

For teams that want Slither + AI analysis + multi-engine scanning in CI, ContractScan offers a CI/CD API on paid plans:

# ContractScan CI scan (requires Pro/Enterprise API key)
- name: Run ContractScan
  run: |
    curl -X POST https://contract-scanner.raccoonworld.xyz/ci/scan \
      -F "file=@contracts/MyContract.sol" \
      -H "X-Api-Key: ${{ secrets.CONTRACTSCAN_API_KEY }}" \
      --fail-with-body

The CI endpoint returns structured JSON with severity levels (low, medium, high, critical), matching MythX's SWC-level severity model. Use the response to fail your pipeline on findings above your threshold.

You can also scan contracts for free on the web UI — unlimited QuickScans, no account needed.

Migrating from the MythX Python SDK

If you used the MythX Python client directly:

# OLD: MythX SDK (deprecated)
from mythx_cli.client import Client
client = Client(api_key="...")
response = client.analyze(source_files={"Vault.sol": source})

ContractScan offers a Python-compatible MCP tool and a REST API:

# Scan via REST API (no auth required for free tier)
curl -X POST https://contract-scanner.raccoonworld.xyz/api/scan \
  -H "Content-Type: application/json" \
  -d '{"source": "pragma solidity ^0.8.0; contract Vault {...}"}'

Or use the ContractScan MCP server inside Claude Code:

Scan contracts/Vault.sol for security vulnerabilities using ContractScan.

What the ContractScan Report Looks Like

A typical scan result includes:

Security Score (0–100): overall contract health
Findings by severity: Critical / High / Medium / Low / Informational
Per-issue details: affected lines, exploit description, SWC reference (compatible with MythX's taxonomy)
AI remediation: concrete code fix suggestions from Claude AI
PDF export: audit-ready report for client delivery

Pricing

ContractScan's free tier offers unlimited QuickScans with no sign-up. For full multi-engine scans (Slither + Mythril + Semgrep + AI), upgrade to Pro at $59/mo or use Pay-per-scan at $11.90/scan. See the pricing page for details.

Summary

MythX shutting down is disruptive, but migrating is straightforward:

Immediately: replace MythX GitHub Action with ContractScan's action
This week: test your contracts at contract-scanner.raccoonworld.xyz (free, no account needed)
Before March 31: remove all mythx-cli or MythX SDK references from your pipeline

ContractScan combines the static analysis depth you relied on from MythX with AI-powered insights that catch logic-level vulnerabilities symbolic execution misses. And it's free to start today.

ContractScan is a smart contract security scanner. Free tier: unlimited QuickScans, no sign-up. CI/CD API and VS Code extension coming soon.

Try ContractScan free at contract-scanner.raccoonworld.xyz

The $285M Drift Hack: Q1 2026 DeFi Security Review

Heemin Kim — Fri, 10 Apr 2026 07:49:16 +0000

Q1 2026 has already seen over $450 million drained from crypto projects. Then April started with the Drift Protocol exploit — $285 million gone in under an hour. Here's what happened and what it means for builders.

Drift Protocol: $285M in 60 Minutes

On April 1, 2026, attackers compromised Drift Protocol, a Solana-based perpetual futures exchange, draining approximately $285 million. Drift's TVL dropped from $550M to under $300M, and the DRIFT token fell 40%.

How it happened:

The attacker gained unauthorized access to Drift's Security Council admin keys through a durable nonce exploit
With admin control, they manipulated oracle price feeds
Leveraged positions were liquidated at artificial prices, draining the protocol

This was not a smart contract code vulnerability. It was a governance and infrastructure attack — the kind that no static analysis tool catches. The lesson: even audited code is only as secure as the keys that control it.

Blockchain analytics firms Elliptic and TRM Labs independently linked the attack to DPRK-affiliated actors. TRM's investigation revealed on-chain staging began on March 11 with a 10 ETH withdrawal from Tornado Cash, consistent with patterns seen in previous state-sponsored exploits.

March 2026: $52M Across 20 Incidents

Before Drift, March was already brutal. PeckShield reported $52 million in losses from 20 separate incidents.

Solv Protocol — $2.7M (Reentrancy)

A classic reentrancy vulnerability in ERC-3525 deposit handling. The onERC721Received callback triggered a second mint during the initial deposit flow, allowing the attacker to double-mint tokens.

This is exactly the type of bug that automated scanners catch. Slither flags reentrancy patterns, and AI-powered analysis can identify the cross-function variant used here.

Venus Protocol — $2M Bad Debt (Price Manipulation)

An attacker spent months building a position in the Thena (THE) token market, then directly transferred tokens to the smart contract to manipulate exchange rates. The protocol was left holding $2M in bad debt.

Resolv Labs — $23M (Private Key Compromise)

Another key management failure. A compromised private key gave the attacker direct access to protocol funds.

The Pattern

Looking at Q1 2026 attacks, three categories emerge:

Attack Type	Example	Preventable by Code Audit?
Code-level bugs	Solv Protocol reentrancy	Yes — static analysis + AI detection
Oracle/price manipulation	Venus Protocol, Drift	Partially — oracle dependency checks
Key/governance compromise	Resolv Labs, Drift	No — requires operational security

Code-level vulnerabilities remain the most preventable category. Reentrancy, unchecked return values, integer overflow, and access control flaws can all be caught before deployment.

What You Can Do

Scan before you deploy. Run static analysis on every contract. Reentrancy and access control bugs have no excuse in 2026.
Use multiple engines. No single tool catches everything. Combine Slither, Semgrep, and AI-powered detection for broader coverage.
Check your dependencies. If your contract interacts with external price feeds or governance contracts, audit those trust boundaries.
Review admin access. Timelocks, multisig requirements, and key rotation policies are not optional.

Try It

ContractScan runs Slither + AI vulnerability detection on your Solidity code in under 5 minutes. Paste your code or enter a deployed contract address — no CLI setup required.

QuickScan is free and unlimited — no signup required. Paid plans unlock all 5 engines (Slither, Mythril, Semgrep, Aderyn, and AI) for deeper coverage.

Scan your contract now

Try ContractScan free at contract-scanner.raccoonworld.xyz

Live Threat Intelligence for Smart Contracts: How to Stay Ahead of Exploits

Heemin Kim — Fri, 10 Apr 2026 07:49:10 +0000

How ContractScan Tracks the Latest DeFi Hacks

The biggest problem with smart contract security tools is that they're frozen in time. Most scanners check your code against the ruleset that shipped with the tool. But DeFi hacks happen every week with new patterns.

ContractScan is different. Every week, we automatically collect new hack incidents and update our analysis database.

Automatic Threat Intelligence System

ContractScan's Risk Feed Collector pulls from these public sources:

1. Rekt.news RSS

The go-to media outlet for DeFi security incidents. Publishes technical analysis reports within days of each hack.

Collection frequency: Weekly
Data: Incident name, loss amount, vulnerability type, reference links

2. DeFiHackLabs (SunWeb3Sec)

An open-source GitHub project that maintains PoC (Proof of Concept) exploit code. Systematically archives DeFi hack incidents from 2020 to present.

Collection frequency: Weekly
Data: Incident name, date, loss amount, vulnerability classification, transaction hashes

3. SWC Registry

Smart Contract Weakness Classification — the standard taxonomy for smart contract vulnerabilities. New categories are automatically incorporated as they're added.

Current coverage: 37 SWC categories

Collection → Classification → Integration Pipeline

[Public Sources]  →  [Collector]  →  [Auto-Classification]  →  [Scan DB Update]
Rekt.news            Weekly          SWC mapping               defi_hacks DB
DeFiHackLabs         cron job        Keyword-based             Shown in scan reports
SWC Registry                         Categorization

Collected incidents are automatically classified by keyword:

Keyword	Classification	Example Incident
reentrancy, re-entrancy	SWC-107	Euler Finance ($197M)
access control, onlyowner	SWC-105	Poly Network ($611M)
flash loan, oracle	Oracle Manipulation	Mango Markets ($116M)
bridge, cross-chain	Bridge Exploit	Wormhole ($320M)
delegatecall	SWC-112	Parity Wallet ($150M)

Why This Matters

The Limitation of Static Rulesets

Traditional security tools only apply rules from their release date. If a new attack pattern is discovered in March 2026, that pattern goes undetected until the tool ships an update.

ContractScan's Approach

New incident occurs → Reported by public sources
Weekly collector runs → Automatically updates the DB
Applied from next scan → Enhanced detection of similar patterns
Real incident references in reports → "This code matches a pattern similar to incident X"

Users always receive scan results that reflect the latest threat intelligence.

Transparency

ContractScan doesn't hide what sources it uses for analysis.

All data sources are publicly available
Classification logic is transparent and documented in scan reports
Scan reports include referenced incidents and source links

This transparency is the foundation of trust. Not a black box — you can verify what evidence led to what conclusion.

Current Collection Status

Static DB: 15+ major incidents (The DAO, Cream Finance, Euler Finance, Ronin Bridge, etc.)
Dynamic collection: Automatic weekly updates
Total coverage: 37 SWC categories + DeFi-specific patterns (Oracle Manipulation, Bridge Exploit)

What's Next

SlowMist Hacked database integration
Automatic Semgrep rule generation pipeline for new incidents
Email alerts for subscribers when new vulnerabilities are detected

ContractScan isn't a "set it and forget it" tool. It's a living security tool. Every week it learns about new threats and applies them to your next scan.

Start scanning your smart contracts at ContractScan.

Try ContractScan free at contract-scanner.raccoonworld.xyz

Automating Smart Contract Security in Your CI/CD Pipeline

Heemin Kim — Fri, 10 Apr 2026 07:43:47 +0000

"I'll Just Scan Before Deployment" — That Mindset Is the Problem

Running security checks only right before deployment leads to:

Discovering vulnerabilities at the last minute — skyrocketing fix costs
Relying on humans to catch security issues during code review
Skipping security scans for "quick fixes"
Vulnerabilities getting merged into the main branch

Integrating security scans into CI/CD automatically detects vulnerabilities on every PR and blocks merges when critical issues are found.

Basic Setup: Slither on Every PR

Assumed Folder Structure

my-defi-project/
├── contracts/
│   ├── Token.sol
│   └── Vault.sol
├── hardhat.config.js
└── .github/
    └── workflows/
        └── security.yml

Basic Workflow

# .github/workflows/security.yml
name: Smart Contract Security Scan

on:
  pull_request:
    paths:
      - 'contracts/**/*.sol'  # Only run when Solidity files change

jobs:
  slither:
    name: Slither Analysis
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run Slither
        uses: crytic/slither-action@v0.4.0
        id: slither
        with:
          target: contracts/
          slither-args: '--filter-paths node_modules'
          fail-on: high  # Fail CI on high severity or above

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: ${{ steps.slither.outputs.sarif }}

This configuration:

Runs automatically on every PR that changes files in contracts/
Fails the check when HIGH severity or above vulnerabilities are found (can block merge)
Automatically uploads results to the GitHub Security tab

Advanced Setup: Multi-Engine + PR Comments

ContractScan API Integration

ContractScan provides a CI/CD scan API (/ci/scan) that works with any pipeline — GitHub Actions, GitLab CI, CircleCI, etc. Here's an example using GitHub Actions:

# .github/workflows/security-full.yml
name: Full Security Scan

on:
  pull_request:
    paths:
      - 'contracts/**'

jobs:
  security-scan:
    name: ContractScan CI Scan
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write  # Permission to post PR comments

    steps:
      - uses: actions/checkout@v4

      - name: Run ContractScan API
        id: scan
        run: |
          RESULT=$(curl -s -X POST https://contract-scanner.raccoonworld.xyz/ci/scan \
            -F "file=@contracts/MyContract.sol" \
            -H "X-Api-Key: ${{ secrets.CONTRACTSCAN_API_KEY }}")
          echo "$RESULT" > scan-result.json
          CRITICAL=$(echo "$RESULT" | jq '.severity_summary.Critical // 0')
          echo "critical-count=$CRITICAL" >> $GITHUB_OUTPUT

      - name: Security Gate
        if: steps.scan.outputs.critical-count > 0
        run: |
          echo "❌ Critical vulnerabilities found. Blocking merge."
          exit 1

See the CI/CD integration docs for full API reference and examples for other CI systems.

Example automated PR comment:

## ContractScan Security Report

🔴 **1 Critical** | 🟠 **2 High** | 🟡 **3 Medium**

### Critical Issues

**[SWC-107] Reentrancy in Vault.withdraw()**
- File: `contracts/Vault.sol:45`
- The contract state is changed after an external call.
- Fix: Apply Checks-Effects-Interactions pattern

---
Full report: [View on ContractScan](https://contract-scanner.raccoonworld.xyz/report/...)

Branch Protection Rules

In GitHub Settings → Branches → Branch protection rules:

Select main / master branch
Enable Require status checks to pass before merging
Add Slither Analysis or ContractScan CI Scan check
Enable Require branches to be up to date

Now PRs cannot be merged unless the security scan passes.

Practical Severity Policies

Failing CI on every finding creates too many false positives and blocks development. Recommended policy:

# Apply different thresholds per environment
jobs:
  security-scan:
    strategy:
      matrix:
        include:
          - branch: main
            fail-on: high      # main branch: block on high and above
          - branch: develop
            fail-on: critical  # develop: block on critical only

Or allowlist specific issues:

- name: Run Slither
  uses: crytic/slither-action@v0.4.0
  with:
    slither-args: >
      --exclude-informational
      --exclude-low
      --filter-paths "node_modules,test"

Hardhat / Foundry Project Integration

Hardhat Projects

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: '20'

  - run: npm ci

  - name: Compile contracts
    run: npx hardhat compile

  - name: Run Slither
    uses: crytic/slither-action@v0.4.0
    with:
      node-version: '20'
      hardhat: true

Foundry Projects

steps:
  - uses: actions/checkout@v4
    with:
      submodules: recursive

  - name: Install Foundry
    uses: foundry-rs/foundry-toolchain@v1

  - name: Build
    run: forge build

  - name: Run Slither
    uses: crytic/slither-action@v0.4.0
    with:
      foundry: true

Complete DevSecOps Pipeline

Developer commit
     ↓
[PR opened]
     ↓
GitHub Actions triggered
     ├── Slither static analysis (30s)
     ├── Semgrep pattern check (20s)
     └── AI vulnerability analysis (60s)
     ↓
Results auto-posted as PR comment
     ↓
Severity gate evaluation
  CRITICAL/HIGH → ❌ Merge blocked
  MEDIUM/LOW   → ⚠️ Warning only
     ↓
[Code review + fixes]
     ↓
Security scan passes
     ↓
[Final pre-deployment review]
     ↓
Mainnet deployment

Cost: Start Completely Free

GitHub Actions: Free for public repos, 2,000 free minutes/month for private repos
Slither: Open-source, free
ContractScan free tier: Unlimited QuickScans, no signup required

Consider paid plans as your team grows or scan volume increases. For now, you can build the entire pipeline at zero cost.

Conclusion: Automation Is the Answer to Security

Summary of what this series has covered:

Introduction: Why smart contract security matters — immutability, direct asset control
Reentrancy: From The DAO to Euler Finance, the CEI pattern and ReentrancyGuard
Top 5 Vulnerabilities: Access control, overflow, oracle manipulation, flash loans, front-running
Tool Comparison: Slither vs Mythril vs Semgrep — when to use what
CI/CD Automation: This post — integrating security into your pipeline

Run a free scan at contract-scanner.raccoonworld.xyz before deploying a single line of code. Five minutes can save millions.

Try ContractScan free at contract-scanner.raccoonworld.xyz

Slither vs Mythril vs Semgrep: Which Smart Contract Scanner Should You Use?

Heemin Kim — Fri, 10 Apr 2026 07:43:41 +0000

Why You Need Multiple Tools

Each tool uses a fundamentally different methodology:

Slither: Source code static analysis — fast with low false positives
Mythril: Symbolic execution — deep analysis, slower but finds complex vulnerabilities
Semgrep: Pattern matching — highly customizable, ideal for CI/CD

No single tool catches every vulnerability. Even The DAO hack was missed by the tools available at the time.

Slither — The Static Analysis Standard

Developed by Trail of Bits, Slither is the de facto standard for Solidity security analysis.

Installation and Usage

pip install slither-analyzer

# Scan a single file
slither contracts/Vault.sol

# Run specific detectors only
slither contracts/Vault.sol --detect reentrancy-eth,unprotected-ether-withdrawal

# JSON output (for CI integration)
slither contracts/Vault.sol --json results.json

Example Output

INFO:Detectors:
Vault.withdraw() (contracts/Vault.sol#12-18) sends eth to arbitrary user
        Dangerous calls:
        - (success,None) = msg.sender.call{value: amount}() (contracts/Vault.sol#15)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#suicidal

Reentrancy in Vault.withdraw() (contracts/Vault.sol#12-18):
        External calls:
        - (success,None) = msg.sender.call{value: amount}() (contracts/Vault.sol#15)
        State variables written after the call(s):
        - balances[msg.sender] = 0 (contracts/Vault.sol#17)

Slither Strengths / Weaknesses

Criteria	Rating
Speed	⚡ Fast (seconds)
Reentrancy detection	✅ Excellent
Access control	✅ Excellent
Oracle manipulation	⚠️ Limited
False positives	Low
Learning curve	Low

Over 60 built-in detectors, with support for writing custom detectors.

Mythril — Symbolic Execution Engine

Developed by ConsenSys, Mythril uses symbolic execution to explore all possible execution paths. (Note: MythX ≠ Mythril. MythX was a cloud service that included Mythril but shut down on 2026-03-31. Mythril itself remains open-source and fully usable.)

Installation and Usage

pip install mythril

# Analyze a source file
myth analyze contracts/Vault.sol

# Deeper analysis (takes longer)
myth analyze contracts/Vault.sol --execution-timeout 300

# Analyze EVM bytecode directly
myth analyze --bin-runtime 0x608060...

Example Output

==== Reentrancy ====
SWC ID: 107
Severity: High
Contract: Vault
Function name: withdraw()
PC address: 148

The contract account state is changed after an external call.

Initial State:
  Account: [attacker], balance: 0x1, nonce:0, storage: {}

Transaction Sequence:
  Caller: [attacker], calldata: , value: 0x1
  ...

Results are categorized according to the SWC (Smart Contract Weakness Classification) standard.

Mythril Strengths / Weaknesses

Criteria	Rating
Speed	🐢 Slow (minutes to tens of minutes)
Complex logic detection	✅ Excellent
Bytecode analysis	✅ Supported
False positives	Medium
Learning curve	Medium

Large contracts may hit timeouts. However, Mythril excels at finding vulnerabilities involving complex state transitions.

Semgrep — Pattern Matching and Customization

Semgrep is a general-purpose code security tool that supports Solidity rulesets. It is especially useful for defining team-specific vulnerability patterns.

Installation and Usage

pip install semgrep

# Use the public Solidity ruleset
semgrep --config=p/solidity contracts/

# Specific ruleset
semgrep --config=p/smart-contracts contracts/Vault.sol

Custom Rule Example

# Custom rule: detect tx.origin usage
rules:
  - id: tx-origin-auth
    patterns:
      - pattern: require(tx.origin == ...)
      - pattern: if (tx.origin == ...)
    message: |
      Using tx.origin for authentication is vulnerable to phishing attacks.
      Use msg.sender instead.
    languages: [solidity]
    severity: WARNING

Semgrep Strengths / Weaknesses

Criteria	Rating
Speed	⚡ Fast
Customization	✅ Excellent
Known pattern detection	✅ Excellent
Deep logic analysis	❌ Not supported
Learning curve	Low (basic) / Medium (custom rules)

Comprehensive Comparison

Criteria	Slither	Mythril	Semgrep
Methodology	Static analysis	Symbolic execution	Pattern matching
Speed	Fast	Slow	Fast
Reentrancy	✅	✅	⚠️
Access control	✅	✅	✅
Oracle manipulation	❌	⚠️	❌
Custom rules	⚠️	❌	✅
CI/CD suitability	✅	⚠️	✅
MythX replacement	Partial	✅	Partial

Practical Recommendations

Solo developer (indie, fast deployment):

Slither → CI integration → Pre-deployment ContractScan unified scan

Team development (enterprise, multisig management):

Slither + Semgrep (custom rules) → Automated PR checks → Pre-deployment Mythril deep analysis

High-value protocols:

All of the above + External audits (Certik, Trail of Bits, OpenZeppelin Audits)

Unified Scanning: One Command for All Engines

If installing and managing multiple tools separately seems cumbersome, ContractScan wraps five independent engines (Slither, Mythril, Semgrep, Aderyn, and AI) into a single scan.

# ContractScan CI API — run all five engines simultaneously
curl -X POST https://contract-scanner.raccoonworld.xyz/ci/scan \
  -F "file=@contracts/MyContract.sol" \
  -H "X-Api-Key: $CONTRACTSCAN_API_KEY"

Or scan directly on the web: https://contract-scanner.raccoonworld.xyz (no signup required)

The AI analysis layer catches business logic issues that static tools miss.

In the next post, we walk through integrating these tools into your CI/CD pipeline step by step — from branch protection rules to automated PR comment generation, covering the complete workflow.

Try ContractScan free at contract-scanner.raccoonworld.xyz

Introduction to Smart Contract Security

Heemin Kim — Fri, 10 Apr 2026 07:37:37 +0000

Code Is Law — and Bugs Lose Money

When a traditional web application has a bug, developers can take down the server and deploy a patch. Smart contracts are different.

A contract deployed to Ethereum cannot be modified. And it may hold tens of millions of dollars in assets.

2016 The DAO hack: $60 million stolen.
2021 Poly Network: $611 million stolen.
2022 Ronin Network: $625 million stolen.

All of these incidents shared one common trait: they exploited known vulnerability patterns that could have been detected with code review and automated scanning.

Why Smart Contracts Differ from Traditional Software

1. Immutability

// This contract can never be changed after deployment
contract SimpleVault {
    mapping(address => uint256) public balances;

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    // Even if there's a bug, it can't be fixed after deployment
    function withdraw(uint256 amount) external {
        balances[msg.sender] -= amount;
        payable(msg.sender).transfer(amount);
    }
}

If a bug is found after deployment, you must deploy a new contract and migrate all existing users. An attack can happen in the interim.

2. Direct Control of Financial Assets

Contracts directly hold ETH, ERC-20 tokens, and NFTs. While a SQL injection exposes data, a smart contract vulnerability immediately drains assets.

3. Public Code, 24/7 Attack Surface

Anyone can view the source code on Etherscan. Attackers analyze the code as soon as it is deployed and look for vulnerabilities. "Security through obscurity" does not work on blockchain.

Most Common Vulnerability Types

Reentrancy

Occurs when state is not updated before an external contract call. This caused The DAO hack.

Integer Overflow / Underflow

Before Solidity 0.8.0, SafeMath had to be used manually to prevent arithmetic overflows.

Access Control Vulnerabilities

Missing onlyOwner modifiers or incorrectly implemented permission schemes.

Flash Loan Attacks

Large uncollateralized loans within a single transaction, used to manipulate DeFi protocol price oracles.

Timestamp Dependence

Using block.timestamp as a random seed or for critical logic allows miner manipulation.

Integrating Security into Your Development Process

Security is not a checklist to add right before deployment. It must be considered from the very first line of code.

Step 1 — During development: Use battle-tested libraries from OpenZeppelin. Leverage proven patterns rather than rolling your own.

Step 2 — Before code review: Run an automated scan. Paste your source code into ContractScan for free Slither static analysis and AI vulnerability detection (no signup required).

Step 3 — CI/CD: Automate security scans in GitHub Actions. Catch vulnerabilities automatically on every PR.

Step 4 — Before deployment: Get a professional audit. High-value protocols should always undergo an external security audit.

Getting Started: Your First Scan in 5 Minutes

If you have code, check it for vulnerabilities right now:

Visit contract-scanner.raccoonworld.xyz
Paste your Solidity code or enter a contract address
Run the scan — results appear within seconds

Free unlimited QuickScans, no signup required.

In this series, we will dive deep into each vulnerability type. The next post covers a complete anatomy of reentrancy attacks — from The DAO to Euler Finance, with real exploit code and defense patterns.

Try ContractScan free at contract-scanner.raccoonworld.xyz

Smart Contract Security Audit Checklist

Heemin Kim — Fri, 10 Apr 2026 07:37:31 +0000

Before deploying a smart contract to mainnet, run through this checklist. Catching one critical issue here can save millions.

Access Control

[ ] All privileged functions have onlyOwner / role-based guards
[ ] tx.origin is never used for authorization (use msg.sender)
[ ] Initializer functions use initializer modifier (upgradeable contracts)
[ ] Admin key is a multi-sig, not an EOA
[ ] Ownership transfer is a two-step process

Arithmetic

[ ] Using Solidity 0.8.x (built-in overflow checks) or SafeMath
[ ] No division before multiplication (precision loss)
[ ] No unchecked blocks around critical math
[ ] Accounting for fee-on-transfer tokens where applicable

External Calls & Reentrancy

[ ] All external calls follow Checks-Effects-Interactions (CEI)
[ ] ReentrancyGuard on any function that sends ETH or makes external calls
[ ] Return values from call() / delegatecall() are checked
[ ] Cross-function and cross-contract reentrancy paths reviewed

Oracle & Price Safety

[ ] Not using AMM spot prices for anything critical
[ ] Using Chainlink or Uniswap TWAP for price feeds
[ ] Staleness check on oracle answers (updatedAt timestamp)
[ ] Fallback oracle or circuit breaker for oracle downtime

Flash Loan Vectors

[ ] No single-block price manipulation possible
[ ] Liquidity checks cannot be bypassed in one transaction
[ ] Protocol-owned liquidity is not vulnerable to sandwich attacks

Upgradability

[ ] Storage layout is documented and collision-free across proxy/impl
[ ] _disableInitializers() called in implementation constructor
[ ] Upgrade function is behind a timelock and multi-sig

Token Interactions

[ ] ERC-20 transfer() / transferFrom() return values checked
[ ] Compatible with non-standard tokens (USDT, USDC with no-return)
[ ] Deflationary / rebasing token edge cases considered

Gas & DoS

[ ] No unbounded loops over user-controlled arrays
[ ] No use of block.gaslimit as a constant
[ ] Pull-over-push pattern for ETH distributions

Events & Logging

[ ] All state-changing functions emit events
[ ] Events include enough context to reconstruct state off-chain

Testing

[ ] Unit tests cover happy path and edge cases
[ ] Fuzz tests for arithmetic and state transitions
[ ] Fork tests against mainnet state for DeFi integrations
[ ] Code coverage > 95%

Automated Pre-Check

Many of the above items can be caught automatically. ContractScan runs static analysis and AI-assisted review on your Solidity files — no setup required.

An automated scan is not a substitute for a full professional audit, but it's an excellent first pass before you engage an audit firm.

Try ContractScan free at contract-scanner.raccoonworld.xyz

Proxy Pattern Vulnerabilities: UUPS, Transparent, and Diamond

Heemin Kim — Fri, 10 Apr 2026 07:31:42 +0000

Upgradeability is one of the most requested features in smart contract development and one of the most dangerous to implement. The proxy pattern separates logic from storage, enabling contract upgrades — but the gap between proxy and implementation is where attackers find their foothold.

This post breaks down real vulnerability classes across the three dominant proxy patterns: UUPS, Transparent Proxy, and Diamond (EIP-2535). Each pattern introduces different attack surfaces. Each has caused real losses.

Why Proxies Are Risky by Design

A proxy contract stores state but delegates execution to an implementation contract via delegatecall. The implementation runs in the proxy's storage context — meaning state variables, msg.sender, and msg.value all belong to the proxy, not the implementation.

This creates an invariant that must hold: the storage layout of the implementation and the proxy must be compatible. Breaking that invariant is not a compile-time error. It's a silent, runtime catastrophe.

UUPS Proxies

UUPS (Universal Upgradeable Proxy Standard, EIP-1822) moves upgrade logic into the implementation contract itself. The proxy is minimal — it just does the delegatecall. Upgrades are triggered by calling upgradeTo() on the implementation.

Vulnerability 1: Uninitialized Implementation

The most common UUPS bug. OpenZeppelin's Initializable pattern replaces constructors for upgradeable contracts. If the implementation is deployed without calling initialize(), anyone can call it and set themselves as owner.

// Vulnerable: no initializer protection
contract VaultV1 is UUPSUpgradeable, OwnableUpgradeable {
    function initialize(address owner) public {
        __Ownable_init(owner); // must be guarded
    }

    function _authorizeUpgrade(address) internal override onlyOwner {}
}

The fix: use initializer modifier from OpenZeppelin, and additionally call _disableInitializers() in the constructor to lock the implementation contract itself:

constructor() {
    _disableInitializers(); // lock the bare implementation
}

This is now standard in OZ v4.9+, but countless deployed contracts predate this fix.

Vulnerability 2: Missing `_authorizeUpgrade` Guard

UUPS requires the implementation to define _authorizeUpgrade. If it's empty or missing the access check, anyone can upgrade to a malicious implementation:

// Critical bug: missing access control
function _authorizeUpgrade(address newImplementation) internal override {
    // empty — any caller can upgrade
}

An attacker calls upgradeTo(maliciousImpl), replaces logic, and drains funds. This has happened. Always gate _authorizeUpgrade with onlyOwner or a multisig role check.

Vulnerability 3: Implementation Self-Destruct

If the unprotected implementation is called directly (not via proxy) and contains a selfdestruct path, the implementation contract can be destroyed. The proxy still exists, but every delegatecall now hits dead code — effectively bricking the proxy permanently.

// If this implementation is called directly and selfdestructs...
function destroy() external onlyOwner {
    selfdestruct(payable(msg.sender));
}

Mitigation: never call selfdestruct in implementation contracts. The _disableInitializers() pattern also helps prevent direct exploitation of the implementation.

Transparent Proxy Pattern

In the Transparent Proxy pattern (OpenZeppelin's classic approach), the proxy distinguishes callers: the admin gets proxy-management functions (like upgradeTo), everyone else gets their call forwarded to the implementation.

Vulnerability 4: Storage Collision

The proxy stores admin state (admin address, implementation address) in specific storage slots. If an implementation's state variables land on the same slots, reads and writes corrupt each other.

// Implementation
contract Token {
    address public owner; // slot 0
    uint256 public totalSupply; // slot 1
}

// If the proxy also uses slot 0 for admin address — collision

OpenZeppelin solves this with pseudo-random storage slots derived from keccak256:

bytes32 internal constant IMPLEMENTATION_SLOT =
    0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

The risk is real when teams write custom proxies without following EIP-1967. Static analysis tools catch obvious pattern violations; storage layout diffs between upgrade versions need manual review.

Vulnerability 5: Admin Confusion / Selector Clash

If the admin calls a function whose selector happens to match a proxy admin function, the transparent proxy intercepts it. If a regular user calls the same selector on the proxy, it's forwarded to the implementation. This asymmetry has caused operational confusion and, in some setups, enabled unexpected access escalation.

Always verify selector collision between proxy admin functions and implementation functions before deploying.

Diamond Proxy (EIP-2535)

The Diamond standard extends proxy upgrades to a facet-based architecture: multiple implementation contracts (facets), each handling different function selectors. A DiamondCut operation adds, removes, or replaces facets.

Vulnerability 6: Storage Collision Between Facets

Each facet can define its own state variables. If two facets write to overlapping storage slots, reads from one facet corrupt state written by another.

The mitigation is Diamond Storage: each facet uses a unique storage struct at a deterministic slot:

library LibVault {
    bytes32 constant STORAGE_SLOT =
        keccak256("diamond.vault.storage.v1");

    struct Storage {
        mapping(address => uint256) balances;
        uint256 totalDeposits;
    }

    function get() internal pure returns (Storage storage s) {
        bytes32 slot = STORAGE_SLOT;
        assembly {
            s.slot := slot
        }
    }
}

Facets that access shared state through their own storage.slot variable instead of position-based slots avoid cross-facet collisions.

Vulnerability 7: Unsafe DiamondCut Access Control

DiamondCut is the most powerful function in the system — it can replace any facet logic. If diamondCut is callable by more than a trusted owner or timelock, the entire contract is compromisable.

// Missing access control on diamondCut
function diamondCut(
    FacetCut[] calldata _diamondCut,
    address _init,
    bytes calldata _calldata
) external {
    // no onlyOwner or role check — anyone can replace facets
    LibDiamond.diamondCut(_diamondCut, _init, _calldata);
}

Always lock diamondCut behind a multisig or DAO timelock. Treat it with the same caution you'd apply to upgradeTo.

Vulnerability 8: Function Selector Clashes Across Facets

The Diamond maps function selectors to facets. Adding a new facet with a selector that already exists silently overwrites the previous mapping — the old facet function is now unreachable without an explicit diamondCut to restore it.

// Before: selector 0xabcd1234 → FacetA.withdraw()
// DiamondCut adds FacetB with 0xabcd1234 → FacetB.emergencyStop()
// Now: withdraw() is unreachable — replaced silently

Tooling helps here: the Diamond standard's reference implementation includes selector deduplication checks, but custom implementations may skip them. Always enumerate selectors before and after any cut.

Detection and Tooling

Static analyzers catch several proxy bugs automatically:

Bug Class	Slither	Semgrep	Manual Review
Uninitialized implementation	Partial	Custom rules	Essential
Missing `_authorizeUpgrade` guard	Yes	Yes	—
Storage layout collision	Partial	—	Essential
DiamondCut access control	Partial	Custom rules	Essential
Selector clash	—	—	Essential

Slither's uninitialized-local and suicidal detectors catch some of the UUPS issues. The storage layout checks require comparing layouts between versions — a diff that automated scanners can assist but not fully replace.

When using ContractScan on an upgradeable contract, the AI engine is specifically prompted to check for proxy-related vulnerability patterns, including initialization gaps and access control on upgrade functions.

Upgrade Checklist

Before any proxy upgrade:

[ ] Storage layout diff — confirm no new variables inserted before existing ones
[ ] _authorizeUpgrade / diamondCut locked to owner/multisig
[ ] Implementation constructor calls _disableInitializers()
[ ] New initializer guarded with reinitializer(N) not initializer
[ ] Selector collision check if using Diamond
[ ] Upgrade script tested on a fork with production state
[ ] Timelock delay enforced for non-emergency upgrades

The Bottom Line

Proxy patterns trade immutability for flexibility, but that flexibility comes with a novel class of bugs that don't exist in non-upgradeable contracts. The storage layout invariant must hold across every upgrade. Access to upgrade functions must be strictly controlled. Initialization must be locked at both proxy and implementation level.

None of these checks are optional for contracts holding real value. A missed _authorizeUpgrade guard or an uninitialized implementation can hand full control of your contract to an attacker in a single transaction.

ContractScan is a multi-engine smart contract security scanner. QuickScan is free and unlimited — no sign-up required. Try it now.

Try ContractScan free at contract-scanner.raccoonworld.xyz

Flash Loan Attacks: A Complete Breakdown

Heemin Kim — Fri, 10 Apr 2026 07:28:07 +0000

Flash Loan Attacks: A Complete Breakdown

Flash loans are both a DeFi innovation and the single largest attack vector. They allow borrowing millions of dollars without collateral, manipulating prices within a single transaction, extracting profit, and repaying the loan — all atomically. The attacker's upfront cost is just the gas fee.

What Is a Flash Loan?

An uncollateralized loan that is borrowed and repaid within the same transaction. If not repaid, the entire transaction reverts. Available on Aave, dYdX, and Uniswap V2/V3.

// Aave V3 Flash Loan interface
function flashLoan(
    address receiverAddress,
    address[] calldata assets,
    uint256[] calldata amounts,
    uint256[] calldata interestRateModes,
    address onBehalfOf,
    bytes calldata params,
    uint16 referralCode
) external;

Attack Pattern: Price Oracle Manipulation

1. Borrow a large amount of Token A via flash loan
2. Dump Token A on a DEX → Token A price crashes
3. Target protocol uses the DEX spot price as its oracle
4. Set up collateral or trigger liquidation at the depressed price
5. Profit after price recovery
6. Repay the flash loan

Case 1: bZx (2020, ~$1M)

The first major DeFi flash loan attack. sUSD price was manipulated on Uniswap to take out an overvalued collateral loan.

Attack flow:

Flash loan 10,000 ETH from dYdX
Deposit 5,500 ETH as collateral on Compound → borrow 112 WBTC
Use remaining ETH to open a short position on Fulcrum
Manipulate price on Uniswap/Kyber
Realize profit from the short position
Repay flash loan, keep the profit

Case 2: PancakeBunny (2021, ~$45M)

A BSC-based protocol. PancakeSwap's spot price was used as the oracle, allowing BUNNY token price manipulation.

Root cause: The priceCalculator relied on a single block's AMM spot price. A flash loan momentarily distorted the price, enabling excessive BUNNY minting.

Case 3: Euler Finance (2023, ~$197M)

Combined a flash loan with donateToReserves(). Missing health factor validation allowed creation of an artificial liquidation state.

Attack flow:

Flash loan DAI from Aave
Deposit DAI into Euler → mint eDAI
Borrow additional DAI against eDAI (leverage)
Call donateToReserves() to donate eDAI to reserve → create undercollateralized state
Liquidate own position from a separate account → acquire collateral at a discount
Repay flash loan, keep the profit

Defense 1: TWAP Oracle

Use a Time-Weighted Average Price instead of a single block's spot price.

// Uniswap V3 TWAP Oracle
function consult(address pool, uint32 secondsAgo) external view returns (int24 arithmeticMeanTick) {
    uint32[] memory secondsAgos = new uint32[](2);
    secondsAgos[0] = secondsAgo;
    secondsAgos[1] = 0;

    (int56[] memory tickCumulatives, ) = IUniswapV3Pool(pool).observe(secondsAgos);

    arithmeticMeanTick = int24(
        (tickCumulatives[1] - tickCumulatives[0]) / int56(int32(secondsAgo))
    );
}

Defense 2: Chainlink Oracle

Use off-chain data feeds instead of on-chain DEX prices. Cannot be manipulated via flash loans.

import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

function getPrice() external view returns (uint256) {
    (, int256 price, , uint256 updatedAt, ) = priceFeed.latestRoundData();
    require(block.timestamp - updatedAt < 3600, "Stale price");
    return uint256(price);
}

Defense 3: Single-Transaction Restriction

mapping(address => uint256) private _lastActionBlock;

modifier noSameBlockAction() {
    require(_lastActionBlock[msg.sender] != block.number, "Same block");
    _lastActionBlock[msg.sender] = block.number;
    _;
}

Defense 4: Health Factor Validation

Always re-validate the health factor after state-changing functions.

function donateToReserves(uint256 amount) external {
    // ... donate logic ...
    require(getHealthFactor(msg.sender) >= MIN_HEALTH_FACTOR, "Unhealthy");
}

Checklist

[ ] Does the price oracle avoid relying on single-block spot prices?
[ ] Is a manipulation-resistant oracle (TWAP or Chainlink) in use?
[ ] Are price-dependent operations restricted within the same block?
[ ] Is the health factor re-validated after state changes?
[ ] Are there unintended state changes in flash loan callbacks?

Detecting These Issues with ContractScan

Semgrep's single-transaction-price-manipulation and unchecked-oracle-price rules, combined with AI analysis, detect flash loan vulnerability patterns.
→ ContractScan Free Scan

Try ContractScan free at contract-scanner.raccoonworld.xyz

How Access Control Mistakes Led to $1.4B in Losses

Heemin Kim — Fri, 10 Apr 2026 05:08:54 +0000

How Access Control Mistakes Led to $1.4B in Losses

As of 2025, the #1 loss category in smart contract security incidents is access control vulnerabilities. Three landmark cases alone — Poly Network, Ronin Bridge, and Nomad Bridge — account for over $1.4B in combined losses. These are not complex mathematical exploits — they stem from simply failing to verify "who can call this function."

What Is an Access Control Vulnerability?

Admin-only functions (mint, pause, upgrade, transfer ownership, etc.) that lack proper access controls, allowing anyone to call them.

Vulnerable Code

contract VulnerableToken {
    address public owner;

    // ⚠️ No onlyOwner check — anyone can mint
    function mint(address to, uint256 amount) external {
        _mint(to, amount);
    }

    // ⚠️ Initializer is unprotected
    function initialize(address _owner) external {
        owner = _owner;
    }
}

Case 1: Poly Network (2021, ~$611M)

The cross-chain relay's keeper change function was insufficiently protected, allowing the attacker to register themselves as a keeper and withdraw funds from all chains.

Root cause: verifyHeaderAndExecuteTx() allowed arbitrary contract calls through cross-chain message validation.

Source: Rekt News — Poly Network

Case 2: Ronin Bridge (2022, ~$625M)

Five out of nine validator private keys for Axie Infinity's Ronin Bridge were compromised. This exceeded the multisig threshold, enabling bridge fund withdrawal.

Root cause: Too few validators, some keys stored on shared infrastructure. Vulnerable to social engineering.

Source: Rekt News — Ronin

Case 3: Nomad Bridge (2022, ~$190M)

During an upgrade, the trusted root was initialized to 0x00. All messages were automatically treated as valid, allowing anyone to withdraw bridge funds.

Root cause: Incorrect parameters in the initialize() call set the Merkle root to zero.

Source: Rekt News — Nomad

Defense 1: Ownable Pattern

import "@openzeppelin/contracts/access/Ownable.sol";

contract SafeToken is Ownable {
    function mint(address to, uint256 amount) external onlyOwner {
        _mint(to, amount);
    }
}

Defense 2: Role-Based Access Control (RBAC)

import "@openzeppelin/contracts/access/AccessControl.sol";

contract SafeToken is AccessControl {
    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
        _mint(to, amount);
    }
}

Defense 3: Initializer Protection

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract SafeProxy is Initializable {
    function initialize(address _owner) external initializer {
        // initializer modifier prevents re-calling
        _transferOwnership(_owner);
    }
}

Defense 4: Timelock

Add a delay before admin function execution, giving the community time to detect and respond to malicious changes.

import "@openzeppelin/contracts/governance/TimelockController.sol";

Checklist

[ ] Do all admin/owner functions have access control modifiers?
[ ] Does initialize() use the initializer modifier?
[ ] Is the upgrade function (upgradeTo) protected?
[ ] Is multi-sig or a timelock applied?
[ ] Are private keys stored in a distributed manner?

Detecting These Issues with ContractScan

Slither's unprotected-upgrade and Semgrep's missing-access-control rules automatically detect missing access controls.
→ ContractScan Free Scan