Ce que dit l’avis, et ce qu’il ne dit pas

Selon l’avis signé Manish Goregaokar pour le Rust Security Response Team, Miri doit conserver certaines variables d’environnement d’un appel à l’autre pour rejouer correctement les builds. Il les écrivait donc toutes dans target/. Le correctif réduit la liste aux variables CARGO_* (hors CARGO_*_TOKEN) et à OUT_DIR.

Vous êtes concerné si vous cumulez trois choses : cargo miri en CI, des secrets exposés en variables d’environnement aux étapes qui le lancent, et un cache de target/ accessible aux pull requests. L’avis ne mentionne pas de CVE, et précise qu’un dépôt a été confirmé vulnérable, sept autres appelant à la prudence. Ce n’est donc pas une catastrophe à grande échelle. Les mesures immédiates recommandées sont de désactiver le cache sur les jobs concernés, de restreindre les secrets aux seules étapes qui en ont besoin, de vider les caches existants et de faire tourner les secrets qui ont pu fuiter.

Je retiens la nature du défaut : aucun exploit sophistiqué. Un outil écrit trop de choses sur disque, et un cache est relu par un contexte moins fiable que celui qui l’a écrit.

Pourquoi le cache est un canal de fuite

La documentation GitHub est explicite. Un run de workflow peut restaurer un cache créé sur sa branche ou sur la branche par défaut, et, pour une pull request, sur la branche de base. La documentation ajoute : « Don’t store sensitive information in a cache. Anyone who can open a pull request against your repository can read the contents of caches in the base branch. » Elle précise aussi que le contenu d’un cache n’est ni signé ni vérifié.

Le raisonnement à garder est donc le suivant : tout ce qui est écrit dans un chemin mis en cache doit être considéré comme lisible par quiconque peut ouvrir une PR. Le problème n’est pas de stocker un secret volontairement (personne ne le fait), mais qu’un outil l’écrive à votre place. Un projet public a d’ailleurs réagi à l’avis en coupant l’enregistrement du cache Rust sur ses builds de release, qui portent des clés de signature, comme le décrit cette pull request : son auteur y explique que Cargo sérialise la valeur des variables déclarées par cargo:rerun-if-env-changed dans target/. Je n’ai pas vérifié ce point dans la documentation de Cargo, prenez-le comme un témoignage de mainteneur.

Le même schéma dans un projet PHP

Sur les pipelines PHP que j’ai rencontrés, la configuration typique met en cache le dossier de cache de Composer (~/.cache/composer sur les runners Ubuntu) ou le dossier vendor/, quelquefois le dossier du projet entier pour gagner du temps. Le cache Composer contient des archives de paquets, ce qui est sans risque. Le reste dépend de ce que le job a écrit avant.

Un exemple concret côté Symfony : la commande composer dump-env prod, recommandée pour la production, compile les fichiers .env* en un .env.local.php. Les variables réellement présentes dans l’environnement n’y sont pas copiées, elles restent lues à l’exécution. En revanche, si la CI écrit des secrets dans un .env.prod.local avant le dump, ils se retrouvent en clair dans le fichier généré. Et si ce fichier atterrit dans un chemin mis en cache, vous venez de recréer le défaut de Miri avec un autre outil. Le même raisonnement s’applique à tout fichier de configuration généré, à un docker buildx qui met en cache des couches, ou à un dossier var/cache réchauffé avec des paramètres sensibles.

La règle : séparer les jobs qui écrivent des caches de ceux qui portent des secrets

GitHub a d’ailleurs commencé à durcir la plateforme de son côté. Depuis le 26 juin 2026, les événements qui peuvent être déclenchés sans droit d’écriture sur le dépôt (pull_request_target, issue_comment, les cascades workflow_run issues d’une PR de fork) reçoivent un jeton de cache en lecture seule quand ils s’exécutent sur la branche par défaut. Les événements push, schedule ou workflow_dispatch gardent la lecture et l’écriture, et pull_request aussi. Le 10 septembre, GitHub a ajouté un réglage cache-mode qui fixe l’accès au cache au niveau du workflow ou du job : read, write, write-only ou none, le réglage du job l’emportant sur celui du workflow. Pour un job de déploiement, none est la valeur naturelle ; la syntaxe exacte est dans la documentation des workflows.

Cela protège contre l’empoisonnement de cache par un tiers, pas contre l’écriture involontaire d’un secret par un outil de confiance. La discipline reste à vous. Voici la structure que je recommande : un job de construction qui écrit le cache sans aucun secret, un job de déploiement qui n’écrit aucun cache.

name: ci
on: [push, pull_request]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    # aucun secret ici : ce job lit et écrit le cache
    steps:
      - uses: actions/checkout@v6
      - id: composer-cache
        run: echo "dir=$(composer config cache-files-dir)" >> "$GITHUB_OUTPUT"
      - uses: actions/cache@v5
        with:
          path: ${{ steps.composer-cache.outputs.dir }}
          key: composer-${{ hashFiles('composer.lock') }}
      - run: composer install --no-interaction
      - run: vendor/bin/phpunit

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v6
      - run: ./bin/deploy
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Les numéros de version des actions ci-dessus sont là pour la lisibilité : épinglez celles que vous utilisez réellement, idéalement par empreinte de commit. Ce qui compte est la séparation : le secret n’existe que dans une étape du job deploy, qui ne restaure ni n’enregistre aucun cache.

Audit d’un pipeline en 30 minutes

La liste qui suit tient en une demi-heure sur un dépôt de taille moyenne. C’est celle que je déroule en premier sur une base que je découvre.

1. Listez tous les usages de cache : grep -rn "actions/cache\|cache:" .github/workflows/, sans oublier les options de cache des actions setup-*.
2. Pour chaque cache, notez le chemin et demandez-vous quels outils ont écrit dedans avant la sauvegarde.
3. Listez tous les secrets : grep -rn "secrets\." .github/workflows/, et dites pour chacun quel job et quelle étape le voit.
4. Repérez les secrets déclarés au niveau du workflow ou du job (env:) plutôt que de l’étape. Descendez-les à l’étape.
5. Repérez les jobs qui cumulent cache en écriture et secret. C’est le cas à corriger en priorité.
6. Pour les projets Rust, vérifiez si cargo miri tourne quelque part, et si target/ est mis en cache.
7. Si un doute existe sur un secret passé dans un job qui écrivait un cache : videz le cache, puis faites tourner le secret. Le vider ne suffit pas si quelqu’un a pu le lire entre-temps.

Les limites

Cette règle a un coût. Séparer les jobs peut allonger un pipeline, et un job de déploiement sans cache repart de zéro sur ses dépendances. Sur un projet où le déploiement est court, c’est négligeable. Sur un build qui a besoin d’un secret pour récupérer des dépendances privées (un jeton de registre Composer privé, par exemple), la séparation demande un peu d’ingénierie : le jeton est nécessaire pendant l’installation, donc pendant l’écriture du cache. Dans ce cas, vérifiez que le jeton n’est pas écrit dans un chemin mis en cache (un fichier auth.json dans le dossier de Composer, par exemple) et préférez un jeton à portée minimale, en lecture seule.

Ensuite, l’avis Miri concerne un cas précis, et il est corrigé. Si vous ne lancez pas Miri, l’article ne prétend pas que votre pipeline fuit. Il dit qu’un pipeline dont vous n’avez jamais listé les secrets et les caches est un pipeline dont vous ne savez pas s’il fuit. Enfin, je n’ai pas reproduit la fuite pour cet article : je m’appuie sur l’avis de l’équipe Rust et sur la documentation de GitHub.

Concrètement, par où commencer

1. Dès cette semaine, exécutez les deux grep de la section précédente et dressez un tableau job, cache, secrets.
2. Corrigez d’abord le cas le plus grave : un job qui écrit un cache et voit un secret de déploiement ou de signature.
3. Si vous utilisez Miri, mettez à jour la nightly et vérifiez la date de vos caches existants ; en cas de doute, videz-les et faites tourner les secrets concernés.
4. Ajoutez au dépôt une note de trois lignes qui énonce la règle, pour qu’elle survive au prochain changement de mainteneur.
5. Relisez la question de fond avec votre équipe : qui, aujourd’hui, peut ouvrir une PR sur vos dépôts, et qu’est-ce que votre CI lui permet de lire ?

Sur la plupart des audits de CI, ce qui m’a surpris n’est pas la sophistication d’une faille, c’est la quantité de secrets visibles par des jobs qui n’en avaient pas besoin.

Sources

• GitHub Actions leaking secrets when Miri output is cached, Rust Blog, 21 septembre 2026
• Dependency caching reference, GitHub Docs, consulté le 29 septembre 2026
• Read-only Actions cache for untrusted triggers, GitHub Changelog, 26 juin 2026
• Control GitHub Actions cache access with cache-mode, GitHub Changelog, 10 septembre 2026
• Keep credentials out of cached directories, and audit the org against the miri cache disclosure, pull request 11517, unslothai/unsloth, consultée le 29 septembre 2026

Ma thèse est simple : l’outbox natif transforme un pattern qu’on écrivait à la main, souvent de travers, en quelques lignes de configuration. C’est l’un des chantiers à meilleur rendement d’une montée vers 8.2, à condition de comprendre ce qu’il garantit et ce qu’il ne garantit pas.

Le bug qui n’apparaît qu’en production

Le scénario est banal. Un contrôleur ou un handler enregistre une commande en base, puis dispatche un message vers RabbitMQ ou SQS pour prévenir le reste du système. Deux écritures, deux systèmes, aucune transaction commune.

Deux échecs sont possibles. Si la transaction est annulée après l’envoi du message, le broker transporte l’annonce d’un fait qui n’a pas eu lieu. Si le broker est indisponible au moment de l’envoi, la donnée est enregistrée mais personne n’en est informé. Dans les deux cas, rien ne casse bruyamment : les systèmes divergent en silence et quelqu’un finit par réconcilier à la main.

Sur les migrations que j’ai menées, cet endroit existe presque toujours quelque part dans le monolithe : un « on enregistre, puis on envoie » sans filet. Ça marche la plupart du temps, ce qui est exactement ce qui le rend dangereux.

Ce que l’outbox de Messenger 8.2 fait concrètement

Le principe est celui du transactional outbox. Le message n’est pas envoyé au broker : il est écrit en base, dans la même transaction que vos données métier. Un worker dédié, le relais, lit ensuite ces messages stockés et les transmet au vrai broker. Les consommateurs, eux, lisent le broker comme avant.

Selon l’article du blog Symfony, la configuration se réduit à une option sur le transport :

# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            orders:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                # les messages envoyés vers "orders" passent d'abord par "db_outbox"
                outbox: db_outbox

            db_outbox: 'doctrine://default?queue_name=outbox'

Et deux workers à faire tourner :

# le relais : transmet les messages stockés vers "orders" (il n'exécute aucun handler)
php bin/console messenger:consume db_outbox

# traite les messages de "orders" comme d'habitude
php bin/console messenger:consume orders

Le point important est que votre code applicatif ne change pas. Vous dispatchez toujours le même message sur le même bus, dans votre transaction Doctrine ; c’est le transport qui fait la différence. Le gain de migration est là : le pattern se déploie sans réécrire les handlers, message par message si vous le souhaitez.

Les contraintes à lire avant d’activer

L’article est net sur les limites, et elles comptent plus que la configuration.

• L’outbox doit être un transport Doctrine utilisant la même connexion que votre application. C’est ce qui rend l’écriture atomique ; si vos données métier vivent dans une autre base ou une autre connexion, la garantie disparaît.
• L’ordre des messages n’est pas garanti pendant la transmission. Pour un flux où « commande créée » doit précéder « commande payée », ce n’est pas un détail.
• Le délai d’un message s’applique pendant son attente dans l’outbox ; une fois transmis, il n’a plus de délai.
• Si la transmission échoue, c’est la stratégie de retry et le failure transport de l’outbox qui s’appliquent. Si le traitement échoue, les nouvelles tentatives repartent directement vers le transport cible, car le message est déjà passé par l’outbox.

Ce dernier point mérite une vérification en préproduction : vous aurez désormais deux endroits où un message peut échouer, avec deux stratégies de reprise. Il faut savoir, avant l’incident, lequel des deux failure transports regarder.

Un corollaire que l’article ne développe pas et qui relève du pattern lui-même : une livraison fiable de ce type est de l’ordre de « au moins une fois ». Vos consommateurs doivent donc tolérer de recevoir deux fois le même message. Si ce n’est pas le cas aujourd’hui, l’outbox rend le sujet visible, ce qui n’est pas plus mal, mais il faut le traiter.

Le claim check, pour les messages trop gros

La seconde nouveauté répond à un autre problème : les brokers limitent la taille des messages. Avec le claim check, un message dont la taille encodée (corps et en-têtes) dépasse un seuil est stocké dans un pool de cache, et seule une référence (un identifiant aléatoire et une somme de contrôle) est envoyée.

framework:
    cache:
        pools:
            # un pool dédié, accessible aux producteurs et aux consommateurs
            messenger.claim_check.cache:
                adapter: cache.adapter.redis
                # les claims ne sont supprimés qu'à l'expiration
                default_lifetime: 604_800 # 7 jours

    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                claim_check:
                    cache_pool: messenger.claim_check.cache
                    # gardez une marge sous la limite de votre broker
                    max_size: 200_000

Le piège tient en une phrase de la documentation : le pool de cache fait désormais partie de la livraison des messages. Ne le partagez pas avec le cache applicatif, car un cache:clear ferait disparaître des messages en attente. Réglez default_lifetime au-delà de la durée de vie réelle d’un message, retries et attente dans le failure transport compris. Un claim expiré produit une ClaimCheckNotFoundException, encapsulée dans une MessageDecodingFailedException, qui suit le chemin habituel de retry et de failure transport.

Sur un legacy, je vois deux cas d’usage : les exports ou synthèses volumineux qu’on poussait dans un message faute de mieux, et les payloads qui ont grossi au fil des ans jusqu’à frôler la limite du broker.

Pourquoi c’est un chantier de migration, pas seulement une amélioration

Une migration progressive, de type strangler, crée mécaniquement une couture : l’ancien monolithe d’un côté, les nouveaux services de l’autre, et des messages entre les deux. C’est là que la double écriture fait le plus de dégâts, parce que chaque incohérence est difficile à attribuer : l’ancien code, le nouveau, ou le transport ?

Mon avis est qu’il faut sécuriser cette couture avant de déplacer de la logique métier au-delà. Un outbox en place fait de la couture un point fixe : ce qui est en base est ce qui sera publié, et l’on peut, en cas de doute, compter les lignes de la table d’outbox plutôt que fouiller des logs de broker.

Je commencerais par les messages critiques (paiement, facturation, changement de statut de commande) et non par tout le bus d’un coup. Chaque transport a sa propre option outbox, ce qui permet cette progression.

Les limites

L’outbox n’est pas gratuit. Vous ajoutez une table qui grossit, un worker de plus à superviser, et de la latence : un message passe par la base avant d’atteindre le broker. Pour un flux où la milliseconde compte, ce n’est peut-être pas le bon compromis.

L’absence de garantie d’ordre est la limite la plus sérieuse. Si votre métier dépend d’une séquence stricte pour un même agrégat, il faudra soit rendre les consommateurs tolérants au désordre, soit trouver une autre approche. Je n’ai pas vu, dans l’article, de mécanisme de partitionnement ; je ne prétends donc pas que ce cas soit couvert.

Il existe aussi des alternatives plus lourdes, comme la capture des changements directement dans le journal de la base, qui évitent d’écrire dans une table d’outbox. Elles demandent une infrastructure que la plupart des équipes avec un monolithe historique n’ont pas, et je les réserverais aux cas où le volume l’impose.

Enfin, tout cela suppose Symfony 8.2. Sur une application encore en 6.4 ou 7.4, le pattern reste faisable à la main, mais l’argument « une ligne de configuration » ne tient plus. C’est une raison de plus de planifier la montée de version.

Concrètement, par où commencer

1. Repérez dans votre code les endroits où un flush() ou un commit est suivi d’un dispatch vers un broker. Une recherche sur le bus de messages suffit pour un premier inventaire.
2. Classez ces messages par criticité. Les paiements et la facturation d’abord.
3. Vérifiez que vos consommateurs supportent un message reçu deux fois, et un message reçu dans le désordre. C’est le vrai pré-requis, plus que la version de Symfony.
4. Sur un environnement de préproduction, activez l’outbox sur un seul transport, faites tourner le relais et provoquez des pannes du broker. Observez où atterrissent les échecs.
5. Décidez qui surveille la table d’outbox et le relais : une alerte sur l’ancienneté du plus vieux message non transmis est un bon indicateur.

Si vous préparez une montée vers 8.2 sur une application ancienne, cet inventaire des écritures doubles est un bon premier jalon : il livre de la fiabilité avant même que la migration ne commence, et cette valeur-là se voit tout de suite.

Sources

• New in Symfony 8.2: Messenger Outbox and Claim Check : Symfony Blog, 21 septembre 2026
• A Week of Symfony #1030 (21–27 septembre 2026) : Symfony Blog, 27 septembre 2026