Updated on 58 min read
Sébastien Nobour
Founder of DEVEDANOS
PHP is a programming language. Its developers describe it as a general-purpose scripting language especially suited to web development: on the server, it builds each page of a site at the moment a visitor requests it. According to W3Techs, a service that measures the technologies websites use, PHP is used, as of October 2026, by 69.3% of the websites whose server-side language is known. WordPress, Drupal, Magento, PrestaShop, Laravel and Symfony are written in PHP.
On 21 October 2026, the PHP team released new versions of the language as an emergency. They fix two critical vulnerabilities, which the people who found them named PHP2Shell. With a few requests, and no account or password, an attacker can make the server that hosts a site execute their own code. And it all happens before the site’s code even starts to run. These vulnerabilities go back to PHP 5.4, released on 1 March 2012. Attacks were reported before the fix was published.
If your website or application relies on PHP, the question to ask your host or your provider today is simple: which version of PHP do we use, and when does it move to a fixed version? The steps to follow, in order, are in the section “WordPress site hacked or vulnerability discovered: what to do, in order”.
On the same day, GitLab and Node.js also released fixes for serious vulnerabilities. GitLab, a platform that hosts software code and automates its testing and deployment, fixed a vulnerability (CVE-2026-110264) rated 10 out of 10 that, under certain conditions, let someone with no account execute code on self-managed installations. It affected every version since 7.0. GitLab.com, the version hosted by GitLab, had already been fixed.
Node.js, the software that executes JavaScript on servers, released versions that close four high-severity vulnerabilities, one of which, in the decoding of Brotli-compressed data, allows remote code execution. These versions also update the list of trusted certificates, after an intermediate certificate authority of eMudhra was compromised.
If your company hosts GitLab itself, or if its applications use Node.js, the same question applies to these programs: which version do we use, and when does it move to a fixed version?
Some news outlets grouped these fixes and other incidents of the week under the name “Black October”. As far as we know, the name first appeared in a post on X by the developer Muzzammil overnight on 21–22 October, and was taken up a few hours later by Axios and by 404 Media. SecurityToday, a German IT security news site, sees it above all as a peak in disclosures: many of the attacks revealed in those days had started weeks or months earlier.
The rest applies to any application, whatever its language. This vulnerability is not the first of this scale, and nothing suggests it will be the last. Three things can be prepared ahead of a vulnerability: what it lets an attacker reach, how long it takes to notice, and how long it takes to fix.
The technical details are grouped in the passages headed “For your technical team”.
On a web server, PHP is the program that executes a site’s code: the code of WordPress, of a PrestaShop store or of a custom-built application. The two vulnerabilities, referenced CVE-2026-109618 and CVE-2026-109619, are not in any of these programs, nor in a plugin. They are in PHP itself.
The PHP team describes them as follows. The first is triggered when PHP runs out of memory in the middle of a request: partly initialised data is then treated as valid. The second leaves information tied to a finished request in the server’s memory, where a later request can reuse it. The team gives them a severity score of 9.2 out of 10 (CVSS 4.0 scale). According to Calif, a security research company whose researchers reported the first vulnerabilities to the PHP team, they are exploitable under default configurations.
According to the timeline published by Calif, the first report to the PHP team dates from 11 August 2026. The research team at Wiz, a cloud security company, publishes a different timeline: discovery on 19 August, report to the PHP team on 24 August. Calif counts OpenAI, the AI model company, among the discoverers. The PHP team, Calif, OpenAI and Wiz were preparing a coordinated disclosure, that is, announcing the vulnerability on the day the fix is available, to leave attackers as little time as possible. On 20 October, details leaked before the planned publication date (Patchstack). The PHP team brought the release forward by a day (CyberScoop). Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 came out on 21 October at around 4 pm Paris time. The PHP team is clear: “There are no complete mitigations, updating is the only safe choice.”
Early attacks were reported on the morning of 21 October, before the fix was published. Cloudflare, a provider of website protection and acceleration services, observed attacks against its customers between the leak and the official release. At 5:02 am Paris time on 21 October it switched on filtering rules for all its customers, free plan included, while telling them to apply the fix even with those rules in place. Patchstack, which tracks vulnerabilities in the WordPress ecosystem, reports that partner hosts told it of exploitation the same morning. At around 4 pm Paris time, its own sensors were still only recording scanning attempts, with no evidence of intrusion. watchTowr, which tracks attacks through a network of decoy servers, says it observed exploitation on 21 October. Amazon’s threat intelligence team says its decoy servers recorded an exploitation attempt as early as 17 October, four days before publication. Cloudflare’s chief executive posted how the numbers grew (The Register): thousands of exploitation attempts (not confirmed intrusions) on its network in the ten hours before the announcement, tens of thousands in the 45 minutes after it, then millions. In Japan, the Prime Minister asked website operators that same day to check whether they use PHP and to apply the fix overnight, or failing that to take their sites offline. Banks, transport companies and government bodies in Japan and Europe suspended part of their services. As of 21 October, according to watchTowr, these vulnerabilities were not in the catalogue of exploited vulnerabilities kept by CISA, the US cybersecurity agency.
In France, CERT-FR, the incident response centre of ANSSI, the French national cybersecurity agency, published an alert the same day. It recommends isolating the affected systems, then moving to a maintained, up-to-date version as soon as the fix is available. CERT-EU, its counterpart for the EU institutions, advises patching immediately and, where that is not possible, considering isolating exposed applications from the Internet until the fix has been applied and verified. In the United States, CISA asks organisations to take PHP systems offline if they cannot be updated immediately or still run PHP 8.1 or older; the FBI’s Cyber Division issued the same instruction on 21 October.
session.upload_progress.enabled=0 (with php_admin_flag for PHP-FPM); Calif points out that this setting does not replace a fix. CERT-FR suggests blocking, or at least monitoring, multipart requests at a web application firewall, noting that it has not validated these workarounds. Restart all PHP processes after changing a setting (Patchstack); the pipeline or the host applies that change like any other.To understand it, you need to know what PHP does when a request arrives. When a visitor submits a form or a file, the web server passes the request to PHP. PHP starts by preparing it: it parses the data received, allocates memory, sets up the visitor’s session. Only then does it start the site’s code, the code that checks who is logged in and what they are allowed to do.
PHP2Shell is triggered during this preparation. According to Calif, both attack paths execute “before the target PHP file runs”. Wiz adds that the attack works even if the application never uses sessions. Calif states that with PHP-FPM, additional conditions apply (see the technical box above).
The mechanism, simplified, unfolds in three steps.
At that point, neither the login page nor the application’s access rules have run yet.
The attacker’s code then very probably runs with the rights of the PHP process, that is, of the system user PHP runs as on the server (php.net). That is not automatically the machine’s administrator. But this user can read everything PHP needs to make the site work. And on a system that is not itself up to date, other known vulnerabilities let an attacker go from this user to the machine’s administrator: that was the case with PwnKit and Baron Samedit, discussed below.
Here is a plausible scenario, which chains what these vulnerabilities allow with what attackers have already done against PHP sites. At the time of writing (October 2026), no attack of this kind has been described with PHP2Shell.
Read the database password. A site needs to connect to its database, and the password is most often in a configuration file. For WordPress, it is the wp-config.php file, which, according to the WordPress documentation, “contains your website’s base configuration details, such as database connection information”. The WordPress hardening guide advises making sure that only you “and the web server” can read it. Yet if PHP is executed by the same system user as the web server, which depends on the configuration, the attacker’s code can read this file. Looking for passwords in configuration files is a technique catalogued by MITRE ATT&CK, the reference knowledge base of attack techniques.
Help themselves to the data. With this password, the attacker connects to the database as the application would: customer accounts, orders, addresses. If the database account also has the right to delete or alter tables, they can do much more than read.
Settle in to come back. The attacker can drop a web shell: a small file placed on the web server that lets them come back and control the server from their browser (MITRE ATT&CK). This file stays in place after PHP is updated. Fixing the vulnerability does not remove it.
Skim card payments. On an online store, the attacker can insert code into the checkout page that copies the card numbers customers enter. That is what the CosmicSting attackers did, as described below.
Read the server’s memory, without executing code. According to Wiz, these vulnerabilities also make it possible to read part of the memory of PHP processes, which can hold “passwords, authentication tokens, API keys and certificates”.
Two recent attacks show what such vulnerabilities become once they are public. In June 2024, a vulnerability in PHP on Windows (CVE-2024-4577) was the target of many exploitation attempts within 24 hours of its disclosure, according to the research team at Akamai, a company providing Internet security and content delivery services. The attackers installed remote access tools, software that mines cryptocurrency at the server’s expense, and botnet malware. According to Help Net Security, citing the company Imperva, the same vulnerability was used to deliver ransomware two days after the fix was published.
The same year, CosmicSting (CVE-2024-34102) hit Magento and Adobe Commerce, two online store platforms written in PHP. According to Sansec, a company specialising in online store security, seven groups of attackers hacked 4,275 stores. They stole the store’s secret encryption key, used it to forge access to its API, then inserted code into the checkout page that copied bank cards. When the attackers started looking for these keys, 75% of installations had not applied the fix. And according to Sansec, quoted by The Hacker News, even patched stores remained vulnerable as long as they had not replaced their key: a key stolen before the fix still worked afterwards. Applying the fix therefore does not end the incident.
Content management systems first. According to W3Techs, WordPress alone is used, as of October 2026, by 39.6% of all websites. Joomla (2.4%), Drupal (0.6%), PrestaShop (0.5%), Bitrix, TYPO3 and OpenCart (0.3 to 0.4% each) are also written in PHP.
Then custom-built applications. Laravel and Symfony are frameworks, sets of components on which custom applications are built in PHP. Symfony states that Drupal, PrestaShop and Laravel are built on its components. On the business software side, Dolibarr, an open source ERP and CRM for small and large companies alike, is written in PHP.
Calif says it confirmed exploitation on WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube and WHMCS, as well as on Laravel and Symfony. And other products embed PHP without showing it: CERT-EU warns that products that include PHP may be affected even if they do not expose it directly. Palo Alto Networks confirmed this on 21 October: every version of PAN-OS, the operating system of its firewalls, and of its Panorama management console is affected, through the management interface. As of that date, no fixed version is available; the vendor advises restricting access to this interface to trusted internal addresses. NCSC-NL, the national cybersecurity centre of the Netherlands, maintains a list of software that depends on PHP: it is the best starting point for finding out which ones you use.
How many sites use a version the PHP team no longer fixes? In October 2026, by our calculations on W3Techs’ figures, nearly half of PHP sites whose version is known: around 35% are on PHP 7 or older, and around 14% on PHP 8.0 or 8.1 (breakdown by version, PHP 8 detail). This figure should be read with caution: some Linux distributions patch old versions themselves without changing the version number, so an old version is not always a vulnerable one. According to a researchers’ estimate reported by CyberScoop on 21 October 2026, more than 1.3 million servers exposed on the Internet could be vulnerable. So check your site’s PHP version, or ask your host for it. If it is no longer among the versions the PHP team maintains, it will not get a new official release fixing PHP2Shell. The PHP team has published minimal source patches for PHP 7.4, 8.0 and 8.1 (technical box above), but most sites only get them through their Linux distribution or their host. Otherwise, move to a maintained version.
Fourteen and a half years between writing a piece of code and discovering its vulnerability seems enormous. That is often the case, even for some of the most serious vulnerabilities of recent years.
| Vulnerability | Software affected | Present since | Made public | Duration |
|---|---|---|---|---|
| Shellshock | Bash, the command interpreter of Unix and Linux systems | 1989 | September 2014 | about 25 years (D. A. Wheeler) |
| PwnKit | pkexec, a polkit tool for running a command with other rights on Linux | May 2009 | January 2022 | about 12 and a half years (Qualys) |
| Baron Samedit | sudo, the command for acting as administrator on Linux | July 2011 | January 2021 | about 9 and a half years (Qualys) |
| Heartbleed | OpenSSL, an encryption library | March 2012 | April 2014 | about 2 years (heartbleed.com) |
| PHP2Shell | PHP | March 2012 | October 2026 | about 14 and a half years (php.net) |
Researchers had measured as early as 2006 how long vulnerabilities stay hidden. Andy Ozment and Stuart Schechter, two computer security researchers, followed the vulnerabilities of OpenBSD, an open source operating system known for its security, over seven and a half years and fifteen releases. 62% of the vulnerabilities reported during the study were already present when it began, and half of the vulnerabilities in the original code stayed hidden for at least 2.6 years before being found (USENIX Security 2006).
For PHP2Shell, there were even signs before the discovery. According to Calif, a first PHP problem related to the memory limit had been found as early as 2004, a related bug reported in 2020, and a 2024 audit had flagged a similar problem without being able to show it was exploitable.
These vulnerabilities have one thing in common: they sat in code written years earlier, on which a very large number of systems rely.
Mandiant, Google Cloud’s threat intelligence team, measures every year the time between the disclosure of a vulnerability and its first observed exploitation. On average, this time was 63 days in 2018 and 2019, 44 days between 2020 and early 2021, 32 days in 2021 and 2022, then only 5 days in 2023 (Mandiant). In its M-Trends 2026 report, Mandiant estimates that, on average, first exploitation comes seven days before the vulnerability is disclosed. Exploitation is routinely occurring “before a patch is even released” (M-Trends 2026).
VulnCheck, a vulnerability intelligence company, looked only at vulnerabilities with confirmed exploitation. In the first half of 2026, 23.43% of them were exploited on the day they were disclosed, or before. Content management systems, such as WordPress and its plugins, are the most targeted category: a third of these vulnerabilities (VulnCheck). For the most exploited WordPress vulnerabilities, Patchstack, which sells protection against these attacks, measured in 2025 a median of five hours before first exploitation (Patchstack). And according to Verizon’s annual report on data breaches, in its 2026 edition, 31% of breaches start with a software vulnerability, ahead of stolen credentials (Verizon DBIR 2026).
PHP2Shell illustrates this: a first attempt spotted by Amazon as early as 17 October, a leak on the 20th, attacks reported by Cloudflare and watchTowr on the morning of the 21st, the fix published that afternoon.
These figures explain what follows. If the attack can start before the fix is published, applying it is not enough. Three things remain to be prepared: that the vulnerability, on the day it is exploited, does not give access to everything; that you are alerted immediately; and that the fix, once published, goes to production within the day.
The Calif researchers explain that they reviewed PHP’s source code with the help of a language model. AI agents followed the code paths, and a model generalised the first vulnerability into a research method, which led to a second one. According to them, they needed no special tooling and no access to a non-public model; their knowledge of the history of PHP vulnerabilities mattered. Wiz, for its part, warns that language models can help adapt an attack to different PHP versions, configurations and memory layouts, and that “this significantly lowers the barrier to scaling attacks across different deployments”.
It is not the first case. In 2024, Big Sleep, an AI agent from Google, found an exploitable vulnerability in SQLite, a database found in a very large number of applications, fixed before it reached a released version (Google Project Zero). In August 2025, at the final of DARPA’s AIxCC competition (DARPA is the research agency of the US Department of Defense), AI systems found 54 vulnerabilities planted for the competition and fixed 43 of them, in 45 minutes per fix on average. They also found 18 real vulnerabilities, which had not been planted for the occasion (DARPA).
On 21 October, two projects fixed vulnerabilities found with AI tools: PHP, according to the people who discovered its vulnerabilities, and Node.js, for one of its own (CVE-2026-111497), which its team credits to OpenAI Codex Security and two researchers. The GitLab vulnerability was reported by a researcher, and GitLab mentions no AI tool.
On 21 October, Microsoft described a campaign carried out with ARTEX by Storm-0940, an actor Microsoft says is aligned with the Chinese state. Microsoft presents ARTEX as an open source penetration testing framework that hands the stages of an attack to AI agents. According to Microsoft, Storm-0940 used it to automate attacks against hundreds of organisations. After compromising ConnectWise, a software vendor for IT service providers, it tried to sign in to more than 2,250 Microsoft 365 environments belonging to ConnectWise’s customers. The agents handled reconnaissance, changes to application credentials, and attempts to change permissions to widen or extend their access. Microsoft states that most of these attempts failed.
On 19 October, Reuters reported that a Chinese-speaking cybercriminal had used AI agents to break into the websites of more than 100 companies, for around $5,000 of AI usage. The agency could not establish how much data had been extracted. Reuters relies on a report by a researcher, Snorre Fagerland, of the company NorForge; of the companies named, two say they dealt with an incident on a website.
Amazon describes a general trend: AI-assisted analysis makes it cheaper to go from a fix or a security advisory to a working attack, and more attackers can act within hours, or even minutes, of a vulnerability’s details being published. Amazon does not say that the PHP2Shell attackers used AI, and says it does not know how the attacker obtained information about the vulnerability before it was published.
Big Sleep and AIxCC show that AI systems find vulnerabilities in real code; according to Wiz, a model can help adapt an attack; and according to Microsoft, AI agents are already carrying out attacks against organisations. AI therefore serves those who fix vulnerabilities as well as those who exploit them. We treat this as a hypothesis: the time between the discovery of a vulnerability and the first attacks could shrink further.
Security authorities agree on one point: AI shortens the time available to those who apply fixes. In February 2026, CERT-FR wrote, in its overview of the threat posed by generative AI, that it “enables malicious actors to act faster, and therefore on a larger scale”. In May, the NCSC, the UK’s National Cyber Security Centre, announced a wave of updates, for vulnerabilities of every severity, because AI, in skilled hands, can exploit the weaknesses accumulated in software “at scale and at pace”. In June, CISA changed the deadlines it sets US federal agencies for applying fixes: they now depend on risk (exposure to the Internet, confirmed exploitation, impact). The shortest deadline is three days. CISA justifies the change by attackers’ use of AI, which “may further narrow” the time defenders have. From this we take one rule: a critical fix is applied on the day it is published (see the exploitation timeframes above), and a delivery approach where every change already goes through the pipeline makes that possible.
AI is also used to write code, and several of these authorities recommend checking it. In March 2026, the NCSC’s chief executive warned that insecure software produced “without human review” could propagate vulnerabilities. ANSSI and the BSI, its German counterpart, point out in their report on coding assistants a risk of over-reliance on these tools and of accepting the code they generate without examining it, especially among junior developers. They recommend that generated code should, as a rule, be checked by developers, with a critical review of the tool’s mistakes and of security risks. CERT-FR flags another trap: an AI assistant can invent the name of a component that does not exist, and attackers register these names to publish malicious versions under them. For AI agents, the principle of least privilege applies just as it does to the PHP process (details below).
In practice, we advise a team that develops with AI to review every line the tool writes and to put it through the pipeline’s tests, like the rest of the code; to check that a component suggested by AI exists, and who publishes it, before adding it; and to give an agent only the rights its task needs. For an application built with AI, our article “Can you build an app with AI?” explains what the tool does on its own.
An SME or a start-up does not need security researchers on its teams. Finding a vulnerability like PHP2Shell takes specialists, and their research took place before disclosure: eight to ten weeks separate the first report from the fix, according to the Wiz and Calif timelines. For everything else, the 2017 edition of ANSSI’s IT hygiene guide lists 42 measures. The agency writes there that most of the attacks it responded to could have been avoided if these measures had been applied. For those without the expertise, it advises calling on a specialist for an assessment, and appointing a security contact within the company.
Dave Farley is the inventor of the deployment pipeline, often called the CI/CD pipeline. Continuous Delivery means keeping software ready to go to production at any time, through small changes checked automatically. The deployment pipeline is the automated chain that takes each change to the code, tests it, records it and makes it ready to go to production. Dave Farley is the co-author, with Jez Humble, of the book Continuous Delivery, and the author of Modern Software Engineering. In Continuous Delivery Pipelines, he writes that security may need to involve specialists, but that it is “everyone’s responsibility within the team”. Specialists advise; they should not act as “gate-keepers” who approve every release.
What the team that develops and maintains the application can do comes down to four objectives, and none of them requires looking for vulnerabilities:
The sections “Limit what a vulnerability lets an attacker reach” and “Be alerted immediately” cover the first two objectives. The sections on dependencies, on updates and on the delivery approach cover the third, and the section “WordPress site hacked or vulnerability discovered” the fourth.
According to M-Trends 2026, the median time between an attacker entering a system and being discovered is 14 days. During that time, the attacker acts: the first two objectives reduce what they can reach and how long they go unnoticed.
A digital service is more than a website. A typical web application has several parts: an entry point that receives requests from the Internet and passes them on, the server that executes the code, a database, backups, and the accounts of the people who administer it all. Each of these parts can be set up so that a vulnerability in one does not give access to all the others. This is called defence in depth.
Give each program only the privileges it needs. The PHP process needs neither to be the machine’s administrator nor to be able to modify the site’s code. The account it uses to connect to the database only needs, according to the WordPress hardening guide, to read and write data; the rights to delete, change the structure or grant rights can be taken away from it. Jez Humble and Dave Farley say so in Continuous Delivery: the default settings of operating systems and databases are not suitable for an application in production; you need firewalls, unnecessary services switched off, and database users with tailored rights.
Make the code impossible to modify from the site. If the PHP process cannot write to the code folders, an attacker who takes control of it cannot drop a web shell there as easily. WordPress provides for this: only the uploaded content folder (wp-content) should be writable by the web server, and the code editor built into the admin, according to WordPress “often the first tool an attacker will use if able to login”, can be disabled.
Segment the network. The database has no reason to be reachable from the Internet: only the application server should be able to connect to it. ANSSI asks for the network to be segmented, for the services visible from the Internet to be separated from the rest of the system, and for servers to be administered from a dedicated network (measures 19, 23 and 28 of its guide).
Filter upstream, knowing the filter’s limits. A web application firewall, or WAF, inspects requests before they reach the server and blocks those that look like a known attack. The WordPress hardening guide recommends installing one. It has its limits: Cloudflare itself tells customers to apply the fix even with its rules against PHP2Shell, and CERT-FR states that it has not validated the blocking it suggests. A web application firewall buys time; it does not replace the fix.
Take secrets out of the code. Passwords and access keys to other services (payment, email sending, storage) should not be written in the code files. MITRE ATT&CK recommends a policy that forbids storing passwords in files. Placed in the server’s environment variables or in a secrets vault, they remain readable by PHP while it runs: that does not protect them if the PHP process is taken over. What you gain, in our view, is that they are no longer in the code’s history or its backups, and that they can be changed without touching the code. That matters on the day they all have to be replaced.
Protect user and administrator accounts. An attacker does not always need a vulnerability: a reused password is enough. ANSSI asks for passwords to be protected, for default passwords to be changed, and for strong authentication to be preferred (measures 11 to 13). In practice, we advise a password manager, so that everyone has a different password for each service, and two-factor authentication on the accounts that give access to production, hosting and code.
Forbid manual changes in production. In Continuous Delivery Pipelines, Dave Farley sets a goal: “We should aim to eliminate human write access to production systems.” Every change goes through the deployment pipeline. In Continuous Delivery, the two authors add that production must be locked down against people outside the company and inside it alike, operations teams included. Without that, when something goes wrong, nobody knows any more who did what, or when.
Keep offline backups, and test them. A backup reachable from the compromised server can be encrypted or wiped along with the rest. ANSSI asks for a backup policy that includes offline copies and restore tests, with at least one restore exercise a year (measure 37). A backup that has never been restored has not proved that it works.
user directive, which is mandatory (php.net). Settings set with php_admin_value and php_admin_flag cannot be overridden with ini_set(). Do not expose PHP-FPM on an address reachable from outside.expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…), and secure, httponly and use_strict_mode session cookies. But the PHP documentation itself warns that disable_functions “can be circumvented” and that open_basedir “is just an extra safety net, that is in no way comprehensive”, and it does not restrict access to Unix sockets. These settings make the rest of an attack harder; they do not prevent it, and PHP2Shell is triggered before the application runs.DROP, ALTER and GRANT privileges can be revoked, bearing in mind that some updates change the schema); wp-config.php with permission 400 or 440; DISALLOW_FILE_EDIT; web application firewall, with ModSecurity cited as the most popular open source option.Once the defences are in place, you still need to be warned when they are breached. The goal is threefold: know that something abnormal is happening, cut off access, then find where the attack comes from. In Continuous Delivery, Jez Humble and Dave Farley ask that, when something goes wrong, the operations team be “informed immediately” of the incident, and have the tools to track down its cause. They also point to a common mistake: swallowing errors instead of logging them, which prevents them from being detected.
A monitoring solution watches specific signals, and its logs are kept somewhere other than the server being watched. Operations teams follow the state of the servers continuously on dashboards, such as Grafana or Kibana, which bring together metrics and logs and fire an alert when a threshold is crossed. Here are the signals these alerts should watch.
The web server starts a program. A web server serves pages; it has no reason to start a command interpreter or a download tool. When it does, a web shell is often in use (MITRE ATT&CK).
The server connects to unknown addresses. Cryptocurrency mining software, a remote access tool or a data leak all need outbound connections. We advise blocking the server’s outbound connections by default, except to the services the application needs: this also limits the use of these tools.
A code file changes. In production, the code only changes during a deployment. A new .php file in the site’s folders, outside a deployment, is a sign of intrusion. WordPress recommends monitoring file integrity, and points out that an attack always leaves traces in the logs or the file system.
A new administrator account appears. ANSSI asks for the inventory of privileged accounts to be kept up to date (measure 5). An administrator account created outside any procedure is a signal to act on.
Errors pile up. ANSSI asks for the errors of web services to be logged, citing 403, 404 and 500 errors, as well as unexpected shutdowns (measure 36).
Keep the logs off the server. An attacker who controls the server can erase their tracks in the logs stored on it. ANSSI therefore recommends centralising logs on another system, and keeping security events for at least a year.
A few open source tools, given as examples:
/etc (Falco documentation).An application is not written entirely by the people who develop it. It relies on components published by others, its dependencies, which tools install and update: Composer for PHP, npm or pnpm for JavaScript. And it runs on an environment, PHP itself, supplied by the server’s operating system, by the host or by the image used to deploy it.
In Continuous Delivery, Jez Humble and Dave Farley are categorical: “your build system should always specify the exact version of the external libraries that you use.” Without it, they write, you cannot reproduce what is in production. In our view, you cannot know whether you are exposed to a vulnerability either.
When a project accepts “any version from this one onwards”, a newly published version enters the application at the next update, without anyone having chosen it. This is currently npm’s default setting (npm), and Composer recommends it for libraries meant to be reused by other projects (Composer). The notation is detailed in the “For your technical team” box below.
Not all new versions are handled the same way. The fix for a serious vulnerability is installed as soon as it is published: waiting leaves the door open. Other new versions can wait a few days, because a freshly published version is where malicious code slips in. In 2018, an attacker took over maintenance of the event-stream package and added code to it that targeted the bitcoin wallets of the Copay application (npm). In September 2025, the account of the maintainer of chalk, debug and some twenty other JavaScript packages was hijacked through a fake password reset email; according to StepSecurity, a cybersecurity company, these packages were then downloaded billions of times a week (StepSecurity). A few days later, the Shai-Hulud worm, which spread on its own from one package to the next, had compromised more than 500 of them; CISA then recommended pinning dependencies to known safe versions released before 16 September 2025 (CISA).
That gives four practices.
Pin the exact version in the file that declares the dependencies. The application then gets a new version when someone decides it, not when it is published. With a lock file committed with the code (next practice), a version range only comes into play at update time. It is therefore not a vulnerability in itself: the exact version is a team rule, which makes every update deliberate.
Keep the lock file with the code. This file records the exact version of every component installed, including the components your components depend on, and the Composer documentation asks for it to be committed with the project’s code (Composer).
Install from this file, and only update by decision. The pipeline installs exactly the versions in the lock file. An update is decided component by component, and tested.
Wait before adopting a freshly published version. The pnpm package manager offers this delay, currently set by default to one day since its version 11, to reduce the risk of installing compromised or defective packages. Its documentation states that malicious releases are usually discovered and removed from the registry within an hour (pnpm). The fix for a serious vulnerability does not follow this delay: it is installed as soon as it is published, once you have checked that it is indeed announced by the vendor or by CERT-FR.
The opposite risk exists too: pinning your versions and never updating them again. By our calculations on W3Techs’ figures, nearly half of PHP sites used, in October 2026, a version the PHP team no longer fixes. An exact version only protects you if updates follow, often, one at a time, and verified. Jez Humble and Dave Farley make it a general principle: “If It Hurts, Do It More Frequently, and Bring the Pain Forward.” An update made every week changes little at a time; an update put off for two years becomes a project.
New vulnerabilities are published every day in code that has not changed. A check run only when a change is made misses the vulnerabilities published in the meantime. Composer, the tool that manages the components of a PHP application, can compare the installed components with the security advisories published on Packagist, the main repository of PHP components, and also reports abandoned components (Composer). Run every day by a scheduled pipeline job, this check reports a vulnerability as soon as its security advisory is published. In Continuous Delivery Pipelines, Dave Farley asks for security to be tested in the pipeline, from the very first stage, and not treated as a separate check.
Once a week, another check lists the components for which a new version exists. This reminder prevents the two-year gap.
An alert does not always call for the same response. Two pieces of information decide how urgent it is. Severity first: most security advisories give a CVSS score, from 0 to 10, which FIRST, the international organisation that publishes this scale, groups into five levels: none (0), low (0.1 to 3.9), medium (4 to 6.9), high (7 to 8.9) and critical (9 to 10) (CVSS 4.0). The PHP2Shell vulnerabilities are scored 9.2: critical. This score compares the severity of one vulnerability with others; it does not measure the risk to your business.
Exploitation next: a vulnerability that is already exploited comes before a more serious one that is not yet. CISA keeps the list of exploited vulnerabilities: it sets deadlines for US federal agencies to fix them, and recommends that every organisation fix them as a priority. FIRST publishes EPSS every day, an estimate of the probability that a vulnerability will be exploited within thirty days. In France, CERT-FR distinguishes its alerts, “intended to warn of an immediate danger”, from its advisories, which report vulnerabilities and the ways to protect against them. PHP2Shell was the subject of an alert.
In practice, a vulnerability that is critical, already exploited or covered by a CERT-FR alert is fixed on the day the fix is published. The others follow the normal pace of updates, one at a time.
These tools have a limit, and PHP2Shell shows it. They examine the libraries the application declares, not the language that runs it. A component check with no alert says nothing about PHP2Shell. The PHP version is monitored separately: the PHP team publishes the list of supported versions and a news feed of its releases; CERT-FR publishes its alerts, and ANSSI asks for new vulnerabilities to be followed through this channel (measure 34). ANSSI also asks for the end of software maintenance to be anticipated (measure 35): PHP 8.2 receives none after 31 December 2026.
A composer.json with exact versions (component names given as examples):
{
"require": {
"vendor/component-a": "2.3.1",
"vendor/component-b": "5.0.4"
}
}
Instead of "^2.3.1", which would accept any version from 2.3.1 up to, but not including, 3.0.0 (Composer). Currently, npm writes ^ by default: ^1.2.3 accepts any version from 1.2.3 and below 2.0.0 (node-semver). For npm, save-exact=true in .npmrc makes it write the exact version by default (npm).
An example GitLab pipeline, given as an illustration to adapt: a check on every push, a daily job and a weekly job, each triggered by its own GitLab schedule (schedules, rules).
# Illustrative example, to adapt to your project
stages: [commit, audit]
.php:
# Your project's image with PHP and Composer, pinned by its digest
image: registry.example/php-composer@sha256:<digest>
commit:
extends: .php
stage: commit
script:
# Checks that composer.json and composer.lock are consistent
- composer validate --strict
# Fails if a component, production or development, has a security advisory
- composer audit --locked
# Installs exactly the versions in the lock file
- composer install --no-interaction --prefer-dist
rules:
- if: $CI_PIPELINE_SOURCE == "push"
daily-audit:
extends: .php
stage: audit
script:
# Same check every day, with no code change; also fails on abandoned components
- composer audit --locked --abandoned=fail
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"
weekly-reminder:
extends: .php
stage: audit
script:
# Lists the new versions available, without failing the pipeline: this is the reminder
- composer outdated --direct
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
composer.lock, or package-lock.json for npm) is committed with the code. The pipeline runs composer install, which installs exactly the versions in this file; composer update recalculates the versions and rewrites the file: it is only for a decided update, for example composer update vendor/component-a (Composer).minimumReleaseAge for pnpm, min-release-age for npm (setting names as of October 2026). For Composer, we advise enforcing this delay through a team rule, or through the tool that proposes updates.composer audit returns a non-zero exit code when a component is covered by an advisory: the job turns red, and that is the alert. --locked reads the lock file, even without a vendor folder (Composer): the example therefore runs the check before composer install, and the job stops before installing a component covered by an advisory. The example also checks development components: they run in the pipeline, which has access to the code and to the deployment secrets.php image, hence the project image in the example.@sha256:…): the Docker documentation states that this guarantees “that the image you’re using is always the same”, and warns that Docker then does not pull updated versions of the image, “which may include security updates” (Docker). Pinning therefore only makes sense with a regular update of the digest, tested by the pipeline.integrity field), and installation fails if the downloaded package does not match. For a script or a stylesheet loaded from another domain, the integrity attribute (Subresource Integrity) makes the browser refuse a modified file (MDN); ANSSI recommends this check for JavaScript and CSS resources, internal and third-party alike, especially those served from a CDN (recommendations R11 and R12). OWASP asks you to enable checksum and signature verification for downloaded packages. Renovate or Dependabot can propose these updates as merge requests; they deploy nothing themselves (Renovate, Dependabot).https://www.php.net/feed.atom) and CERT-FR alerts. Google’s OSV-Scanner currently reads composer.lock and, in a container image, Alpine and Debian or Ubuntu packages: it can spot a PHP installed by the image’s operating system.The NCSC asks every organisation to “apply software updates as soon as possible, and ideally automatically”, because attackers often study a fixed vulnerability to write an attack that exploits it; according to Amazon, quoted above, AI makes this work cheaper. The NCSC points out that vendors test their own updates, while asking organisations to test them on their own systems too and to roll them out in stages. For software you install and use off the shelf (Windows, macOS, a phone, a browser, office software), we therefore advise switching on its automatic updates. For an online service, it is the provider that applies the fixes. A WordPress site falls into neither category: its owner does not develop the software and does not use it off the shelf, but assembles and configures it. Our position is different for a site or an application that you assemble.
WordPress is used, as of October 2026, by nearly four sites in ten, and most of its vulnerabilities are not in WordPress itself. According to Patchstack, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and only 6 in WordPress core. And 46% of these vulnerabilities had not received a fix from their developer by the time they were disclosed (Patchstack). These figures come from a company that sells protection against these vulnerabilities.
Our position is this: we advise against automatic updates of PHP, plugins and themes. We prefer pinned versions, and one update at a time, tested before it reaches production: by the deployment pipeline for a custom-built application, on a copy of the site for a WordPress site, checked by automated tests where possible. This position is not ours alone. In Continuous Delivery, Jez Humble and Dave Farley ask for the exact version of every external library to be specified and for every change to be verified on a production-like environment. OWASP, in its 2025 ranking of the most critical risks to web applications, asks you to “deliberately choose which version of a dependency you use and upgrade only when there is need”, and to “avoid deploying updates to all systems simultaneously”. Its ranking of the risks specific to CI/CD pipelines asks you not to configure tools to always fetch the latest version of a package. The reason lies in the nature of the ecosystem. A WordPress site combines WordPress core, a version of PHP, and plugins and themes written by authors independent of one another. Nothing guarantees that the new version of one plugin works with the version of another, or with the server’s PHP version. Yet an automatic update installs the new version in production without any test having checked that the site still works.
WordPress takes the opposite position by default. At the time of writing (October 2026), since WordPress 3.7, minor core updates install automatically by default (WordPress). For plugins and themes, automatic updates have had to be switched on one by one since WordPress 5.5, and WordPress then runs them twice a day. The same WordPress page opens with this sentence: “To keep your WordPress site secure, you should always update your plugins and themes to the latest version” (WordPress). This gives automatic updates a real advantage: against a median of five hours, measured in 2025, between the disclosure of a heavily exploited vulnerability and its first exploitation, an automatic update applied twice a day is faster than a manual update made once a month.
Our position therefore assumes someone takes care of maintenance. What gets automated is the alerts: an alert when a vulnerability affects the versions in place, an alert when something abnormal happens on the server, a sign that a vulnerability may be being exploited. It is up to a person to decide when to update, then to do it straight away, without waiting. The update itself can be scripted: the administrator starts it in one click, and it is tested before it reaches production, by the pipeline for a custom application, on a copy of the site for WordPress, within the hours that follow. Without this organisation, pinned versions leave the site exposed for longer than an automatic update would.
Two other levers matter just as much. Since, in 2025, nearly half of plugin vulnerabilities had no fix on the day they were disclosed, no update policy, automatic or manual, covers them on that day. Fewer plugins installed means fewer possible vulnerabilities: OWASP, the reference foundation for web application security, asks you to remove unused dependencies, and ANSSI to limit dependencies between software. And a plugin abandoned by its author will never get another fix: it gets replaced.
Finally, WordPress updates only update WordPress. None of them touches PHP. PHP is supplied by the host or by the server’s operating system: that is why the PHP team refers people to the Linux distribution or the vendor that maintains PHP over the long term. Updating PHP for a WordPress site is therefore done at the host, or in the environment used to deploy the site.
For a WordPress site, nothing requires you to handle this maintenance yourself. Cybermalveillance.gouv.fr presents its good security practices for a website as measures “to adopt or have applied by your service provider”. Hosts specialising in WordPress take care of updating the server software, PHP included, and of automatic backups. The WordPress security guide describes the trustworthy host: it “provides the most recent stable versions of all server software”, “provides reliable methods for backup and recovery”, and readily discusses the security measures it offers. Before choosing one, ask whether it updates PHP itself, whether it tests updates on a copy of the site before applying them, and how to restore a backup.
A custom-built application is updated by decision too. The NCSC’s Cyber Essentials scheme leaves the bespoke components of web applications out of its scope, and recommends “robust development and testing” for them. Every update, of PHP or of a component, goes through the deployment pipeline and its automated tests, then reaches production on the day it is published.
Everything changes on the day you have to touch the code. WordPress’s first rule applies to everyone: “Don’t touch WordPress core”, because every update overwrites its files; whatever you want to add or modify goes into a plugin. For a theme, a child theme lets you modify it without touching its code, while still receiving its updates. This custom code, child theme or plugin, is software that you develop. In Continuous Delivery, Jez Humble and Dave Farley ask for everything used to build and deploy the software to be kept under version control, and for every change to go through the deployment pipeline. In practice, this code lives in a Git repository and goes to production through the pipeline, never copied by hand onto the server.
Nobody needs to modify WordPress core. The gap in a standard installation lies elsewhere. Plugins are installed from the admin, without their versions being declared anywhere, and the configuration lives in a single file, the same for every environment. You therefore cannot rebuild, identically, on a test environment, the site that is in production, which is exactly what Jez Humble and Dave Farley ask for. This is the gap that Bedrock, from Roots, fills. It does not modify WordPress core: it wraps it. WordPress, its plugins and its themes become dependencies, installed by Composer at a precise version and locked in composer.lock. The configuration changes with the environment (development, staging, production) through environment variables. The Git repository then contains only the custom code, the configuration and the list of dependencies and, according to Roots, core and plugins can no longer be modified outside the development environment. Roots presents this setup as applying to WordPress the “Twelve-Factor App” methodology, which describes how to build web applications that are easy to deploy and maintain. Updates are then made in the code, one plugin at a time, then go through the pipeline. Bedrock’s default configuration currently disables automatic updates and installing plugins from the admin (config/application.php).
In our view, Bedrock is worth it once a WordPress site is maintained as software: custom code, several environments, a development team, a pipeline. For a site that you configure, and to which you add a child theme or a plugin, it is not necessary. And Bedrock organises the project, nothing more: the quality of the custom code remains the responsibility of those who develop it.
// Bedrock's config/application.php, default configuration
// Disables WordPress automatic updates
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Disables the admin file editor
Config::define('DISALLOW_FILE_EDIT', true);
// Forbids installing or updating plugins from the admin
Config::define('DISALLOW_FILE_MODS', true);
# With Bedrock: update a single plugin, in the code, then go through the pipeline
composer update wp-plugin/plugin-name
Without Bedrock, the WordPress hardening guide advises disabling the admin file editor, which by default lets you modify the PHP code of plugins and themes; it states that this “will not prevent an attacker from uploading malicious files to your site, but might stop some attacks” (WordPress):
// In wp-config.php: disables the admin file editor
define( 'DISALLOW_FILE_EDIT', true );
To update one plugin at a time, WP-CLI, WordPress’s command-line tool, keeps you in control: wp plugin update accepts --version to target a specific version, --patch to take only fixes, and --dry-run to see what would be updated without changing anything (WP-CLI). The WordPress documentation itself cites customisations and prior testing on a staging environment as reasons to disable automatic updates, and asks, before enabling them for plugins, that you be able to roll back to a previous version of your website.
Everything above rests on one capability: putting a fix into production on the same day, without breaking anything. This capability cannot be improvised on the day of the alert. It depends on how the software is delivered day to day.
In our experience, in an organisation where every release to production is a rare operation (one evening a quarter, tests done by hand, several people mobilised), a critical vulnerability arrives as an emergency. You have to put together an urgent fix outside the schedule, gather the people who know how to deploy, redo the tests by hand, book a maintenance window, sometimes get a committee’s approval. The fix becomes a project, and in the meantime the application stays exposed. This delivery pace pushes people to fix things directly on the server, by hand. In Continuous Delivery, Jez Humble and Dave Farley reject this shortcut outright: when a critical defect is found, “Do not, under any circumstances, subvert your process.” They also point out that it is sometimes better to roll back to the previous version than to deploy a fix. A fix made by hand in production is untested, can make the problem worse, and is often recorded nowhere.
With Continuous Delivery, practised as part of an adaptive approach, that is, adjusting the software continuously based on how it is used, the same fix is a change like any other. Jez Humble defines Continuous Delivery as “the ability to get changes of all types, including new features, configuration changes, bug fixes and experiments, into production, or into the hands of users, safely and quickly in a sustainable way” (continuousdelivery.com). Dave Farley specifies that the deployment pipeline is “the ONLY route to production”: every change goes through it, the PHP update as much as the new feature. It goes through the same automated tests, then to production. Because every change follows this path, the procedure is already well practised on the day a fix arrives.
This discipline also changes how the project is managed. A critical vulnerability is not scheduled for the end of the week: it jumps ahead of everything else, the same day. A team that keeps to the discipline of Continuous Delivery can change its priorities within the day, according to what comes up, because nothing in progress blocks the release of the fix.
DORA (DevOps Research and Assessment), Google Cloud’s research programme on how software is developed and released, measures what this practice changes. DORA does not directly measure how long it takes to apply a fix. The closest metric is the lead time for a change, from the moment it is committed to the code to the moment it is in production. In Modern Software Engineering, Dave Farley asks a related question: how long does it take for a single-line change to go from “idea” to “working software”? In our view, that time is also how long it will take to apply the next security fix. DORA’s research has repeatedly shown that “speed and stability are not tradeoffs” (DORA). According to a summary of the 2024 report published by Octopus Deploy, a vendor of deployment tools, the highest-performing teams get a change into production in less than a day, and recover from a failed deployment in less than an hour (Octopus Deploy).
Change approval boards do not make up for slow delivery. In Modern Software Engineering, Dave Farley quotes the research published in the book Accelerate: “approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems […] It is, in fact, worse than having no change approval process at all.”
Security guidance sets a different timeframe. ANSSI, in its 2017 guide, asks for security patches to be applied “within the month following their publication by the vendor”, and allows for possible qualification of the patches and a gradual rollout (measure 34). OWASP, in its 2025 ranking of the ten most critical risks to web applications, warns against this pace: exposure “commonly happens in environments when patching is a monthly or quarterly task under change control, leaving organizations open to days or months of unnecessary exposure before fixing vulnerabilities”. The one-month timeframe dates from 2017, before the time to exploit fell to a few days, and is presented as a maximum. With attacks that sometimes start before the fix is published, it is no longer enough as a goal. The patch verification ANSSI asks for does not require waiting a month: automated tests in the pipeline carry it out on every change.
Speaking at the Economic Club of Chicago, according to Business Insider on 16 October, Jamie Dimon, chairman and chief executive of JPMorgan Chase, pointed to two risks: AI agents acting on their users’ bank accounts, and AI tools uncovering vulnerabilities sooner. To pay on their users’ behalf, these agents need their bank code: “If they can make payments for you, that means you have to give them your bank code […] you’re assuming they’re going to act properly on your behalf, and they may not”. The day before, presenting the bank’s quarterly results, he had warned that JPMorgan would not “allow just any outside agent to come inside the company”. At the time of writing, JPMorgan stops outside AI agents from acting on its retail customers’ accounts and gives them read-only access. According to Benzinga, he also warned that AI tools are uncovering hundreds of serious vulnerabilities in open source code, leaving “industries completely unprotected”.
For the vulnerabilities AI uncovers sooner, Continuous Delivery addresses how long it takes to apply the fix. As early as 2010, in Continuous Delivery, Jez Humble and Dave Farley called for the ability to release a new version quickly “in case critical defects or security holes are found”. They also asked for production to be “completely locked down”, so that only the deployment pipeline can make changes to it. With these practices and those described in the section on the delivery approach, the fix for a vulnerability found by AI goes to production like any other change. In our view, Continuous Delivery shortens the time during which a vulnerability whose fix exists remains exploitable in your systems; finding vulnerabilities and stopping attacks are the job of the other practices described in this article.
The other risk Jamie Dimon describes is a matter of access rights: knowing whether an agent really acts for the person who authorised it, for a bank as for any application. OWASP lists “Excessive Agency” among the risks of AI applications, and the NCSC asks for the principle of least privilege to be applied to agents. If your application lets AI agents act for your users, we advise, as OWASP does, giving them only the minimum rights they need, making them act in the context of the user concerned, and having a person approve high-impact actions.
On the day a vulnerability hits your software, the course of action comes down to eight steps. It draws on four public documents: the guide “What to do in the event of a cyberattack?” from cybermalveillance.gouv.fr, the French public service that assists victims of cyberattacks, written for business leaders; its sheet on website defacement; ANSSI’s IT hygiene guide; and the CERT-FR response sheet that its PHP alert points to. It is better to read these steps before that day and to know who does what.
1. Find out whether you are exposed. Which sites and applications use the affected component, in which version, on which servers, with which host? For PHP2Shell, the question also applies to products that embed PHP without showing it. If a provider or a host manages your site, this is the first question to ask them. Keep a log of every action taken, stored outside the affected system, as CERT-FR asks.
2. Update, or isolate. Complete protection means updating: for PHP2Shell, PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later version of the same branch, or your distribution’s fix. As support for PHP 8.2 ends on 31 December 2026, it is better to move to PHP 8.3 or later. If updating is not possible right away, isolate the applications exposed to the Internet until it is, as CERT-FR and CERT-EU advise.
Watch out for a trap: for PHP2Shell, the maintenance mode of a WordPress site or a Laravel application does not protect against this vulnerability. The vulnerability is triggered while PHP prepares the request, before the site’s code runs. Blocking has to happen before PHP: on the web server or the reverse proxy, which returns a static page, or at network level.
If the server seems compromised, ANSSI gives the right reflex: disconnect the machine from the network, but leave it powered on and do not restart it, so as not to lose the information needed for the analysis (measure 40).
3. Look for signs of intrusion. Amazon advises searching back to at least 17 October, not from the publication date. For PHP2Shell: unusual file upload requests followed by memory errors or repeated 500 errors, abnormally long or malformed session cookies, unexplained PHP restarts (Patchstack). More generally, the signals from the section on monitoring: new files in the site’s folders, programs started by the web server, unknown outbound connections, new administrator accounts. Patchstack recommends treating a targeted server as potentially compromised.
4. Preserve evidence before cleaning up. Cybermalveillance.gouv.fr asks you to collect the logs of the firewall, the reverse proxy and the affected servers, and to make a full copy of the attacked machine and its memory. The guide for business leaders asks you to file a complaint with the police “before any remediation action”. Redeploying a clean version before this copy erases precisely what would make it possible to understand what happened.
5. Change every secret the server held. We advise changing the database passwords, the application keys (WordPress keys and salts, Laravel’s APP_KEY, Magento’s encryption key), the access keys to third-party services (payment, email sending, storage), the messaging accounts, the deployment tokens present on the server, the private keys of certificates and the administrator accounts, and closing open sessions. The new secrets are generated from a clean environment and deployed only to the server rebuilt in the next step, never to the server that is still compromised. CERT-FR asks you to “change potentially compromised secrets”, and cybermalveillance.gouv.fr to change all passwords before going back online. CosmicSting showed it: a key stolen before the fix remains valid after it, and Sansec recommends replacing the encryption key and invalidating the old one. Changing the application key logs all users out; that is expected. Data encrypted with the old key is another matter: it becomes unreadable unless the old key stays available to decrypt it or the data is re-encrypted with the new one. Laravel lets you keep previous keys for decryption (APP_PREVIOUS_KEYS), and Adobe provides for Magento a key change procedure and a command that re-encrypts the data.
6. If the server was compromised, rebuild from a clean source. We advise against restoring the old server image or the old code, which may contain the web shell. With a pipeline, you rebuild the server and the application from the code repository, at a clean version, with the fix. The data, in our view, is restored from a backup taken before the earliest possible date of intrusion. This is where offline, tested backups make the difference. Cybermalveillance.gouv.fr then asks for a gradual return to service, after making sure the vulnerability is fixed.
7. Report. If personal data may have been accessed, altered or destroyed, the incident must be notified to the CNIL, the French data protection authority, within 72 hours, as cybermalveillance.gouv.fr points out. Also notify your insurer of the incident. For support, ANSSI advises calling on a qualified security incident response provider (measure 40 of its guide). In an emergency, the French police and gendarmerie answer on 17.
8. Learn the lessons. Ask the question cybermalveillance.gouv.fr puts at the last step of its guide: what have we learned? How long did it take to apply the fix, and why? That is the delay for which DORA measures the closest indicator, described above: the shorter it is day to day, the sooner after its publication the next fix will be applied. What made it possible, or would have made it possible, to notice the attack?
A security fix is a change like any other: it goes through the same pipeline as everything else. We do not look for vulnerabilities; that research belongs to researchers. Our role is to limit what the next vulnerability will let an attacker reach, to be alerted as soon as it is exploited, and to apply its fix as soon as it is published.
The same team develops, tests, deploys and maintains your software continuously, in the same pipeline. Every production deployment goes through a deployment pipeline: security, performance, accessibility, everything is verified automatically before reaching production. We put one change at a time into production, after it has been checked by the pipeline. If there is an incident, we roll back to the previous version.
For the applications we develop, here is what we set up with a deployment pipeline. Every dependency is pinned to its exact version. A freshly published version is only adopted after three days, except the fix for a serious vulnerability, which is installed as soon as it is published. Every morning, a scheduled job checks whether a known vulnerability affects the components in place. We also set up monitoring of the servers, with alerts on the signals described above. An update of PHP or of a component goes through the same pipeline as everything else.
For custom software development, we work to a fixed budget, invoiced at the end of each month for the work done. Your application is usable within a month, with a few essential features: your users start working with it straight away, and how they use it determines which features come next. Maintenance is included, adaptive maintenance too: dependency updates, security patches, browser compatibility. And to make sure that what worked last month still works this month, we apply a zero-regression guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.
We also offer software production chain audits and training for technical teams. The audit checks whether the practices described in this article are in place in your deployment pipeline and in your software, and what remains to be put in place.
A security update reaches production on the day it is published when every change already gets there in small steps. Our article on Continuous Delivery and Continuous Deployment explains how this works, and our article on the predictive or adaptive approach why this way of delivering belongs to an adaptive approach.
To take over an application whose PHP version is no longer maintained, our application takeover and redesign page explains how we go about it.
Do you have an application to get developed, or to take back in hand? Shall we talk?
DISALLOW_FILE_EDIT).config/application.php file.save-prefix, save-exact, min-release-age).
GTA 6 delayed twice, The Line called into question, Akon City abandoned, public IT projects over budget: why estimates for work never done before do not hold, and how cathedrals were built.
Continuous Delivery and Continuous Deployment differ by a single step. Why a small, frequent change carries less risk than a big one, with the sources to back it up.
What is a feature flag? Four types of toggles, what to try before adding one, and seven anti-patterns that end up running code nobody has tested.