Why we took eLabFTW offline during the PHP security emergency
On 21 October, we made a decision that no hosting provider enjoys making: we temporarily suspended access to our hosted eLabFTW instances.
Not because the servers had stopped working, but because keeping them accessible carried a security risk we were not willing to take with your research data.
Two critical vulnerabilities in PHP had turned an ordinary Wednesday into an emergency across the PHP ecosystem. We warned our community, put preventive measures in place before the patches were released, and ultimately took the services offline until we could deploy the fix.
Access was restored that evening, at approximately 22:00 CEST.
Here is what happened, what we did, and why.
All times below are in Paris time (CEST, UTC+2), unless stated otherwise.
1. The warning signs appeared before the patches
On 20 October, information about two critical PHP vulnerabilities started circulating ahead of their coordinated disclosure.
As the PHP Foundation later explained, the initial leak concerned the vulnerability identifiers. A prematurely published demonstration video subsequently revealed additional, limited details. The PHP project brought its release forward by a day.
The official announcement scheduled the security release for 21 October at 16:00 CEST.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affected PHP itself, the runtime used by eLabFTW. Under exploitable conditions, they could allow an attacker to execute code on a server without authenticating.
This was not a bug in an eLabFTW feature. But a vulnerability in a component we depend on is still our responsibility to respond to.
And with information circulating before a fix was publicly available, waiting quietly for the release was not a sensible option.
2. We warned people early
We started sharing warnings in our Matrix community chat, so that people running their own eLabFTW installations could prepare before the security release.
We also contacted our customers by email. Hosted customers needed to know what we were doing on their behalf. On-premise customers needed actionable information for the systems they manage themselves.
As the situation developed, we explained the upload restrictions, the expected emergency update, and then the decision to suspend public access. We also displayed a warning banner on hosted instances, so users encountering a blocked upload would know why it was happening.
The aim was straightforward: nobody should have to discover a security emergency through a failed upload or an unexplained error page.
Communication was part of the response, not something to leave until everything was over.
3. We reduced exposure before the patch was released
Several hours before the scheduled release, we began blocking multipart requests at our HAProxy reverse proxies.
Multipart requests are commonly used for file uploads. Rejecting them at the proxy meant that matching requests were stopped before they reached PHP, rather than relying on the application to reject them later.
That distinction matters. Some affected processing can happen before an application checks whether the user is logged in. Requiring an eLabFTW account is therefore not, by itself, protection against this kind of runtime vulnerability.
We also added a PHP configuration change to disable the built-in session upload-progress feature, through pull request #7634.
These were targeted precautions based on the information available at the time. The CERT-FR alert discussed both measures, while warning that disabling upload progress only reduced the attack surface for one of the two vulnerabilities.
For our users, this meant that uploads and some import operations were temporarily unavailable, while much of eLabFTW remained accessible.
We did not wait for a patch to start protecting the service. But we also did not mistake a mitigation for a complete fix.
4. The patch arrived, but deployment was not immediate
At 16:00 CEST, PHP released the security fixes.
That was an important milestone, but it did not mean every downstream application could immediately deploy them.
Our eLabFTW containers use PHP packages provided by Alpine Linux. Before we could publish and deploy updated containers through our normal build process, we needed those packages to contain the fixes.
The packages we needed were not immediately available. That left a gap between the upstream PHP release and our ability to deploy patched containers.
Meanwhile, the full advisories made something clear: these were problems in PHP’s memory management and request lifecycle, not simply bugs in one upload feature. Blocking multipart requests addressed important known attack paths, but it was not a complete answer to both vulnerabilities.
We were left with a choice: continue operating with partial protection, or remove public access until the patched runtime could be deployed.
5. We chose to take the services offline
We decided to temporarily block all public access to our hosted eLabFTW services at HAProxy.
Visitors received a maintenance page explaining the security situation. The proxy generated that response itself, without passing those requests to the application.
This was a deliberate precaution, not a response to a confirmed compromise.
We knew it would interrupt work. An electronic lab notebook is not an optional extra in the middle of an experiment, and we do not dismiss the inconvenience of losing access to it.
But the alternative was to keep accepting public traffic while relying on measures that could not rule out every exploitation path.
We preferred a few hours of disruption to taking an uncertain risk with research data.
We emailed hosted customers to explain the decision. We also advised on-premise customers with publicly exposed, unpatched instances to take the same precaution: temporarily stop the service or block public access at their firewall or reverse proxy.
There was no benefit in pretending that the original upload restrictions were sufficient once the available evidence no longer supported that conclusion. We adjusted our response as we learned more.
6. We rebuilt, deployed and restored access
Once the necessary patched packages were available, we rebuilt and deployed the updated eLabFTW containers. Hosted services were restored at approximately 22:00 CEST.
The emergency releases for self-hosted installations were eLabFTW 6.0.9 and eLabFTW 5.6.15.
The older 5.6 branch needed additional work. Its Alpine 3.23 base did not provide the updated PHP package we needed, so we moved it to Alpine 3.24 and fixed the resulting build-tool compatibility issue.
Although 5.6 was no longer officially supported, we made an exception because of the severity of these vulnerabilities. Organizations still on that branch needed a way to apply the security fix without first completing a major-version migration.
That exception does not replace the need to upgrade to 6.0, but it provided an immediate path out of this particular emergency.
Was taking the services offline the right decision?
We believe it was.
Subsequent reporting supports the concern that the period before the patch was released was already an exposure window, not just a preparation window.
According to ELLIO’s analysis of the activity observed by its sensors, the first exploit-related request arrived at 08:36 UTC, or 10:36 CEST, more than five hours before the official patch release. Their report also describes further attack activity later in the day.
This is evidence of attempts, not proof that those attempts successfully compromised servers. It also does not establish that our own infrastructure was targeted or that it would have been compromised without our intervention.
What it does show is that the concern was real: people were already probing these attack paths while administrators were still waiting for a fix.
Our response did not depend on waiting for evidence of damage. We warned users early, restricted the known attack surface, and then suspended access when we could no longer justify leaving an unpatched runtime publicly reachable.
That is the kind of decision we believe a hosting provider should make.
What did we find in our logs?
Our review of server logs has not identified any indicators of compromise or evidence of successful exploitation of these vulnerabilities on our infrastructure.
That is reassuring. However, the absence of such indicators cannot prove that no malicious activity occurred, and we do not want to turn a careful assessment into an absolute guarantee.
Based on the evidence available at the time of writing, we have not identified a compromise.
What this incident reinforced
The first lesson is that a security response starts before deployment. Reading the advisories, understanding which parts of the infrastructure are exposed, communicating with users, and applying temporary controls all matter while a patch is still on its way.
The second is that an upstream release and a deployable update are not the same thing. Distribution packages, container builds and compatibility checks sit between the two. That gap needs its own response plan. In this case, ours included temporarily removing public access.
The third is that availability cannot be the only measure of a well-run service. We want eLabFTW to be available whenever you need it. But keeping a service online at any cost is not the same as looking after the people who trust it with their data.
We are sorry for the disruption this caused, and grateful for our customers’ patience.
We also want to acknowledge the work of the PHP developers, security researchers and distribution maintainers who delivered the fixes. The PHP Foundation’s account gives useful context on the technical challenges and the resources needed to maintain the software so many of us depend on. The CERT-EU advisory and CERT-FR alert provide additional guidance.
Running eLabFTW? Make security response part of the plan
Installing an electronic lab notebook is one task. Keeping it maintained, following security developments and responding when a critical dependency needs an emergency update is an ongoing responsibility.
For organizations running eLabFTW themselves, Deltablot PRO Support provides direct access to the team behind the software, including technical guidance and assistance with upgrades.
For organizations that prefer us to manage the infrastructure, Deltablot PRO Hosting includes maintenance, updates, monitoring and backups. During this incident, that also meant assessing incomplete information, applying preventive measures, communicating with users, and making the decision to suspend access until we could deploy the fix.
Our public security information and updates remain available to the whole community. A support or hosting subscription adds something different: a team you can turn to, or delegate the operational work to, when it matters.
No service can promise that vulnerabilities will never happen. What matters is having a clear plan and people ready to act.
Explore our eLabFTW support and hosting plans to give your research data the ongoing attention it deserves.