MyDispense uses a programming language called PHP, which is a common web technology used to deliver the MyDispense platform. On the 20th of October 2026 the The PHP Foundation Security team gave notice of an upcoming critical security release, with a release date of 21st October 2026 at 1400 UTC. Due to the severity of the security issue and the possibility of Remote Code Execution (RCE) we took the precautionary measure of shutting down all of our PHP based sites, including all MyDispense production systems.

This resulted in downtime of around 24 hours for most users. We took these measures to protect our sites until we could be sure that patches were in place. Our priority was to avoid the risk of RCE occurring on our systems. RCE allows for an attacker to execute arbitrary code on a target system, which could result in data exfiltration, further unauthorized access to other services on the system or installation of malicious systems.

This post is a timeline of our response and restoration. Dates and times are given in Australian Eastern Standard Time. Note that the initial blog post on 20th of October was posted on the 21st of October Australian time.

21/10/2026 1400-1600 AEST

We first learned about the exploits when our lead developer, Keenan was alerted by industry contacts. The alert, from a security researcher depicts examples of multiple PHP projects vulnerable to RCE, with examples of a file being written to the public file system of the target.

There was limited information at this stage and we were trying to find as much information as we possibly could. A temporary mitigation was noted, where a PHP.ini setting can be set. We immediately deployed the PHP ini change and set session.upload_progress.enabled = Off .

PHP is not one single application, in fact there are very many versions of PHP for different operating systems, server architectures etc. The information from the PHP Foundation at the time indicated that only the most recent versions (PHP versions 8.2+) were going to get updates for these vulnerabilities. The PHP Foundation team supports some other projects which are on older versions of PHP. We explored if we could quickly upgrade them to a supported version of PHP and were unsuccessful. Therefore, those sites were disabled.

21/10/2026 1600-1830 AEST

At this stage more news was breaking that various governments and cybersecurity agencies recommended shutting down any PHP site. The previous session.upload_progress.enabled mitigation was described as not enough by a PHP security team member:

“INI settings alone won’t protect you. You need to patch PHP”.

The MyDispense team had an emergency meeting and the decision was made to shut down all of our sites running PHP. This shutdown occurred at 1633 AEST / 0530 UTC. Our initial shut down was to stop NGINX on all of our servers. NGINX is the web server software we use (when you access a website over the internet, a web server initially processes that request). With NGINX shut down, web requests made to all MyDispense sites returned a server not available message.

NGINX is the system that routes requests to PHP and executes PHP via PHP-FPM. Thus, shutting it down was the fastest option, preventing access to PHP and any potential exploits from running.

Keith sent out an email to all users about the outage. Some folks managed to email us regarding access problems before he could send this email out. Our apologies, we were working very quickly. Kaan started work on a notice page that we could host and we prepared to host it on notice.mydispense.site.

Displaying the notice for all sites was not trivial (the need to display an emergency global message to our users was unprecedented). We devised a series of scripts that would take the NGINX config for MyDispense on each site, back it up, then modify it to redirect requests to notice.mydispense.site without touching PHP.

The reason we had to do this is because we force all HTTP requests to our sites to be redirected to HTTPS via permanent 302 redirect. Thus, if we replaced the NGINX config with a quick http-only temporary redirect, most browsers having only cached the 302 permanent redirect would attempt to access the site on HTTPS and it would display an error message instead of the notice we wanted to display to our users.

Thus modifying the original NGINX config and stripping out any PHP configurations (eg fastcgi pass) to prevent execution of PHP and hosting the redirect on HTTPS was necessary. We got the redirect message in place at 1810 AEST and all MyDispense production servers were hosting it:

At this stage we had taken as much action as we could until the PHP updates were released. We continued to monitor the situation.

22/10/2026 0100-0500 AEST

The PHP updates were released at 0100 as expected. However, the release of the updates did not immediately translate to them being available on our platforms. We manage 280+ MyDispense production servers and they run on a mix of architectures (ARM and x86). Thankfully due to work on our part, our servers all run the same version of Ubuntu LTS.

Normally PHP updates are not a problem. However, due to the emergency nature of these updates we wanted to update ASAP and get our sites back online. For the latest updates to PHP we use a PHP repository for Ubuntu maintained by Ondřej Surý (a legend in the PHP community) and he was (still is at time of writing) very actively compiling the updates and responding (https://codeberg.org/oerdnj/deb.sury.org/issues/145).

It soon became apparent that he did not get the updates until everyone else and had started compiling his packages once the release came out. We have learned a lot about how these packages get compiled and there are many many permutations that need to be put together, different Operating System versions, Architectures and PHP versions. It was soon reported that ARM64 builds (which we use on the majority of our servers) can take upwards of 5 hours to compile.

At 2am, Keenan continued to monitor the compilation process. He also prepared scripts for the eventual patch deployment and to restore MyDispense when a patched version of PHP was on the server and NGINX was configured to use it. The valid versions of PHP were 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The script would effectively read what was in use by NGINX and check the output of php -v (to get the version number) before restoring MyDispense and allowing PHP to run on the servers again.

We continued to update the notice on notice.mydispense.site as the situation developed. We also tried swapping to Ondřej’s newly updated package repository as it was indicated packages would be available there first. At 5am AEST, Keenan was eventually able to get some rest.

22/10/2026 0700-1000 AEST

At 0700 Keenan checked whether the ARM updates were available and confirmed they were not (only x86 updates were available). The team started exploring the possibility of migrating some servers to an x86 architecture to restore sites on a case by case basis. This was tested on our Monash sites due to exams being run on 23/10/2026. The tests were successful and two sites were restored to service with patched versions of PHP.

However, it was determined that due to DNS propagation it would be better to hold off and wait until we could patch our existing servers. The two sites we migrated run on static IPs which we rarely use so we could swap the underlying site out very quickly. DNS propagation can take more than 24 hours in some cases, so if we moved the server to an x86 configuration some users may not be able to access it longer than the outage, so long as the outage was not more than another 12 hours or so.

The MyDispense team continued to monitor the situation and check for updates.

22/10/2026 1400-1700 AEST

While monitoring the situation we checked if the packages were available on the original Launchpad repository for PHP. They were! We checked that the correct version was available. At this point we deployed a new script that would revert the package repository changes made overnight, install the PHP updates and check that a patched version was deployed on the server.

This worked and we were able to start bringing sites back up around 1530 AEST. We updated the notice that we were restoring service and began rolling out the script to bring services back. We finished this step at 1625 AEST and updated the notice to tell people to re-load their MyDispense site.

The MyDispense outage was between 21/10/2026 1633 to 22/10/2026 1625 AEST, just under a total of 24 hours.

Summary

Our decision to shut down all MyDispense sites at 1633 on 21/10/2026 was a good decision. Converted to UTC this is 0530 21/10/2026.

At 21/10/2026 at 0741 UTC, a company broke the release embargo for the security fixes and about 30 minutes after that security researchers indicate PHP Shell attacks were occurring in the wild.

Before that point there is some evidence that PHP Shell attacks been attempted but were not successful. A scan of access logs on some of our sites reveal that MyDispense was not targeted. We did not restore any of our sites before they were patched and our sites were down before the irresponsible release occurred at 0741 UTC.

We will continue to monitor the situation. If you have any questions, please email us at mydispense1@monash.edu