---
title: "Attacco di rientranza"
description: "Un attacco di rientranza usa una chiamata esterna o un callback per rientrare nella logica di un contratto mentre lo stato è incoerente. Spiega percorsi, difese e limiti della revisione."
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.

# Attacco di rientranza

> Solo a scopo educativo; non costituisce consulenza finanziaria. Una vulnerabilità di rientranza può causare una perdita rapida e irreversibile degli asset del contratto, e nessuna singola difesa o verifica dimostra che un contratto sia sicuro.

<a id="answer"></a>

## Risposta diretta

Un attacco di rientranza può avvenire quando la logica di un contratto effettua una chiamata esterna e il destinatario richiama il contratto prima che l'esecuzione originale sia terminata e le invarianti siano ripristinate. Se restano visibili saldi, quote, permessi o prezzi obsoleti, il callback può ripetere un'azione o influenzarne un'altra usando uno stato incoerente.

Il callback non deve rientrare nella stessa funzione né trasferire valuta nativa. Hook dei token, callback dei destinatari NFT, chiamate a vault o strategie e callback di flash loan possono passare il controllo a codice non fidato. La rientranza può attraversare funzioni, contratti e moduli; quella di sola lettura può anche far usare a un altro protocollo un valore transitorio.

<a id="mechanism"></a>

## Come funziona

Un exploit tipico segue questa sequenza:

1. L'attaccante entra in una funzione che modifica lo stato e supera i controlli iniziali.
2. Il contratto vulnerabile chiama un indirizzo, token o protocollo prima di completare la contabilità.
3. Il codice controllato dall'attaccante entra nel contratto originale o collegato mentre il vecchio stato è ancora visibile.
4. La chiamata annidata ripete un effetto o cambia lo stato condiviso e l'esecuzione ritorna con un'invariante violata.

Il trasferimento esterno del controllo può essere esplicito, come una chiamata di basso livello, oppure nascosto dietro trasferimenti di token, hook del destinatario, mint sicuro, adattatori di strategia o interfacce di chiamata arbitraria. Un revert normalmente annulla l'albero di chiamate interessato, ma l'attaccante può costruire una sequenza annidata riuscita che ritorna normalmente dopo aver estratto valore o corrotto la contabilità.

Le difese devono essere stratificate:

- Applicare controlli-effetti-interazioni: prima validare, poi registrare tutti gli effetti interni rilevanti e infine interagire all'esterno.
- Usare una protezione su ogni punto di ingresso che condivide l'invariante protetta, non soltanto sulla funzione con la chiamata evidente.
- Preferire prelievi richiesti dal beneficiario quando appropriato e ridurre le chiamate a token, destinatari, hook, proxy e integrazioni non fidati.
- Definire invarianti tra contratti e testare callback malevoli, percorsi tra funzioni, multicall annidate e consumatori di sola lettura.
- Affiancare alla revisione dell'implementazione monitoraggio, pausa e risposta agli incidenti quando il design lo consente.

<a id="example"></a>

## Esempio

Si consideri un vault che invia valore e azzera il saldo dell'utente solo dopo la chiamata:

```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;
}
```

Il destinatario ottiene il controllo mentre `balances[msg.sender]` contiene ancora il vecchio importo. La funzione di ricezione può richiamare `withdraw()`, superare lo stesso controllo e richiedere un altro trasferimento. Aggiornare il saldo prima della chiamata chiude questa finestra; una protezione può respingere l'ingresso annidato. Nessuna modifica dimostra che l'intero sistema sia sicuro, perché un altro punto di ingresso o contratto collegato può esporre la stessa invariante incompleta.

<a id="risks"></a>

## Rischi

- Una protezione copre una funzione mentre un'altra espone lo stesso stato.
- L'ordine locale è corretto, ma un'invariante tra contratti rimane incoerente durante il callback.
- Un token, destinatario, callback di flash loan o adattatore di strategia esegue inaspettatamente codice esterno.
- Una funzione view pubblica un prezzo o tasso transitorio usato da un altro protocollo nella stessa transazione.
- Un upgrade, modulo o cambio del layout di storage aggira o corrompe il blocco originale.
- I test coprono il prelievo ricorsivo ma omettono percorsi tra funzioni, contratti e di sola lettura.

Per gli utenti, un badge di audit o una protezione dalla rientranza dimostra l'esistenza di un controllo, non offre una garanzia. Upgrade, integrazioni e azioni di emergenza privilegiate possono cambiare la superficie di attacco. Limitare approvazioni ed esposizione, verificare l'implementazione distribuita e non presumere che le perdite siano reversibili.

<a id="misconceptions"></a>

## Errori comuni

- **La rientranza significa solo ripetere una funzione di prelievo.** Può entrare in un'altra funzione o contratto, oppure esporre dati incoerenti a un lettore.
- **Solo i trasferimenti di valuta nativa attivano callback.** Standard dei token, hook dei destinatari e integrazioni possono eseguire codice esterno.
- **Una protezione o controlli-effetti-interazioni rende sicuro il contratto.** Ambito, punti di ingresso condivisi e invarianti tra contratti richiedono ancora revisione.
- **Un audit riuscito esclude la rientranza.** Gli audit hanno portata limitata; modifiche successive e integrazioni non verificate possono creare nuovi percorsi.

<a id="related"></a>

## Argomenti correlati

- [Smart contract](/it/crypto/smart-contract/)
- [Audit degli smart contract](/it/crypto/contract-audit/)
- [Ethereum Virtual Machine](/it/crypto/evm/)
- [ERC-1155](/it/crypto/erc1155/)
- [Standard vault ERC-4626](/it/crypto/erc4626-vault/)

<a id="sources"></a>

## Fonti

- [Considerazioni sulla sicurezza](https://docs.soliditylang.org/en/latest/security-considerations.html#reentrancy) - Solidity Documentation (consultato: 2026-08-21)
- [Sicurezza degli smart contract](https://ethereum.org/developers/docs/smart-contracts/security/#reentrancy) - ethereum.org (consultato: 2026-08-21)
- [ReentrancyGuard](https://docs.openzeppelin.com/contracts/5.x/api/utils#ReentrancyGuard) - OpenZeppelin Documentation (consultato: 2026-08-21)
- [SC08:2026 Attacchi di rientranza](https://scs.owasp.org/sctop10/SC08-ReentrancyAttacks/) - OWASP Smart Contract Security (consultato: 2026-08-21)

Source: https://wiki.fcontext.com/it/crypto/reentrancy-attack/index.mdx