En bref : si votre serveur PHP pose problème et que vous voulez parler directement à un expert, appelez-nous ou écrivez-nous sur WhatsApp. Vous êtes concerné ? Appelez-nous. Nous vous aidons. Nous clarifions à distance s'il s'agit d'une panne, d'une erreur de configuration ou d'une attaque, et nous prenons le relais dès le premier message, jusqu'à ce que l'incident soit clos et documenté.
Ne supprimez rien et ne réinstallez rien pour l'instant. Un redémarrage ou un retour en arrière peut aussi effacer des traces. Décrivez-nous d'abord ce que vous voyez. Signaler une urgence, puis nous fixerons la prochaine étape.
Êtes-vous concerné ? Ces perturbations nous concernent
Toute perturbation n'est pas une attaque, mais en ce moment il vaut la peine de vérifier. Contactez-nous si votre système PHP présente ce qui suit :
- Des processus PHP ou le serveur web s'interrompent, redémarrent sans cesse ou sont arrêtés par le système (code de sortie 137).
- La charge augmente sans raison apparente ou la mémoire se remplit.
- Des pages renvoient des réponses vides, des erreurs 500 ou des messages d'erreur qui n'existaient pas auparavant.
- Sous le serveur web ou PHP-FPM, des processus lancent un shell.
- Dans le dossier d'envoi ou de cache se trouvent des fichiers PHP que vous ne connaissez pas.
- Après une mise à jour de PHP, une application ne fonctionne plus.
- Votre hébergeur a bloqué l'accès ou mis le site hors ligne.
La différence entre une panne et une attaque ne se voit généralement que dans les journaux. L'article Le serveur web lance un shell décrit les premiers éléments à surveiller.
Ce que vous faites tout de suite
- Observer avant d'intervenir. Notez l'heure, les messages d'erreur et ce qui a été modifié en dernier (mise à jour, plug-in, configuration).
- Sécuriser les journaux. Copiez les journaux du serveur web, de PHP et du système avant qu'ils ne tournent. La presse spécialisée conseille de conserver les journaux à partir du 20 octobre 2026.
- Ne pas redémarrer à l'aveugle. Un redémarrage résout certaines pannes, mais détruit des traces volatiles. Redémarrez si l'exploitation l'exige, et notez ce que vous avez fait.
- Peser l'accessibilité. Si vous soupçonnez une attaque, l'isolement ou l'arrêt est souvent la bonne décision. Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) le conseille lorsque la mise à jour n'est pas possible immédiatement.
- Déterminer la version de PHP.
php -vaffiche la version, mais pas toujours celle de l'environnement d'exécution du serveur web. - Appeler ou écrire. Plus vous pouvez décrire précisément la situation, plus vite nous allons à l'essentiel.
Comment PHP SOS aide-t-il concrètement ?
Nous travaillons à distance, sans déplacement, partout en Allemagne et en Europe.
- Faire le point : lors du premier échange, nous écoutons et posons des questions ciblées : systèmes, mode d'exécution de PHP, moment, dernières modifications. Vous savez ensuite si nous voyons une panne ou un soupçon d'attaque.
- Sécuriser et fermer : nous sécurisons l'état, éliminons la cause et, si nécessaire, fermons la faille par la mise à jour, le redémarrage et des mesures transitoires.
- Examiner et nettoyer : si une intrusion apparaît, nous supprimons le code malveillant et vérifions les accès et les secrets. Sinon, nous documentons la cause et laissons l'exploitation fonctionner proprement.
- Durcir et rendre compte : vous recevez un court rapport et des recommandations pour que la perturbation ne se reproduise pas.
Si l'affaire est plus grave, nous passons à l'aide d'urgence en cas de site web piraté ou à la réponse aux incidents structurée.
Mémoire, interruptions et nouvelle limite
Depuis les versions de sécurité du 21 octobre 2026 (8.5.12, 8.4.27, 8.3.36, 8.2.35), la directive memory_hard_limit_percent existe. Depuis lors, memory_limit est une limite souple. Sans réglage propre, la limite stricte est le double de memory_limit jusqu'à 1G, et au-delà memory_limit plus 1G. Si elle est dépassée, le processus se termine immédiatement avec le code de sortie 137. Une exploitation qui fonctionnait avant la mise à jour tout près de la limite peut ainsi présenter soudain des interruptions. Ce n'est pas une attaque, mais une conséquence de la correction, et la solution consiste à adapter proprement l'application ou la limite, pas à annuler la mise à jour.
Inversement : qui constate des processus plantés et n'a pas encore appliqué le correctif ne devrait pas y voir un hasard, car la faille CVE-2026-109618 est liée à un état de mémoire insuffisante (out of memory). Les journaux montrent si cela joue un rôle chez vous. Vous trouverez des informations de fond sur la gestion de la mémoire sous Out-of-Memory dans PHP, et de possibles signes d'intrusion sous Processus suspects sous Linux.
Quand l'hébergeur intervient
Certains fournisseurs bloquent des comptes ou mettent des sites hors ligne par précaution. Cela ne signifie pas automatiquement que vous avez été piraté, mais peut être la conséquence d'anomalies. Demandez la raison et le moment, réclamez les journaux et consignez ce que le fournisseur exige. Nous nous concertons avec votre hébergeur si vous le souhaitez. Il est judicieux de clarifier au préalable qui peut prendre des décisions chez le fournisseur et s'il dispose de journaux du serveur que vous ne pouvez pas consulter vous-même. De telles données, par exemple les accès au niveau du réseau, peuvent s'avérer décisives par la suite pour circonscrire le moment d'une éventuelle intrusion.
Ce que vous devriez nous envoyer
- une courte description : qu'est-ce qui est en panne ou suspect, depuis quand ?
- le type de système (serveur dédié, offre d'hébergement, conteneur) et l'hébergeur
- le résultat de
php -v, le mode d'exécution et le serveur web, s'ils sont connus - des messages d'erreur ou des extraits des journaux
- la date de la dernière mise à jour de PHP et des dernières modifications
- une personne de contact habilitée à décider des redémarrages
Pourquoi PHP SOS
Nous travaillons Made in Germany et, avec notre réseau de partenaires de professionnels de la cybersécurité, nous sommes spécialisés depuis plus de 25 ans dans la sécurité informatique. Vous parlez à un interlocuteur fixe plutôt qu'à un système de tickets. Nous travaillons à distance, documentons ce que nous voyons et faisons, et disons ouvertement ce qui est établi et ce qui ne l'est pas. Pour les cas aigus autour de la faille, il existe en outre l'aide d'urgence PHP2Shell.
Vous êtes concerné ? Appelez-nous. Nous vous aidons.
Si votre serveur PHP pose problème, n'attendez pas la prochaine panne. Appelez-nous ou écrivez-nous sur WhatsApp. Nous prenons le relais dès le premier message. Signaler une urgence maintenant.
Questions fréquentes
Mon serveur PHP est soudain lent ou plante : est-ce une attaque ?
Pas nécessairement. Les pannes ont souvent des causes banales, comme un manque de mémoire, une mise à jour défectueuse ou une surcharge. Seul un coup d'œil aux journaux et aux processus montre s'il s'agit d'une attaque ; les signes d'alerte sont par exemple des processus shell sous le serveur web ou de nouveaux fichiers PHP inconnus.
Que signifie le code de sortie 137 pour les processus PHP ?
Le code 137 désigne un processus terminé immédiatement. Selon le manuel PHP, un processus se termine avec 137 lorsqu'il dépasse la limite de mémoire stricte de la nouvelle directive memory_hard_limit_percent ; il peut aussi avoir été arrêté par le système faute de mémoire. La cause se clarifie en consultant les journaux.
Puis-je téléphoner à un expert avant de modifier quoi que ce soit ?
Oui, c'est précisément à cela que sert l'aide d'urgence. Appelez-nous ou écrivez-nous sur WhatsApp et décrivez ce qui vous alerte. Nous vous disons ce que vous devriez éviter et ce que vous pouvez faire sans danger.
Dois-je simplement redémarrer le service PHP ?
Un redémarrage peut résoudre une panne, mais il efface des indices en mémoire vive. Si une intrusion est possible, sécurisez d'abord les journaux et faites-vous conseiller. Après une mise à jour de PHP, en revanche, le redémarrage est obligatoire.
Travaillez-vous aussi si mon serveur est chez un hébergeur ?
Oui, nous travaillons à distance avec l'accès dont vous disposez et nous nous concertons au besoin avec votre hébergeur. Les vérifications possibles dépendent de vos droits.