A security weakness first identified by software developers in 2024 remained unresolved until October 2026, when a worldwide emergency forced Scottish councils, NHS health boards and other public bodies to suspend access to websites and online services.
By the evening of 21 October, at least seven of Scotland’s 32 councils and six of its 14 territorial NHS boards had temporarily taken websites offline. The Care Inspectorate, which regulates care services across Scotland, was also among the organisations affected.
Residents encountered unavailable council websites, interrupted online transactions and difficulties accessing public information. In Orkney, the council subsequently warned that its MyOrkney platform could not process payments or provide access to online forms while its external software supplier carried out urgent security work.
The interruptions were precautionary. They did not establish that Scottish council or NHS systems had been successfully attacked.
However, information released by the organisations responsible for the affected software reveals a more serious underlying issue. The PHP Foundation, which supports development of the programming language at the centre of the emergency, has acknowledged that developers had recognised signs of the underlying problem two years earlier but struggled to agree and implement a permanent solution.
Its explanation, published on 21 October, described the delay as a “structural failure” involving its decision-making processes and limited resources.
There was a second troubling development. Amazon’s security researchers reported detecting attempted exploitation of the vulnerability on 17 October, four days before the public disclosure and emergency software updates.
These disclosures place Scotland’s temporary public-service shutdowns within a much larger question about the security and resilience of the technology on which modern government depends.
The Scottish Services That Went Offline
The disruption began on Wednesday 21 October, as website administrators across the world responded to an urgent warning concerning two critical security vulnerabilities in PHP, a programming language widely used to operate websites and internet applications.
In Scotland, affected council websites included those serving Edinburgh, Highland, Argyll and Bute, East Lothian and Midlothian. Other public bodies, including NHS organisations and the Care Inspectorate, also temporarily restricted access.
Contemporaneous reporting identified at least seven local authorities and six territorial health boards that had suspended websites by Wednesday evening. The figures describe the number of authorities affected at that point, not the number of individual public services or computer systems unavailable.
For residents, the consequences varied according to the services operated through each website. Losing access to an information page is different from being unable to submit a housing application, make a payment or complete a time-sensitive transaction.
In Orkney, the problem extended to the council’s MyOrkney customer platform. On 22 October, Orkney Islands Council confirmed that the system, provided by the American technology company Granicus, was unavailable while the supplier applied security updates.
The council advised residents that online payments and forms could be affected. Telephone, email and staffed customer service offices in Kirkwall and Stromness remained available as alternatives.
Granicus confirmed that it had deliberately suspended affected services as a precaution. It subsequently reported that its services had been restored by 2pm on 22 October and that it had identified no breach or malicious exploitation affecting its products.
The shutdowns were therefore part of an effort to prevent potential attacks, not evidence that attackers had already taken control of Scottish government systems.
The Software Problem Had Been Recognised Two Years Earlier
The vulnerabilities were designated CVE-2026-109618 and CVE-2026-109619. Both received a critical severity score of 9.2 under version 4.0 of the Common Vulnerability Scoring System.
They involved errors in PHP’s handling of computer memory. Under certain circumstances, an attacker could manipulate the errors to execute commands on a vulnerable server without first obtaining legitimate login credentials.
Successful exploitation could potentially give an attacker access to information stored or processed by the affected server, permit unauthorised changes or allow further malicious activity.
The scale of the problem reflected PHP’s widespread use. It forms part of the underlying technology supporting many websites and content-management systems, including WordPress, Drupal and Joomla, as well as commercial applications supplied to governments and businesses.
But the vulnerability was not entirely new to the people responsible for maintaining PHP.
In 2024, the PHP Foundation arranged an external security audit funded by Germany’s Sovereign Tech Agency. The audit was conducted by French cybersecurity company Quarkslab.
While addressing issues identified during that work, a PHP developer working under contract to the Foundation discovered signs of the memory-handling problem that would later become one of the October 2026 vulnerabilities.
At the time, developers considered the possibility that the problem could be exploited. However, they had not established a working method of turning it into an attack, and other security issues with clearer immediate consequences received priority.
The Foundation explained that several possible fixes had been considered. Each presented difficulties, including the risk of breaking existing software, introducing different vulnerabilities or requiring extensive changes to third-party extensions.
Its security team operated through a consensus-based decision-making process, and developers could not agree which approach offered an acceptable balance of security and compatibility.
The Foundation also acknowledged that relatively few developers possessed the specialist knowledge needed to make changes to PHP’s core systems, while those individuals already had substantial responsibilities.
Work on the problem consequently stalled and restarted over a period of months.
The important distinction is that developers in 2024 had identified an underlying weakness, not the full range of practical attacks demonstrated in 2026. Nevertheless, the weakness remained unresolved while millions of websites and applications continued to depend on PHP.
Artificial Intelligence Helped Establish the Full Danger
The situation changed during the summer of 2026, when additional security researchers examined the problem with assistance from advanced artificial intelligence tools.
On 30 July, security company Calif began an examination of PHP through OpenAI’s Patch the Planet programme.
On 11 August, a Calif researcher reported a working remote-code-execution attack involving the same underlying memory problem identified in 2024.
OpenAI independently reported the same root cause. Researchers at Wiz, a cybersecurity company owned by Google, also identified vulnerabilities and developed attacks against common website systems.
Wiz reported that its researchers had used its Atlas security system together with advanced AI models to analyse the PHP code and demonstrate that attackers could exploit the weaknesses.
By 24 August, Wiz had reported its findings to PHP’s security team. Further research established that the vulnerabilities could affect different PHP configurations and applications.
The PHP Foundation stated that the reports from Calif, OpenAI and Wiz established the full potential consequences of the earlier memory problem. From 11 August, resolving it became a priority for its security developers.
The case demonstrates how AI-assisted research can identify complex weaknesses that have remained difficult to investigate through conventional methods. It also creates a difficult security problem: once the methods of exploitation become understood, attackers may be able to use similar tools to adapt attacks against systems that have not yet been updated.
Attempts to Exploit the Flaw Were Detected Before the Public Warning
The coordinated release of emergency fixes had originally been planned for 22 October. That timetable changed after information concerning the vulnerabilities began circulating online.
On 20 October, the vulnerability identification numbers appeared on social media and security forums. Although the initial information did not contain complete technical details, it prompted the PHP security team to advance its announcement and software release.
The PHP Foundation also reported that Calif had mistakenly published a video demonstrating its research. Copies circulated after the original was removed, helping accelerate development of experimental attacks.
The security team moved the release of its fixes forward to 21 October, allowing software distributors and website operators to begin emergency updates.
Amazon’s security researchers subsequently disclosed that they had detected an apparent attempt to exploit the vulnerability on 17 October.
The activity was observed by Amazon’s MadPot network, which uses specially configured systems to identify and investigate malicious internet activity.
Further attempts were recorded on 21 October, including activity before the coordinated software release.
Amazon said it was unclear how the individuals responsible had obtained information about the vulnerability before public disclosure. It also cautioned that attempts observed against its monitoring systems did not establish whether the same techniques would have succeeded against real-world targets.
The distinction is important. The findings provide evidence of attempted exploitation before the public warning, not proof that Scottish public bodies were breached.
Nevertheless, the timing demonstrates why security agencies treated the situation as urgent. By the time website operators received their public instructions, there was already evidence that the vulnerability was attracting hostile attention.
Why Government Websites Had to Be Taken Offline
On 21 October, the United Kingdom’s National Cyber Security Centre issued an urgent advisory directing organisations to identify their PHP installations and apply newly released security updates.
Four updated PHP releases were made available to address the vulnerabilities across supported versions of the software.
The agency advised operators to prioritise internet-facing systems, including those used by members of the public to access online services.
Where updates could not be installed immediately, organisations were directed to consider temporary protective measures. If adequate protection was not possible, the agency advised taking the affected system offline until the vulnerability could be addressed.
For councils and other public bodies, that created an immediate operational choice. Keeping an affected service available could expose its systems to a potentially serious attack. Suspending access could inconvenience residents and interrupt normal administrative transactions.
On 22 October, the UK Government confirmed in the House of Lords that 32 central government services were unavailable and another four were partially unavailable during the wider emergency.
Those figures referred to UK government services and should not be confused with Scotland’s 32 local councils.
Responding to questions, minister Baroness Lloyd of Effra said the interruptions had arisen largely from precautionary action taken while security updates and protective measures were applied.
The scale of the response indicated how widely the underlying technology was used across government, including services operated directly and those dependent on external providers.
Orkney’s Own IT Report Identified Dependence on Suppliers
Documents published by Orkney Islands Council before the October disruption provide additional insight into the challenges faced by local authorities maintaining complex digital systems.
On 1 September 2026, the council’s Asset Management Sub-committee received an update on its Information Technology and Cyber Security Strategy for 2025 to 2029.
The report covered network security, disaster recovery, computer equipment, website infrastructure and the management of vulnerabilities affecting externally supplied systems.
Under the section dealing with third-party vulnerabilities, the council reported that it scanned internal systems weekly to identify security risks.
However, it also acknowledged that remediation was only partly in place and that some corrective work depended on vendors supplying security updates.
The action was classified green in the council’s delivery plan, despite the accompanying explanation that remediation was incomplete. The rating indicated the council’s reported progress on the workstream; it was not confirmation that every system had been fully secured.
The report proposed continuing work with system owners, administrators and vendors to improve the process of applying updates and ensuring that newly purchased systems remained supported.
It separately identified weaknesses in the resilience of the council’s webserver infrastructure. Replacement equipment had been purchased and installed, but the migration of webservers had been delayed by workload pressures and was scheduled for completion in December 2026.
These findings do not establish that the council’s internal systems caused or contributed to the MyOrkney interruption. Granicus attributed that interruption to its own precautionary action over the global PHP vulnerabilities.
They do, however, document the extent to which maintaining secure council technology requires continuing work with outside suppliers and the management of multiple systems that may be at different stages of updating.
The same report recorded improvements elsewhere, including an operational disaster recovery data centre at Scapa, enhanced backup arrangements and new security monitoring equipment.
Such measures strengthen locally managed infrastructure. They do not necessarily allow a council to restore an application that an external company has temporarily suspended for security reasons.
East Lothian’s Instructions Reveal Another Layer of Responsibility
East Lothian Council’s employee communications provide another example of the practical consequences of the security emergency.
In its October 2026 staff bulletin, the council advised employees that its intranet had been taken offline while a necessary security update was carried out.
Staff were given alternative routes to essential internal services, including personnel and training systems.
The council also issued instructions to employees responsible for online systems purchased from outside suppliers where no council system administrator had been assigned.
Those employees were told to contact their suppliers to establish whether the applications used PHP, whether vulnerable versions were present, what security fixes were available, when those fixes could be deployed and whether any action was required from the council.
The responses were to be recorded with the council’s IT service desk as a priority.
This illustrates a significant feature of modern local-government technology. Security responsibility is not confined to a single council IT department or central computer network.
Individual departments may purchase and operate specialist applications supplied by different companies. Those applications can contain software components that are not visible to everyday users, while updates remain under the control of the supplier.
When a serious vulnerability is discovered in a widely used programming language, the council must identify not only the technology it manages directly but also any exposure within externally purchased products.
East Lothian’s instructions demonstrate the administrative work required to establish that information during an emergency.
A Wider Problem Than One Software Supplier
Orkney’s disruption involved Granicus, a Denver-headquartered government technology company that acquired British digital-services provider Firmstep in 2019.
However, the wider Scottish shutdowns cannot all be attributed to Granicus. The underlying vulnerabilities were present in PHP itself, which is used by numerous commercial suppliers, public bodies and independently operated websites.
This distinction is central to understanding what happened.
A council may purchase a digital service from a British or international company, but that company may rely on open-source programming languages maintained by developers elsewhere in the world.
That software may then be operated through additional layers of hosting, cloud computing, security services and network infrastructure.
Each layer can have different maintenance responsibilities and different arrangements for responding to newly discovered vulnerabilities.
The PHP Foundation has acknowledged that maintaining the security of such a widely used language depends on a comparatively small number of specialist developers, supported through foundation funding and some voluntary contributions.
It has also outlined changes to its security processes, including additional engineering resources, greater use of automated analysis and a revised approach to resolving disagreements over fixes.
The episode illustrates the dependence of public services on technology that may be free to use but still requires substantial resources to maintain securely.
What Has Not Yet Been Established
Although the security patches have been issued and Granicus has reported restoring its affected services, several important aspects of the Scottish disruption remain undocumented in the public material examined.
There is no consolidated, independently verified Scottish record establishing the number of online transactions interrupted, the full duration of every council outage, how many residents were affected or the administrative cost of restoring the services.
Nor has a complete inventory been identified showing which Scottish local authorities use common digital suppliers, which services depend on the same underlying software and what contractual arrangements govern the restoration of essential applications.
For Orkney, the publicly available announcement established that MyOrkney payments and forms were affected and that alternative contact methods were available. It did not quantify the number of attempted transactions or establish whether any payments or applications were delayed beyond the interruption.
For the wider NHS, the confirmed disruption concerned public-facing websites. The information reviewed does not establish that clinical care, patient records or emergency treatment systems were compromised.
Those distinctions are necessary when assessing the incident. A temporary website shutdown is a service interruption, but it is not evidence of a successful intrusion, loss of confidential information or failure of clinical systems.
The Test for Scotland’s Digital Public Services
The October emergency exposed two separate weaknesses in the way essential online services are maintained.
The first lay within the software development process. The PHP Foundation has acknowledged that an underlying security problem identified in 2024 remained unresolved because its developers could not readily agree on a fix and lacked sufficient specialist resources.
The second concerns the ability of public authorities to maintain services when a serious vulnerability affects technology operated by outside suppliers.
For Scotland’s councils, the issue is not simply whether a supplier responds correctly to a security warning. Taking vulnerable systems offline can be an essential protective measure.
It is whether councils know which services depend on those systems, can identify their exposure quickly, have reliable alternatives for essential transactions and can account for the consequences of an interruption.
Orkney’s council reports and East Lothian’s staff instructions demonstrate that these responsibilities extend beyond the maintenance of ordinary council websites.
As public authorities move more payments, applications, records and communications into digital systems, the ability to continue delivering services during security emergencies becomes as important as preventing attacks in the first place.
The unanswered question for Scotland’s public sector is how consistently those continuity arrangements have been established, tested and made accountable across its councils and other public bodies.
Sources
Today’s PHP Security Release, and How We’re Strengthening PHP Security. The PHP Foundation, 21 October 2026.
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
PHP Security Advisory and Security Releases. PHP Development Team, 21 October 2026.
https://www.php.net/archive/2026.php
Critical Security Issue Affecting PHP. National Cyber Security Centre, 21 October 2026.
https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
Amazon Threat Intelligence Identifies PHP2Shell Exploitation Prior to Public Disclosure in MadPot. Amazon Web Services Security Blog, 21 October 2026.
https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
PHP2Shell: AI Uncovers Critical Remote Code Execution Vulnerabilities. Wiz Research, 21 October 2026.
https://www.wiz.io/blog/php2shell-php-rce
Cyber Security: PHP Vulnerability. House of Lords, Hansard, 22 October 2026.
Read the parliamentary record
Temporary Unavailability of the MyOrkney Platform. Orkney Islands Council, 22 October 2026.
https://www.orkney.gov.uk/latest-news/temporary-unavailability-of-the-myorkney-platform
Information Technology and Cyber Security Strategy – Delivery Plan. Orkney Islands Council, Asset Management Sub-committee, 1 September 2026.
Read the council’s security report
October 2026 Staff Bulletin: Intranet Offline and Advice for Staff Who Have Purchased Online Systems. East Lothian Council, October 2026.
Read the council staff bulletin
Critical PHP Vulnerabilities: What Government Needs to Know. Granicus, October 2026.
https://granicus.com/uk/blog/critical-php-vulnerabilities-what-government-needs-to-know/
Scottish Councils and Health Board Websites Taken Offline After Global Security Threat. STV News, 22 October 2026.
Read the report
