Télécharger les sites web qui utilisent JBoss Web

À propos de JBoss Web

La plupart des logiciels serveurs présents sur le web public témoignent d’une décision récente. JBoss Web témoigne d’une décision prise il y a longtemps et jamais réexaminée. Le composant est la couche HTTP et servlet du serveur d’applications JBoss, la partie qui acceptait les requêtes et exécutait les servlets et les pages JSP des applications Java déployées derrière lui, si bien que son apparition dans un en-tête de réponse ou une page d’erreur en dit moins sur une préférence de serveur web que sur tout un parc d’entreprise qui se tient derrière la porte.

JBoss Web est né chez Red Hat et a été distribué sous licence LGPL, avec une histoire qui remonte à 2005. La filiation explique la forme de ce que nous trouvons. Les serveurs d’applications de cette époque étaient installés par des intégrateurs, configurés une fois et laissés en marche sous des applications métier que personne ne voulait toucher, et les versions ultérieures de la même gamme sont passées à une couche HTTP différente, non bloquante. Ce qui reste visible sur le web public est donc une population d’installations qui ont cessé de recevoir de l’attention plutôt qu’une population de choix actuels.

Les données de version le montrent mieux que ne le ferait n’importe quelle description. Sur l’ensemble de nos détections, nous ne relevons que 2 versions distinctes de JBoss Web, et la version que nous rencontrons le plus souvent est 2.0. Un logiciel en développement actif produit une longue traîne de versions dans un dataset d’empreintes, parce que les sites se mettent à niveau à des rythmes différents et qu’il y a toujours quelque chose de plus récent vers quoi migrer. Un étalement aussi étroit signifie que le code a cessé de bouger, si bien que ce que le dataset enregistre n’est pas un comportement de mise à niveau mais l’année où chaque serveur a été monté pour la dernière fois.

En octobre 2026 nous détectons JBoss Web sur 52 sites, un chiffre petit en valeur absolue et dense en valeur utile. Qui vend des projets de migration lit la liste comme un ensemble d’organisations qui font tourner une stack Java non modernisée, avec un problème de budget reporté. Les chercheurs en sécurité y lisent une exposition, parce qu’un composant qui ne reçoit plus de correctifs se trouve en général devant des applications de la même époque qui n’en reçoivent pas davantage. Les fournisseurs de serveurs d’applications, de plateformes d’exécution et d’outils de supervision y lisent une liste de conquête dont l’argument technique est déjà écrit.

La détection est ici inférentielle et l’inférence ne va que dans un sens. Un serveur qui annonce le composant dans ses en-têtes est trivialement identifiable, alors qu’un serveur configuré pour masquer sa bannière nous est invisible, tout comme n’importe quel déploiement placé derrière un proxy inverse ou un CDN qui réécrit la réponse. Les empreintes de ce genre sous-estiment le total dans une proportion que personne ne peut mesurer de l’extérieur, si bien que la population se lit au mieux comme la part du parc qui s’annonce encore.

Une requête unique confirme un hôte. La liste téléchargeable est ce qui transforme la même empreinte en relevé, à savoir combien d’hôtes subsistent, sur quels domaines nationaux ils se regroupent, et si le total baisse d’un export au suivant. Des décomptes qui baissent d’un export à l’autre sont ce qui se rapproche le plus d’une courbe publique de démantèlement pour un logiciel d’entreprise qui n’a plus de calendrier de versions.