Cyber Brief: Supply chains, zero-days, and AI agent risk

Today's stories share a common thread that will resonate with many UK security and IT teams: the risks that come from trusting the tools, platforms and services you rely on every day. From a widespread supply chain attack targeting GitHub repositories to a managed services platform taken offline after the disclosure of dozens of vulnerabilities, the theme is one of inherited risk — the security exposure that arrives not through your own systems, but through the software and services you depend on. Alongside these, a newly patched Chrome zero-day and a researcher's findings about UK government websites serve as useful reminders that both browser hygiene and basic code security practices remain areas worth revisiting.

Supply chain attack compromises tens of thousands of GitHub repositories

Security researchers have identified a malicious workflow affecting tens of thousands of GitHub repositories, including those owned by Uber, according to reporting by Infosecurity Magazine. The attack targets GitHub Actions workflows — automated processes that many development teams use to build, test and deploy software. By compromising these workflows, attackers can inject malicious code into software at the point it is being built, meaning the resulting applications may carry hidden threats that are difficult to detect downstream. The scale of the campaign, affecting repositories across multiple organisations, suggests this is not a targeted operation but a broad, opportunistic attack designed to reach as many codebases as possible.

For UK businesses, this is a significant concern because GitHub is one of the most widely used platforms for software development, and many organisations — whether building their own software or relying on open source components — will have some exposure to affected repositories. Supply chain attacks of this kind are particularly challenging because the compromise happens before code reaches your environment. Organisations that consume open source packages, use third-party libraries or rely on automated build pipelines may be unknowingly running code that has been tampered with. The inclusion of Uber-owned repositories in the affected set also highlights that large, well-resourced organisations are not immune.

Why it matters

For UK businesses with software development teams or those consuming open source packages, this is a prompt to review your GitHub Actions workflows and audit any third-party dependencies used in your build pipelines. Consider whether your development processes include integrity checks on build outputs and whether you have visibility into the provenance of the code your teams are deploying.

Source: Infosecurity Magazine

N-able takes N-central cloud offline after 33 zero-days disclosed

N-able, a major provider of remote monitoring and management software used by managed service providers (MSPs), has taken its hosted N-central environment offline and is urging on-premises customers to shut down their servers until further notice, according to The Hacker News. The action follows the public disclosure of more than 30 vulnerabilities, collectively tracked as Able2Shell, by a security researcher who also published proof-of-concept exploit code. The sheer volume of disclosed vulnerabilities, combined with the availability of working exploit code, left N-able with little choice but to act swiftly to protect customers while patches are developed and deployed.

N-central is used by MSPs to remotely manage the IT infrastructure of their clients, which means the potential blast radius of these vulnerabilities extends well beyond N-able's direct customers. If an attacker were to exploit these flaws before patches are available, they could potentially gain access not just to an MSP's own systems, but to the networks of every organisation that MSP manages. This is precisely the kind of supply chain risk that has made MSP-targeting attacks a growing concern in recent years. UK organisations that use managed IT services should be asking their providers directly whether they use N-central and what steps are being taken in response.

Why it matters

For many organisations, this is a prompt to contact your managed service provider and ask whether N-central is part of their toolset, and if so, what mitigations are in place while the platform remains offline. More broadly, it is worth reviewing what access your MSP has to your environment and whether that access is appropriately scoped, monitored and auditable.

Source: The Hacker News

Google patches eighth actively exploited Chrome zero-day of 2026

Google has released a security update for Chrome to address nine vulnerabilities, including one — tracked as CVE-2026-125350 — that is already being actively exploited in the wild, according to SecurityWeek. The vulnerability is a use-after-free bug in Chrome's XML component, a class of memory-related flaw that can allow attackers to execute arbitrary code on a victim's device. The flaw was reported anonymously on 6 November and a patch followed within days, reflecting Google's established process for handling zero-day disclosures. This is the eighth actively exploited zero-day patched in Chrome so far in 2026, a figure that underlines how consistently the browser is targeted by attackers.

Chrome is one of the most widely deployed applications in the world, and its prevalence in UK workplaces makes browser patching a routine but genuinely important security task. Use-after-free vulnerabilities are particularly concerning because they can be triggered simply by visiting a malicious web page or interacting with crafted content — no additional user action is required beyond browsing. The frequency of actively exploited zero-days in Chrome this year is a useful reminder that browser updates should not be deferred, and that organisations relying on manual update processes or extended patch cycles for endpoint software may be leaving a meaningful window of exposure.

Why it matters

For UK businesses, this is a prompt to verify that Chrome is set to update automatically across your estate, and to check that your endpoint management processes include browsers as well as operating systems. If your organisation uses a managed browser deployment, confirm that the latest version — 130 or above — is being pushed to devices without delay.

Source: SecurityWeek

Security flaws across UK government sites exposed sensitive information

A security researcher's review of publicly available code has uncovered security flaws across multiple UK government websites that left private information at risk, according to Wired. The researcher's findings, described as exposing what they termed "god-tier" information, were identified through a trawl of publicly accessible repositories and code — meaning the vulnerabilities were discoverable without any privileged access or sophisticated tooling. The findings span multiple government departments, suggesting the issue is not isolated to a single team or system but reflects a broader pattern in how code is managed and reviewed across public sector digital services.

This story is directly relevant to UK organisations beyond central government, because the underlying issue — sensitive information inadvertently exposed through publicly accessible code — is a risk that affects any organisation with development teams, public-facing digital services or cloud-hosted infrastructure. Hardcoded credentials, API keys, internal configuration details and environment variables are among the most common types of sensitive data found in public repositories. The fact that this was identified through publicly available code, rather than a breach of internal systems, is a reminder that exposure does not always require an attacker to break in — sometimes the information is simply left in plain sight.

Why it matters

For UK businesses, this is a prompt to audit your public-facing code repositories — including GitHub, GitLab and any other platforms your development teams use — for inadvertently committed secrets, credentials or configuration data. Tools that scan repositories for exposed secrets are widely available, and establishing a process for regular scanning should be a baseline expectation for any organisation with active software development.

Source: Wired

Today's Key Actions

• Review your GitHub Actions workflows and any third-party dependencies used in your build pipelines; check whether integrity verification is in place for build outputs and open source packages consumed by your development teams.
• Contact your managed service provider to ask whether they use N-able N-central, and if so, what mitigations are in place while the platform is offline; review the scope and auditability of any remote access your MSP holds over your environment.
• Verify that Google Chrome is configured to update automatically across your device estate and confirm that the latest patched version is deployed; include browsers in your standard patch management and endpoint monitoring processes.
• Audit your public-facing code repositories for inadvertently committed secrets, credentials, API keys or configuration data; implement automated secret scanning as a baseline control for any team with active software development activity.
• Confirm that clear ownership exists across your organisation for patch management, third-party supplier security, development security practices and endpoint hygiene — and that each of these areas has a named accountable person who reviews them regularly.

Secarma Insight

What today's stories collectively illustrate is that a significant proportion of security risk in modern organisations does not originate from direct attacks on your own systems — it arrives through the tools, platforms and services that your teams use every day. Supply chain security, managed service provider oversight and development security practices are not niche concerns; they are increasingly central to how organisations manage their overall risk posture. The organisations that handle these challenges well tend to share a few common traits: they have clear ownership of third-party relationships, they treat patch management as a routine operational discipline rather than an emergency response, and they build security review into development workflows from the outset rather than bolting it on afterwards. None of these things require extraordinary resources — they require consistent habits, clear accountability and a willingness to ask straightforward questions of the suppliers and platforms your organisation depends on.