Actualité

PHP2Shell : quand une faille logicielle peut ouvrir de vraies portes

Le 21 octobre 2026, PHP a publié en urgence des correctifs pour deux failles critiques permettant de prendre le contrôle d'un serveur à distance. On pense d'abord aux sites web. Mais les logiciels qui pilotent les badges et les portes sont, eux aussi, des applications sur des serveurs. Une faille dans le monde numérique peut-elle ouvrir des portes dans le monde physique ? Décryptage.

Ce qui s'est passé

Le 20 octobre, un message publié puis supprimé sur un forum décrivait deux vulnérabilités inédites dans le langage PHP, vidéo d'un outil baptisé « PHP2Shell » à l'appui. Face à cette fuite, l'équipe de sécurité de PHP a avancé sa publication et diffusé les correctifs dès le lendemain, le 21 octobre.

  • Deux failles : CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4.0).
  • Exécution de code à distance sans authentification : un attaquant peut faire exécuter ses propres commandes au serveur, sans avoir de compte.
  • Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
  • Une exposition massive : selon la société Mallory, citée par The Hacker News, environ 884 000 serveurs accessibles sur Internet affichaient une version de PHP 8.1 ou plus ancienne.

Le jour même, Cloudflare indiquait observer de premières attaques et déployait des règles de protection, tandis que Patchstack ne relevait encore, à ce stade, que des tentatives de repérage, sans preuve formelle d'intrusion. La situation évolue vite : la mise à jour reste la seule protection fiable.

Quel rapport avec vos badges ?

Un système de contrôle d'accès ne se résume pas aux lecteurs fixés au mur. Derrière, il y a presque toujours un logiciel de gestion : une interface web où l'on crée les utilisateurs, attribue les droits, consulte l'historique des passages et, souvent, commande l'ouverture des portes à distance. Ces interfaces reposent sur des technologies web classiques et tournent sur des serveurs qui, eux aussi, doivent être mis à jour.

C'est là que le risque change de nature. Un attaquant qui prend le contrôle de ce serveur n'a plus besoin de cloner un badge. Selon les systèmes, il pourrait :

  • se créer un compte et s'attribuer les droits sur les portes de son choix ;
  • réactiver un badge censé avoir été révoqué ;
  • déclencher une ouverture à distance ;
  • effacer ou modifier l'historique des passages pour masquer sa présence.

Rien n'indique à ce jour que des systèmes de contrôle d'accès aient été visés par PHP2Shell. Mais l'épisode rappelle une réalité souvent oubliée : la sécurité physique dépend aussi de la sécurité informatique. C'est l'une des formes de la dette de sécurité dont nous parlions hier : des serveurs qui fonctionnent, mais que personne ne pense à mettre à jour.

Que faire dès maintenant ?

  1. Inventorier tous les serveurs qui utilisent PHP, y compris ceux de la vidéosurveillance, de l'interphonie et du contrôle d'accès. En cas de doute, interrogez votre fournisseur ou votre installateur.
  2. Mettre à jour vers une version corrigée, en commençant par les serveurs accessibles depuis Internet.
  3. Isoler les logiciels de gestion des accès : ils n'ont généralement pas besoin d'être exposés sur Internet. Un accès par VPN et un réseau séparé réduisent fortement le risque.
  4. Surveiller les signaux anormaux : nouveaux comptes administrateurs, droits modifiés, ouvertures à distance à des heures inhabituelles.
  5. Protéger les comptes d'administration : mots de passe uniques et double authentification.

L'approche AuthFlash

Aucune technologie ne dispense de sécuriser ses serveurs, et AuthFlash ne fait pas exception. Mais la conception du système limite ce qu'un attaquant peut obtenir. Avec AuthFlash, une solution BatyTech, le badge n'est plus un identifiant fixe stocké quelque part : au moment du passage, le flash du smartphone transmet une clé cryptographique éphémère, reçue par un lecteur optique uniquement en ligne de vue. Le serveur valide ce code dynamique et refuse toute tentative de rejeu.

Conséquence : une liste d'identifiants dérobée ne permet pas de fabriquer de copies, et un code déjà utilisé ne vaut plus rien. Les droits se gèrent depuis une plateforme centrale et son API, ce qui permet de révoquer un accès immédiatement en cas d'incident. La technologie fait l'objet d'un brevet en cours, et un déploiement est prévu sur les campus de l'EFREI Paris de novembre 2026 à mars 2027 (estimation). Vous pouvez l'essayer dans notre démonstration interactive.

En résumé

PHP2Shell est d'abord une urgence pour les sites web. Mais c'est aussi un rappel utile : une porte n'est pas plus sûre que le serveur qui la commande. Mettre à jour, isoler et surveiller les logiciels de gestion des accès fait partie de la sécurité physique, au même titre que le choix des badges. Pour faire le point sur votre installation, contactez l'équipe AuthFlash.

Sources

News

PHP2Shell: when a software flaw can open real doors

On October 21, 2026, PHP rushed out patches for two critical flaws that allow a server to be taken over remotely. Websites come to mind first. But the software that manages badges and doors also runs as applications on servers. Can a flaw in the digital world open doors in the physical one? Here is what you need to know.

What happened

On October 20, a forum post, published and then deleted, described two previously unknown vulnerabilities in the PHP language, with a video of a tool called "PHP2Shell". Faced with this leak, the PHP security team brought its release forward and shipped the fixes the very next day, October 21.

  • Two flaws: CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10 (CVSS v4.0).
  • Unauthenticated remote code execution: an attacker can make the server run their own commands, without an account.
  • Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • Massive exposure: according to Mallory, cited by The Hacker News, around 884,000 internet-facing servers reported PHP 8.1 or older.

That same day, Cloudflare said it was seeing early attacks and deployed protection rules, while Patchstack was still only seeing probing at that stage, with no hard evidence of breaches. The situation is moving fast: updating remains the only reliable protection.

What does this have to do with your badges?

An access control system is more than the readers on the wall. Behind them there is almost always management software: a web interface where users are created, rights are assigned, access logs are reviewed and, often, doors are opened remotely. These interfaces rely on standard web technologies and run on servers that also need to be kept up to date.

That is where the nature of the risk changes. An attacker who takes over that server no longer needs to clone a badge. Depending on the system, they could:

  • create an account and grant themselves rights to any door;
  • reactivate a badge that was supposed to be revoked;
  • trigger a remote door opening;
  • delete or alter access logs to hide their presence.

There is no indication so far that access control systems have been targeted by PHP2Shell. But the episode is a reminder of an often-overlooked reality: physical security also depends on IT security. It is one form of the security debt we wrote about yesterday: servers that work, but that nobody thinks to update.

What to do right now

  1. Take inventory of every server running PHP, including video surveillance, intercom and access control servers. If in doubt, ask your vendor or installer.
  2. Update to a fixed version, starting with internet-facing servers.
  3. Isolate access management software: it usually does not need to be exposed to the internet. VPN access and a separate network greatly reduce the risk.
  4. Watch for unusual signals: new admin accounts, modified rights, remote openings at unusual hours.
  5. Protect admin accounts: unique passwords and two-factor authentication.

The AuthFlash approach

No technology removes the need to secure your servers, and AuthFlash is no exception. But the system's design limits what an attacker can gain. With AuthFlash, a BatyTech solution, the badge is no longer a fixed identifier stored somewhere: when passing through, the smartphone's flash transmits an ephemeral cryptographic key, received by an optical reader in line of sight only. The server validates this dynamic code and rejects any replay attempt.

As a result, a stolen list of identifiers cannot be used to make copies, and a code that has already been used is worthless. Rights are managed from a central platform and its API, so access can be revoked immediately in the event of an incident. The technology is patent pending, and a rollout is planned on the EFREI Paris campuses from November 2026 to March 2027 (estimate). You can try it in our interactive demo.

In short

PHP2Shell is first and foremost an emergency for websites. But it is also a useful reminder: a door is no more secure than the server that controls it. Updating, isolating and monitoring access management software is part of physical security, just like choosing the right badges. To review your installation, contact the AuthFlash team.

Sources

Parlons de vos portes.

Démonstration, déploiement ou partenariat : réponse personnelle.

Nous contacter