---
title: "Serangan reentrancy"
description: "Serangan reentrancy memakai panggilan eksternal atau callback untuk masuk kembali ke logika kontrak saat state tidak konsisten. Artikel ini membahas jalur serangan, pertahanan, dan batas peninjauan."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Serangan reentrancy
> Hanya untuk tujuan edukasi; bukan nasihat investasi. Celah reentrancy dapat menyebabkan hilangnya aset kontrak secara cepat dan tidak dapat dipulihkan, dan tidak ada satu pertahanan atau audit yang membuktikan kontrak aman.
## Jawaban langsung
Serangan reentrancy dapat terjadi ketika logika kontrak membuat panggilan eksternal dan pihak yang dipanggil memanggil balik sebelum eksekusi awal selesai serta invariannya dipulihkan. Jika saldo, bagian, izin, atau harga lama masih terlihat, callback dapat mengulangi tindakan atau memengaruhi tindakan lain dengan state yang tidak konsisten.
Callback tidak harus masuk ke fungsi yang sama atau mentransfer mata uang native. Hook token, callback penerima NFT, panggilan vault atau strategi, dan callback flash loan dapat memindahkan kendali ke kode yang tidak tepercaya. Reentrancy dapat melintasi fungsi, kontrak, dan modul; reentrancy read-only juga dapat membuat protokol lain memakai nilai sementara.
## Cara kerja
Eksploitasi umum mengikuti urutan ini:
1. Penyerang memasuki fungsi yang mengubah state dan lolos pemeriksaan awal.
2. Kontrak rentan memanggil alamat, token, atau protokol sebelum menyelesaikan pembukuannya.
3. Kode penyerang memasuki kontrak awal atau kontrak terhubung saat state lama masih terlihat.
4. Panggilan bertingkat mengulangi dampak atau mengubah state bersama, lalu eksekusi kembali dengan invarian yang rusak.
Perpindahan kendali eksternal bisa jelas seperti low-level call, atau tersembunyi di balik transfer token, hook penerima, safe mint, adaptor strategi, atau antarmuka arbitrary call. Revert biasanya membatalkan call tree terkait, tetapi penyerang dapat menyusun rangkaian bertingkat yang berhasil dan kembali normal setelah mengambil nilai atau merusak pembukuan.
Pertahanan perlu berlapis:
- Terapkan checks-effects-interactions: validasi dahulu, catat semua dampak internal terkait, lalu berinteraksi eksternal paling akhir.
- Gunakan guard pada setiap entry point yang berbagi invarian terlindungi, bukan hanya fungsi dengan panggilan yang jelas.
- Pilih klaim yang ditarik penerima bila sesuai dan kurangi panggilan ke token, penerima, hook, proxy, serta integrasi yang tidak tepercaya.
- Tetapkan invarian lintas kontrak dan uji callback berbahaya, jalur lintas fungsi, multicall bertingkat, serta konsumen read-only.
- Gabungkan peninjauan implementasi dengan pemantauan, pause, dan respons insiden jika didukung desain.
## Contoh
Bayangkan vault yang mengirim nilai dan baru menghapus saldo pengguna setelah panggilan:
```solidity
function withdraw() external {
uint256 amount = balances[msg.sender];
require(amount > 0, "empty balance");
(bool ok, ) = msg.sender.call{value: amount}("");
require(ok, "transfer failed");
balances[msg.sender] = 0;
}
```
Penerima mendapat kendali saat `balances[msg.sender]` masih memuat jumlah lama. Fungsi penerimanya dapat memanggil `withdraw()` lagi, lolos pemeriksaan yang sama, dan meminta transfer tambahan. Memperbarui saldo sebelum panggilan menutup celah khusus ini; guard dapat menolak masuk bertingkat. Keduanya tidak membuktikan seluruh sistem aman karena entry point atau kontrak terhubung lain dapat membuka invarian belum selesai yang sama.
## Risiko
- Guard melindungi satu fungsi sementara fungsi lain membuka state yang sama.
- Urutan panggilan lokal benar, tetapi invarian lintas kontrak tetap tidak konsisten selama callback.
- Token, penerima, callback flash loan, atau adaptor strategi menjalankan kode eksternal tanpa diduga.
- Fungsi view menerbitkan harga atau kurs sementara yang dipakai protokol lain dalam transaksi yang sama.
- Upgrade, modul, atau perubahan layout storage melewati atau merusak kunci awal.
- Pengujian mencakup penarikan rekursif tetapi melewatkan jalur lintas fungsi, lintas kontrak, dan read-only.
Bagi pengguna, lencana audit atau reentrancy guard adalah bukti adanya kontrol, bukan jaminan. Upgrade, integrasi, dan tindakan darurat dengan hak istimewa dapat mengubah permukaan serangan. Batasi approval dan eksposur, verifikasi implementasi yang diterapkan, dan jangan menganggap kerugian dapat dibatalkan.
## Kesalahpahaman umum
- **Reentrancy hanya berarti mengulangi satu fungsi penarikan.** Serangan dapat masuk ke fungsi atau kontrak lain, atau menampilkan data tidak konsisten kepada pembaca.
- **Hanya transfer mata uang native yang memicu callback.** Standar token, hook penerima, dan integrasi protokol juga dapat menjalankan kode eksternal.
- **Guard atau checks-effects-interactions membuat kontrak aman.** Cakupan, semua entry point bersama, dan invarian lintas kontrak tetap perlu ditinjau.
- **Audit yang berhasil meniadakan reentrancy.** Audit memiliki batas; perubahan kemudian dan integrasi yang belum ditinjau dapat membuat jalur baru.
## Topik terkait
- [Smart contract](/id/crypto/smart-contract/)
- [Audit smart contract](/id/crypto/contract-audit/)
- [Ethereum Virtual Machine](/id/crypto/evm/)
- [ERC-1155](/id/crypto/erc1155/)
- [Standar vault ERC-4626](/id/crypto/erc4626-vault/)
## Sumber
- [Pertimbangan keamanan](https://docs.soliditylang.org/en/latest/security-considerations.html#reentrancy) - Solidity Documentation (diakses: 2026-08-21)
- [Keamanan smart contract](https://ethereum.org/developers/docs/smart-contracts/security/#reentrancy) - ethereum.org (diakses: 2026-08-21)
- [ReentrancyGuard](https://docs.openzeppelin.com/contracts/5.x/api/utils#ReentrancyGuard) - OpenZeppelin Documentation (diakses: 2026-08-21)
- [SC08:2026 Serangan reentrancy](https://scs.owasp.org/sctop10/SC08-ReentrancyAttacks/) - OWASP Smart Contract Security (diakses: 2026-08-21)
Source: https://wiki.fcontext.com/id/crypto/reentrancy-attack/index.mdx