---
title: "Attaques d'oracle"
description: "Une attaque d'oracle exploite des données externes manipulables, obsolètes, mal mises à l'échelle ou mal configurées afin qu'un protocole prête, émette, rembourse, règle ou liquide à une valeur dangereuse."
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.
# Attaques d'oracle
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Une attaque d'oracle exploite la frontière de confiance relative aux données d'un protocole afin qu'un prix, taux de change, indice, valeur liquidative ou indicateur d'état déclenche une action économiquement dangereuse. L'attaquant peut manipuler une plateforme peu liquide, compromettre des rapporteurs ou des clés, exploiter les règles d'agrégation ou de mise à jour, ou associer l'absence de contrôles du consommateur sur la fraîcheur, les unités, les bornes et la source de repli à des capitaux empruntés. Un flux obsolète ou mal configuré peut causer la même perte sans opérateur d'oracle malveillant ; l'analyse de l'incident doit donc distinguer le chemin d'attaque du mode de défaillance.
La comparaison déterminante ne consiste pas à savoir si un prix affiché a fortement varié. Il faut déterminer si le coût et le risque d'influencer la valeur exacte consommée par le contrat sont inférieurs à la valeur exécutable accessible par emprunt, émission, remboursement, règlement ou liquidation. La liquidité flash peut financer un parcours atomique, mais elle ne crée pas la frontière de confiance défaillante et n'est pas indispensable à son exploitation.
La valeur d'un oracle n'est pas non plus nécessairement un prix de marché exécutable. Chaque examen doit rattacher cette valeur à une chaîne, un bloc, une adresse de flux ou de pool, une orientation actif de base/actif coté, des décimales, un horodatage, une méthode d'agrégation, une taille de marché et une fonction consommatrice. Une signature valide prouve qui a communiqué les données selon un dispositif donné ; elle ne prouve pas à elle seule leur fraîcheur, l'indépendance des sources, la profondeur du marché ou leur justesse économique.
## Fonctionnement
1. Fixer le déploiement : chaîne, bloc, contrat et fonction consommateurs, contrats des actifs, proxy du flux ou pool, agrégateur, actifs de base et coté, décimales, administrateurs et état de la mise à niveau.
2. Cartographier l'intégralité du chemin de confiance depuis les plateformes, pools ou rapporteurs, à travers l'agrégation, les signatures, le proxy ou l'adaptateur et la source de repli, jusqu'à la logique consommatrice ; consigner les plateformes, opérateurs, clés et mécanismes de gouvernance communs plutôt que de compter des étiquettes comme sources indépendantes.
3. Reproduire exactement la lecture onchain : réponse, métadonnées du round, horodatage, confiance ou statut le cas échéant, normalisation décimale, inversion de la cotation, état du séquenceur et délai de grâce, ancienneté maximale, bornes de déviation et traitement des valeurs nulles ou négatives.
4. Construire le registre d'exposition du consommateur : facteur de garantie, seuil de liquidation, plafonds d'emprunt et d'apport, liquidité disponible, dette, limites d'émission ou de remboursement, close factor, prime de liquidation et chaque action autorisée par la valeur.
5. Modéliser la manipulation à une taille exécutable à partir des réserves, de la liquidité active, des observations, de la fenêtre et de la convention de pondération, des frais, de l'arbitrage, de l'ordonnancement des blocs, du capital flash ou propre, des pertes de débouclage, du gas, du MEV et des liquidateurs concurrents.
6. Tester les contrôles et états de défaillance : sources indépendantes, cardinalité du TWAP, plafonds, coupe-circuits, pouvoir de pause, timelocks, source de repli obsolète ou divergente, perte de rapporteur ou de clé, indisponibilité du séquenceur L2, sauts de prix légitimes et comportement fail-open ou fail-closed.
7. Surveiller et rapprocher les rounds canoniques, les changements de proxy et de configuration, la divergence des sources, les actions du protocole, les liquidations, les créances irrécouvrables et les décisions de pause et de reprise ; répéter l'analyse après toute évolution de la liquidité, du référencement, du logiciel ou du régime de marché.
Une lecture spot d'un AMM peut souvent être modifiée au sein d'une seule transaction. Une moyenne pondérée dans le temps peut relever le coût en imposant une influence sur plusieurs observations, mais sa sécurité dépend de la convention arithmétique ou fondée sur les ticks, de la fenêtre, de la cardinalité des observations, de la répartition de la liquidité et du contrôle des blocs. Une médiane peut écarter certains points aberrants, mais des plateformes sources corrélées ou une perte de quorum peuvent toujours compromettre la sécurité ou la disponibilité. Les paramètres de heartbeat et de déviation régissent la publication de certains flux ; les consommateurs doivent néanmoins appliquer leur propre politique de fraîcheur et de validité.
## Exemples détaillés
- **Spot à produit constant.** Ignorons les frais dans un pool contenant `1,000,000 ABC` et `1,000,000 USDC`, si bien que `k = 10^12`. Un prix marginal cible de `9 USDC/ABC` exige des réserves de `3,000,000 USDC` et `333,333.333333 ABC` : l'opérateur apporte `2,000,000 USDC` et reçoit `666,666.666667 ABC`. Le prix marginal final est `3,000,000 / 333,333.333333 = 9`, tandis que le prix d'exécution moyen est `2,000,000 / 666,666.666667 = 3 USDC/ABC`. En revanche, un apport de `5,000,000 USDC` laisse des réserves de `6,000,000` et `166,666.666667`, ce qui produit un prix marginal de `36`, et non de `9`. Les frais réels, l'arbitrage, la liquidité concentrée et le débouclage modifient le registre.
- **Convention du TWAP.** Sur dix observations égales d'une minute, neuf prix valent `100` et un vaut `160`. Le TWAP arithmétique pédagogique est `(9 * 100 + 160) / 10 = 106`, soit seulement `6%` au-dessus de 100 alors que le dernier spot est supérieur de `60%`. Pour porter cette moyenne arithmétique à `130` en conservant les neuf autres observations à 100, l'observation manipulée doit valoir `400`. La moyenne des ticks d'Uniswap v3 est géométrique, contrairement à cet exemple arithmétique ; le consommateur doit reproduire la convention effectivement déployée.
- **Médiane et quorum.** Sept observations normalisées sont `[99, 100, 100, 101, 101, 500, 600]` ; leur médiane vaut `101`, de sorte que deux rapports extrêmes ne déplacent pas le résultat hors du groupe honnête. Si l'acceptation exige cinq rapports actifs et que trois rapporteurs honnêtes sont hors ligne, il n'en reste que `4 < 5` : la résistance aux valeurs aberrantes ne garantit pas la disponibilité, et le comportement de repli entre dans le modèle de sécurité.
- **Obsolescence et liquidation injustifiée.** Un flux à huit décimales renvoie la valeur brute `140,000,000,000`, soit `1,400`, mais elle date de `17 minutes` alors que le consommateur fixe un maximum de `15 minutes` ; elle doit donc être rejetée. Si cette valeur obsolète est néanmoins utilisée pour `10 ETH`, avec un seuil de liquidation de `75%` et une dette de `12,000`, le facteur de santé vaut `10 * 1,400 * 0.75 / 12,000 = 0.875` ; avec un prix frais de `2,000`, il vaut `1.25`. Une correction ultérieure du prix n'annule pas une liquidation déjà exécutée.
## Risques
- Chaîne, actif, flux, proxy, pool ou adresse du consommateur incorrects.
- Actifs de base et coté inversés ou unité de cotation incohérente.
- Mauvaise normalisation des décimales du flux, du token et du format fixe interne.
- Acceptation de données obsolètes ou confusion entre déclencheurs heartbeat/déviation et garanties de fraîcheur.
- Acceptation de rounds incomplets, d'un statut invalide ou de réponses nulles, négatives, plafonnées ou hors bornes.
- Le prix spot d'une seule plateforme peu liquide contrôle une forte exposition du protocole.
- Fenêtre TWAP trop courte, clairsemée, mal pondérée ou lue dans le mauvais sens.
- Cardinalité, initialisation, interpolation ou comportement de repli des observations mal compris.
- La liquidité concentrée ou just-in-time fait que la valeur nominale du pool représente mal le coût de l'attaque.
- Plusieurs flux partagent plateformes, fournisseurs, opérateurs, clés ou plan de contrôle.
- La défaillance d'un rapporteur, d'une plateforme, d'une API, d'un signataire, du réseau ou du quorum supprime fraîcheur ou intégrité.
- Indisponibilité du séquenceur L2 ou délai de grâce après reprise absent ou incorrect.
- Source de repli obsolète, circulaire, corrélée, différemment mise à l'échelle ou sémantiquement incompatible.
- La liquidité flash et la composabilité atomique rendent une influence temporaire économiquement exploitable.
- L'ordonnancement des mises à jour, le frontrunning, le sandwich, le backrunning ou le MEV de liquidation modifie les paiements.
- Facteurs de garantie, seuils, plafonds, primes et liquidité disponible amplifient une petite erreur.
- La compromission de la gouvernance, d'un administrateur, d'un guardian, d'un multisig ou d'une clé de signature modifie le chemin de confiance.
- Des erreurs de proxy, d'agrégateur, d'adaptateur, de mise à niveau, de stockage ou de configuration sélectionnent la mauvaise valeur.
- Des coupe-circuits ou une logique fail-closed bloquent des emprunts, remboursements ou liquidations légitimes en période de crise.
- La pause, la reprise, le rapprochement des comptes, l'affectation des créances irrécouvrables ou le confinement entre protocoles échoue.
## Idées reçues
- **« Toute attaque d'oracle compromet le réseau d'oracles. »** De nombreuses défaillances exploitent une source peu liquide, une valeur obsolète, des unités erronées, un adaptateur dangereux ou la logique consommatrice alors que le réseau de rapport fonctionne conformément à sa configuration.
- **« Plusieurs flux, ou des flux décentralisés, garantissent un prix correct. »** L'indépendance, la qualité des sources, le quorum, la fraîcheur, les unités, l'agrégation et les contrôles du consommateur restent nécessaires.
- **« Un TWAP rend la manipulation impossible. »** Il en modifie la durée et le coût ; une fenêtre faible, des observations rares, une liquidité réduite ou le contrôle des blocs peuvent rester exploitables.
- **« Interdire les flash loans supprime le risque d'oracle. »** Les flash loans ne sont qu'un mode de financement. Les fonds propres, le crédit, les emprunts interprotocoles, la compromission des rapporteurs et les erreurs de configuration demeurent.
- **« Le retour du prix annule les dommages. »** Les emprunts, émissions, remboursements, règlements et liquidations canoniques persistent, sauf si le protocole dispose d'un processus de récupération distinct et autorisé.
## Thèmes associés
- [Oracle](/fr/crypto/oracle/)
- [Protocole de prêt](/fr/crypto/lending-protocol/)
- [Liquidation](/fr/crypto/liquidation/)
## Sources
- [SC03:2026 Price Oracle Manipulation](https://scs.owasp.org/sctop10/SC03-PriceOracleManipulation/) - OWASP Smart Contract Security (consulté le 2026-08-13)
- [Chainlink Data Feeds](https://docs.chain.link/data-feeds) - Chainlink Documentation (consulté le 2026-08-13)
- [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference) - Chainlink Documentation (consulté le 2026-08-13)
- [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) - Chainlink Documentation (consulté le 2026-08-13)
- [Uniswap v2 Core](https://app.uniswap.org/whitepaper.pdf) - Uniswap Labs (consulté le 2026-08-13)
- [Price Oracles](https://developers.uniswap.org/docs/protocols/v3/concepts/price-oracles) - Uniswap Developers (consulté le 2026-08-13)
- [Oracles](https://aave.com/docs/aave-v3/smart-contracts/oracles) - Aave Protocol Documentation (consulté le 2026-08-13)
- [Flash Loans](https://aave.com/docs/aave-v3/guides/flash-loans) - Aave Protocol Documentation (consulté le 2026-08-13)
Source: https://wiki.fcontext.com/fr/crypto/oracle-attack/index.mdx