Les scripts p0_*.sh et un fichier .s3w étaient encore sur le disque
(seule la référence dans .gitconfig avait été nettoyée le 09-22).
Repéré en vérifiant une alerte Gitea sans rapport sur elevenbook
("hooks broken", finalement bénigne). IOC désormais absents du volume,
pas de réinfection, aucun process malveillant actif.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
INTERNAL_TOKEN est le bon périmètre d'authentification pour cet endpoint,
pas l'adresse réseau — une restriction reverse-proxy serait redondante.
Le token a de toute façon été roté, ce qui referme ce point.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Backup complet (dump SQL + volume) avant upgrade
- Documente l'incident secondaire (502 temporaire sur git.sans.pub) causé
par un payload appDefinitions/update incomplet ayant réinitialisé
containerHttpPort à sa valeur par défaut, et le correctif appliqué
- Ajoute un avertissement dans CLAUDE.md : cette API remplace la config,
ne la fusionne pas
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- INTERNAL_TOKEN, LFS_JWT_SECRET et mot de passe MySQL rotés le 2026-09-23
- DB_PASSWD CapRover resynchronisé, service redémarré et vérifié
- Confirmation que les env vars CapRover de l'app gitea (DB_PASSWD etc.)
ne sont pas au format GITEA__section__clé donc inertes pour app.ini
- Documentation de l'installation/usage du CLI caprover via fnm
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Incident du 2026-09-14 : injection de packObjectsHook via l'API interne
Gitea pour déployer un mineur Monero (XMRig). Contenu et nettoyé le
2026-09-22. Voir incidents/2026-09-14-gitea-cryptominer.md pour le détail
complet (analyse, IOC, remédiation, reste à faire).
Ajout également des détails techniques sur le setup Gitea (containers,
volumes, réseau) découverts pendant l'investigation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pierre MartinandClaude Sonnet 5