Gitea a publié la version 1.27.3 le 29 août 2026 à 17h42 UTC, taguée « Latest » sur le dépôt GitHub du projet, à partir d’un commit signé et vérifié, fusionné par le mainteneur lunny via le compte GiteaBot. Rien d’exceptionnel en soi. Ce qui rend cette sortie intéressante, c’est la section SECURITY de son changelog, qui s’étend sur 18 correctifs distincts, aucun d’entre eux ne portant d’identifiant CVE dédié.
C’est une tout autre forme de publication que celle que nous avions couverte le 10 août, quand la version 1.27.1 corrigeait deux vulnérabilités nommées et numérotées : CVE-2026-59774, une lecture de fichier non authentifiée, et CVE-2026-60004, une exécution de code à distance via le traitement des diffpatch, que la CISA a ensuite confirmé être exploitée activement. Cette fois, pas de faille unique qui fait la une. Les mainteneurs de Gitea sont plutôt passés au peigne fin sur toute la couche de contrôle d’accès et ont refermé 18 brèches distinctes en une seule fois.
Ce que ferment réellement les 18 correctifs
En parcourant la liste, un schéma se dégage vite : presque chaque correctif restreint qui peut accéder à quoi. Un lot de cinq pull requests distinctes, fusionnées ensemble sous un seul correctif « packages », restreint l’accès aux paquets et resserre la portée des jetons d’API. Les pièces jointes appliquent désormais le chemin du dépôt propriétaire au lieu de faire confiance à n’importe quel chemin fourni par une requête. Le rendu du balisage dans les tickets impose maintenant un accès au même dépôt. Actions vérifie les signatures des artefacts avant de les utiliser en clair, plutôt qu’après.
- Les utilisateurs à accès limité sont désormais masqués des comptes restreints dans l’API, comblant un écart d’information entre les paliers de compte.
- Le choix du modèle .gitignore est désormais restreint à un ensemble défini plutôt que d’accepter une entrée arbitraire.
- Le sondage de version GitLab pendant les migrations est désactivé, supprimant une voie d’abus possible contre des serveurs tiers.
- Les manifestes de paquets Swift, les téléversements de sommes de contrôle Maven et les métadonnées de paquets Alpine sont désormais limités en taille ou en format.
- Les réponses de version OneDev pendant les migrations sont restreintes de la même façon.
- Actions applique désormais des limites de confiance pour les pull requests venant de forks, pour qu’une PR forkée ne puisse pas s’exécuter avec plus de confiance qu’elle ne le devrait.
- Les permissions des hooks Git sont restreintes.
- La création de dépôt via l’API exige désormais une autorisation de jeton en bonne et due forme.
- Le point d’accès API de comparaison des HEAD est limité aux dépôts publics uniquement.
- Les dépôts appartenant à des comptes masqués ne sont plus exposés.
- Un correctif referme une voie qui permettait d’énumérer tous les dépôts publics via la recherche de tickets, ce qui n’a jamais été censé constituer une liste complète des dépôts.
- Plusieurs points d’accès privés ont été refactorisés dans le cadre de ce nettoyage.
Pris isolément, la plupart de ces changements ressemblent à de petits ajustements de permissions. Mis bout à bout, ils couvrent les paquets, les pièces jointes, Actions, les migrations, la visibilité des dépôts et quasiment toute la couche API. C’est beaucoup de terrain pour une seule version, et ça ressemble moins à un correctif pour un bug isolé signalé qu’à un vrai audit de la façon dont Gitea décide qui a le droit de voir et de toucher quoi.
Pourquoi aucun de ces correctifs n’a de numéro CVE
Autant être clair sur ce que « pas de CVE » indique et n’indique pas. Un identifiant CVE apparaît généralement quand une faille est signalée de l’extérieur, via un programme de bug bounty, la divulgation d’un chercheur, ou un audit de sécurité avec un signalement formel. L’absence de numéro CVE sur les 18 correctifs pointe dans l’autre sens : une revue interne, pas une divulgation externe. Rien dans les notes de version ne suggère qu’une de ces failles ait été surprise en cours d’exploitation.
C’est une raison légitime de se sentir plutôt rassuré. Mais les zones touchées, la portée de l’API des paquets, les chemins des pièces jointes, les réponses de comparaison des HEAD, l’énumération des dépôts, sont exactement le genre de trous de contrôle d’accès qui comptent le plus sur les instances multi-utilisateurs, ou partout où des dépôts privés côtoient des dépôts publics. Un passage de durcissement interne et discret mérite quand même d’être appliqué rapidement si votre instance Gitea compte plus d’une personne avec un compte.
Les nouveautés et le reste des correctifs de bugs
En dehors de la sécurité, la 1.27.3 ajoute une seule amélioration : des liens permanents sur les revues de pull request, qui permettent désormais de pointer directement vers une revue précise au lieu de faire défiler la page pour la retrouver. La section BUGFIXES est longue et essentiellement routinière : comportement d’Actions, gestionnaire de paquets Swift Registry, cas limites des migrations, vérification des signatures OpenPGP, et le suivi de l’état des pull requests fusionnées. Rien de tout cela ne change votre façon d’exploiter le serveur au quotidien.
La troisième alerte sécurité Gitea en trois semaines
Si vous comptez les points, c’est la troisième fois que la sécurité de Gitea fait l’actualité ici depuis début août. D’abord le correctif 1.27.1 pour CVE-2026-59774 et CVE-2026-60004, puis l’annonce, publiée le même jour que cette version, que la CISA avait confirmé l’exploitation active de cette faille RCE. Aucun des deux articles précédents ne couvre les nouveautés de la 1.27.3 ; si vous ne les avez pas encore lus, ils valent le détour pour comprendre ce qui avait déjà été corrigé en juillet et pourquoi la faille RCE en particulier méritait l’urgence.
Trois versions liées à la sécurité en trois semaines ne signifie pas forcément que quelque chose est plus cassé que d’habitude. Ça pourrait simplement vouloir dire que les mainteneurs sont en ce moment plus attentifs, ce qui, après un événement d’exploitation active confirmée, est exactement ce qu’on souhaite voir.
Faut-il mettre à jour
Oui, et il n’y a pas vraiment de raison d’attendre. Aucun de ces 18 correctifs n’est signalé comme activement exploité, donc ce n’est pas une situation d’urgence à corriger ce soir comme l’était la faille RCE. Mais l’étendue de ce qui est couvert, en particulier les correctifs sur l’API des paquets, la gestion des chemins de pièces jointes et l’énumération des dépôts, justifie de la déployer selon votre calendrier de mise à jour habituel plutôt que de la reléguer en bas de la pile. Si vous faites tourner Gitea pour une équipe, ou avec des dépôts privés à côté de dépôts publics, c’est une raison suffisante pour agir bientôt. Pour les détails d’installation et ce dont Gitea a réellement besoin pour bien tourner en auto-hébergement, consultez notre fiche application Gitea.
Source : les notes de version de Gitea v1.27.3 sur GitHub.