Uptime Kuma 2.5.4 est sorti le 11 septembre 2026, une release signée publiée sur la page GitHub officielle du projet par le mainteneur louislam. L’élément principal est un correctif de sécurité critique : une faille dans la bibliothèque JSONata, qu’Uptime Kuma utilise pour évaluer les conditions dans les notifications et la logique des pages de statut, pouvait être enchaînée jusqu’à l’exécution de code arbitraire sur l’hôte qui fait tourner le moniteur. Uptime Kuma détient généralement des clés API et des jetons pour des dizaines de services de notification connectés : une exécution de code sur cet hôte a donc un rayon d’action plus large que le seul tableau de bord de surveillance.
Les conditions JSONata dans Uptime Kuma sont écrites par la personne qui configure vos moniteurs et notifications, normalement le seul administrateur de l’instance. Ce n’est donc pas quelque chose qu’un visiteur au hasard d’une page de statut publique peut déclencher tout seul. L’exposition réelle est plus étroite que ce que le score CVSS laisse penser sur une instance homelab typique à un seul administrateur, et plus large sur toute instance où la configuration des moniteurs ou des notifications est partagée avec des collaborateurs moins fiables. Le correctif, lui, ne coûte rien : une simple mise à jour de dépendance, sans aucun inconvénient. Peu de raisons, donc, d’attendre une fenêtre de maintenance de routine.
Une faille critique d’exécution de code dans JSONata
Le correctif est référencé sous CVE-2026-77415, noté 9,3 sur 10 sur l’échelle CVSS v4.0 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) : exploitable via le réseau, sans privilège ni interaction utilisateur requis, avec un impact élevé sur la confidentialité, l’intégrité et la disponibilité. Elle est documentée sous la référence GHSA-66mm-25pp-rfff et se situe dans JSONata, le langage d’expression qu’Uptime Kuma embarque pour faire tourner des conditions à l’intérieur des notifications et de la logique des pages de statut.
Une expression JSONata forgée pouvait enchaîner plusieurs faiblesses d’intégrité d’objets : écraser la fonction interne $clone via evaluateTransformExpression, utiliser $merge pour exposer et démonter les fonctions internes, puis atteindre les accesseurs de prototype et l’accès au constructeur. La chaîne aboutit à process.getBuiltinModule et au module child_process de Node, de quoi exécuter des commandes arbitraires avec les privilèges du processus Uptime Kuma lui-même.
Uptime Kuma referme la faille en faisant passer sa dépendance jsonata à la version 2.2.2 (PR #7838). Il n’existe pas de correctif séparé dans le code propre d’Uptime Kuma ; la mise à jour vers la 2.5.4 embarque automatiquement la bibliothèque corrigée.
Un second correctif, plus mineur
Cette version referme aussi GHSA-wf2j-5mc7-5c4w, décrite dans le changelog comme une faiblesse de déni de service. Aucun numéro de CVE ni score CVSS n’a été publié pour celle-ci. C’est un enjeu plus mineur que la faille JSONata, mais elle est livrée dans la même version 2.5.4 : rien ne justifie de retarder la mise à jour à cause d’elle.
Nouveautés : moniteur SFTP et trois fournisseurs de notification
Au-delà des correctifs de sécurité, la 2.5.4 apporte aussi du vrai travail de fonctionnalités :
- Un nouveau type de moniteur SFTP, avec prise en charge de l’authentification par mot de passe et par clé privée (PR #7034).
- Trois nouveaux fournisseurs de notification : Signalgrid, Notify! et Amoot SMS.
Côté interface, la page de connexion dispose désormais d’un bouton pour afficher ou masquer le mot de passe. Une petite amélioration d’ergonomie, réclamée depuis un moment.
Les autres corrections de cette version
Une poignée de bugs plus mineurs ont aussi été nettoyés : le contexte de navigateur utilisé par le type de moniteur « real browser » ne se fermait pas toujours correctement, l’icône PWA sur iOS affichait un fond noir non désiré, deux champs de plafond de délai de ping dans le formulaire de moniteur étaient inversés l’un avec l’autre, un problème de timing du pool de connexions MariaDB a été corrigé, et une plage personnalisée de codes de statut acceptés n’est plus perdue à la création d’un tag.
Faut-il mettre à jour ?
CVE-2026-77415 est notée critique, mais l’exploiter suppose de pouvoir rédiger une expression JSONata malveillante dans la configuration des moniteurs ou des notifications de votre propre instance, pas simplement de visiter une page de statut publique. Sur la plupart des installations à un seul administrateur, la mise à jour compte donc surtout comme une bonne hygiène plutôt que comme une urgence. Elle devient plus pressante sur les instances où la configuration des moniteurs est partagée avec des personnes en qui vous n’avez pas une confiance totale. Rien d’affolant, mais rien à repousser non plus. La mise à jour suit la routine habituelle d’Uptime Kuma : récupérer la nouvelle image si vous faites tourner le conteneur Docker officiel, ou mettre à jour le paquet npm si vous avez installé directement sur Node.js, puis redémarrer le service.
Si vous n’avez pas encore mis en place Uptime Kuma, notre fiche Uptime Kuma détaille l’installation Docker, la surveillance HTTP/TCP/ping et les pages de statut publiques en partant de zéro. Notre précédente couverture d’Uptime Kuma 2.5.0 revient sur le moniteur NTP et le délai de sécurité npm introduits dans la version précédente.
Sources : les notes de version d’Uptime Kuma 2.5.4 sur GitHub, et l’avis GHSA-66mm-25pp-rfff pour CVE-2026-77415.