Edge Access Broker Campaign: 70,000 Credentials via FortiWeb and PAN-OS

On 21 October 2026, researchers published an investigation into an access broker operation that breaks into internet-facing FortiGate, FortiWeb and GlobalProtect devices through two known exploited flaws, CVE-2025-64446 and CVE-2026-0257, and through brute force. More than 70,000 credentials were exposed. Patch both, pull management interfaces off the internet and rotate appliance-linked credentials.

That last step is the one most teams skip. A compromised firewall or VPN gateway is not only a device problem. Its configuration often holds directory bind passwords, local user passwords and administrator accounts, and the operators in this campaign downloaded configurations and decrypted them offline. Patching closes the door. It does not take back the keys that already left.

Our earlier posts cover each flaw on its own: CVE-2025-64446 in FortiWeb with its patch guide, and CVE-2026-0257 in PAN-OS. This post covers how one operation used both, the vendor versions and published indicators, and an edge device and credential hygiene checklist you can run this week.

What happened

The investigation describes an operation built for volume. The operators did not research individual companies. They pulled bulk lists of exposed VPN and firewall appliances from internet scanning services, filtered by product and country, and tried a known exploit or a password guessing routine against each one. Where they got in, they connected over a VPN client, harvested more credentials, worked toward domain administrator, installed remote management tools to keep access, and in some cases copied data out to cloud storage with Rclone.

The researchers say many organisations compromised in this campaign were later listed on the leak sites of two ransomware groups, Qilin and The Gentlemen, and are explicit that the relationship is unconfirmed. Their assessment is that the operators most likely act as initial access brokers, who break in and pass the access to someone else. We go no further than that. No primary source attributes this activity to any country, and neither do we.

Timeline

Times are UTC where a source publishes them.

Key numbers

The headline figure is more than 70,000 exposed credentials tied to network devices, LDAP dumps and similar data. That is credentials, not victim organisations; no victim total is published. The operators' remote management server held 28 active device groups with 84 devices, and 100 more groups since removed. Asia Pacific held 37.6 percent of unique victim domains, with Latin America also large, which the researchers attribute to where exposed devices were found rather than deliberate targeting. An earlier, separately reported FortiGate credential dataset showed negligible overlap.

Technical details

This section draws only on the vendor advisories, NVD, the CISA KEV catalog, the product maker's threat brief and the original research. We give versions, scores and published indicators, and leave out request paths, cookie formats and anything else that would help someone repeat the attack.

CVE-2025-64446: FortiWeb relative path traversal

Fortinet's workaround is to disable HTTP or HTTPS administration on internet-facing interfaces until you upgrade, and it notes the risk is significantly reduced when management is reachable only internally. After upgrading, it recommends reviewing configuration and logs for unexpected changes and unauthorised administrator accounts.

How the researchers say it was used: the operators' script tried this flaw first against every responsive Fortinet target. On a vulnerable FortiWeb it created a local administrator with a random eight character name, a matching password, a built in administrative profile and a trusted host range of 0.0.0.0/0, meaning administration from any address, then confirmed the account worked. FortiGate firewalls are not vulnerable to this flaw; for those the script fell back to password guessing.

CVE-2026-0257: GlobalProtect authentication bypass

The condition matters. The advisory says the issue affects GlobalProtect portals or gateways when authentication override cookies are enabled and a specific certificate configuration exists.

Three notes from the advisory change how you roll this out. The fix regenerates authentication override cookies, so GlobalProtect users must sign in again once after the upgrade. Every portal and gateway that generates or accepts these cookies should be upgraded together, and hybrid Prisma Access customers must upgrade all on premises firewalls. For a phased upgrade, the FAQ documents a temporary setting that relaxes strict cookie HMAC validation, and says to switch it back on once every device is fixed.

If you cannot upgrade yet, the mitigations are a new certificate used only for authentication override cookies, not shared with the portal, gateway or anything else, or turning authentication override off on both portal and gateway. A certificate previously used for another function cannot be reassigned; generate a new one.

How the researchers say it was used: a dedicated script checked GlobalProtect endpoints at scale, flagged those that accepted a forged authentication override cookie, and used it to open a VPN session with an open source VPN client. That gave the operator a network position without a password.

The older weakness: default configuration encryption on FortiGate

The researchers single out CVE-2019-6693 as the weakness the operators abused "at scale". After guessing a FortiGate administrator password, the script downloaded the configuration and decrypted stored secrets offline with a default key built into FortiOS. FortiGuard says the key protects all "ENC" type credential data in the CLI configuration except the administrator's password; NVD adds user passwords, private key passphrases and the high availability password when set.

The fix has existed since FortiOS 5.6.11, 6.0.7 and 6.2.1: the private-data-encryption option, disabled by default, which encrypts those values with a key you supply. Because decryption happens on the attacker's machine, nothing on the appliance can see it. The only defences are protecting the secrets before the configuration leaves, and rotating them after.

Tool categories after initial access

Remote management agents auto-enrolled into the operators' console, which held no files; bulk transfer was left to Rclone. Command and control agents arrived as a fake installer fetched by PowerShell from a bare IP address and port, a behaviour worth searching for directly.

Published indicators

The original research publishes these indicators, defanged as published. The researchers stress that no match does not rule out compromise.

File hashes, listed in groups of MD5, SHA-1 and SHA-256. The report does not say which file each group belongs to, so we keep its order:

Separately, the product maker's threat brief publishes indicators from wider CVE-2026-0257 exploitation it observed. These are not tied to the access broker. For activity before the 29 May proof of concept, it lists these source addresses to check against successful GlobalProtect logins: 23[.]128[.]228[.]6, 104[.]207[.]144[.]154, 146[.]19[.]216[.]119, 146[.]19[.]216[.]120, 146[.]19[.]216[.]125, 179[.]43[.]172[.]213, 185[.]195[.]232[.]139, 198[.]12[.]106[.]60 and 202[.]144[.]192[.]47. It also lists host IDs and device names seen in gateway connected events: aa:bb:cc:dd:ee:ff, 00:11:22:33:44:55, WINDOWS-LAPTOP-001, DESKTOP-GP01 and GP-CLIENT, plus clients reporting Microsoft Windows 10 Pro 64-bit with an empty user domain. A real fleet laptop rarely reports a placeholder MAC address, so these are cheap, high signal searches.

Unknowns, marked

• Start date. Our dossier recorded the campaign as active since 22 October 2025; we could not find that date in the published research. It shows a script dated 8 December 2025 and most FortiGate compromises between February and June 2026.
• Victim count and sponsor. No total is published, and the ransomware link is a victim overlap only.
• Script authors. The researchers could not link the developers named in the tools to the operators.
• FortiWeb exploitation indicators. Fortinet publishes none; the research describes the behaviour, not network indicators for that step.
• A fuller report is promised by the researchers.

Who is affected

Managed service providers should read "you" as every customer appliance they administer. Our posts on edge devices as the front door and why VPN gateways should be first in your patch queue make the general case this campaign illustrates.

Edge device and credential hygiene checklist

Steps 1 to 6 cut exposure today. Steps 7 to 12 find out whether someone is already inside and take back what they took.

1. See your edge the way the operators do

Start from the outside. From a host outside your network, check which of your own public addresses answer on administration and VPN ports:

# Only scan addresses you own.
nmap -Pn -p 443,4443,3879,8443,10443,22 -iL my-public-ips.txt -oG edge-exposure.gnmap
grep "/open/" edge-exposure.gnmap

The product maker's threat brief warns of a misconfiguration it kept finding in incident response: GlobalProtect profiles mapped onto the management interface's HTTP or HTTPS service, exposing management on ports 4443 and 3879, often unnoticed. Keep the result as a list with owner, model, version and management exposure. Every later step depends on it.

2. Check versions and configuration

On FortiWeb and FortiGate, run get system status and compare the version with the tables above. On PAN-OS:

show system info | match sw-version

Then check authentication override. Per the advisory: on the portal, Network, GlobalProtect, Portals, your portal, Agent, your agent configuration, Authentication, and see whether "Generate cookie for authentication override" or "Accept cookie for authentication override" is checked. On the gateway, the Client Settings profile's Authentication Override tab has "Accept cookie for authentication override".

3. Patch on a written SLA

For comparison, CISA gave federal agencies seven days for CVE-2025-64446 and three days for CVE-2026-0257 under Binding Operational Directive 22-01. For GlobalProtect, upgrade every cookie-handling portal and gateway as one change, warn users about the one time sign in, and if you use the temporary HMAC compatibility setting, schedule the day you turn strict validation back on.

4. Take management interfaces off the internet

This step alone removes the FortiWeb path and the FortiGate password guessing in this campaign. CISA's Binding Operational Directive 23-02 requires federal agencies to make management interfaces reachable only from an internal network, with an isolated management network recommended, or to put them behind a separate access control enforcement point. On Fortinet devices, remove http and https from allowaccess on internet-facing interfaces and review every administrator:

show system admin

Read each trusthost line. An open range on an account you do not recognise is exactly what the researchers say the operators created. On PAN-OS, review Interface Management profiles and confirm GlobalProtect is not bound to the management interface's service.

5. Put MFA on every VPN and administrator login

The researchers recommend MFA "universally" because brute force and stolen passwords drove much of this campaign. Enforce it at your identity provider for SSL VPN and GlobalProtect, and on every appliance administrator, preferably phishing resistant. Know the limit: MFA does not stop CVE-2026-0257, and the product maker's threat brief says attackers used the flaw to bypass MFA controls. You need the patch and MFA.

6. Lengthen lockouts and encrypt stored secrets

The operators' script simply waited out the 60 second default lockout. On FortiGate, raise admin-lockout-duration well above the default, keep admin-lockout-threshold low, and alert on lockouts. Then enable configuration secret encryption with your own key:

config system global
    set private-data-encryption enable
end

Store the key with the device record. FortiGuard's advisory notes that configurations leak in ordinary ways, such as being posted on a forum for troubleshooting.

7. Rotate every credential the appliance held

If a device was vulnerable while exposed, assume its configuration was read. The researchers say to treat that as a credential disclosure event. Rotate, in order:

1. LDAP and Active Directory bind accounts, moved to a dedicated low privilege account if they are currently privileged.
2. Local administrators, deleting any you cannot match to an authorised change.
3. Local VPN users stored on the device.
4. RADIUS and TACACS shared secrets, high availability passwords and private key passphrases.
5. Certificates whose keys live on the device, including GlobalProtect portal, gateway and authentication override certificates.
6. Active VPN sessions, so new credentials take effect.

If domain administrator access is suspected, follow your directory vendor's domain compromise guidance, which typically includes resetting the Kerberos ticket granting account password twice.

8. Review appliance and VPN logs

On Fortinet devices, look in system event logs for administrator creation, configuration downloads or backups, trusted host changes and logins from outside your management range. On PAN-OS, list who is connected now:

show global-protect-gateway current-user

Then filter GlobalProtect logs for gateway connected events matching the indicators above or from first seen source addresses.

9. Hunt for unapproved remote management tools

The researchers advise checking that each remote management install has "an approved owner and business purpose". The tools are legitimate, so build a list of the ones your IT team uses and diff every endpoint against it:

Get-CimInstance Win32_Service |
  Select-Object Name, DisplayName, State, StartMode, PathName |
  Export-Csv -NoTypeInformation "$env:COMPUTERNAME-services.csv"

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
                 HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Select-Object DisplayName, Publisher, InstallDate | Sort-Object InstallDate -Descending

Windows System event 7045 records a new service, and Security events 4720 and 4732 record a new local account and a group addition. New services in the days after a VPN login from an unfamiliar address are the pattern to chase, along with outbound connections to remote management clouds and tunnelling services your IT team does not use.

10. Hunt for Rclone

Rclone is a legitimate sync tool. Look for it where it should not be:

Get-ChildItem "C:\Users\*\AppData\Roaming\rclone\rclone.conf" -ErrorAction SilentlyContinue
Get-ChildItem C:\ -Recurse -Include *.exe -ErrorAction SilentlyContinue |
  Where-Object { $_.VersionInfo.ProductName -match 'rclone' } |
  Select-Object FullName, LastWriteTime

find / -xdev \( -name 'rclone' -o -name 'rclone.conf' \) 2>/dev/null

Rclone's documentation describes its configuration as an INI file with one section per remote and a type key naming the storage backend, so a configuration with a cloud remote on a file server is a strong lead. In process creation logs, search for copy or sync command lines that name a remote, and alert on large outbound transfers to cloud storage your organisation does not use. Match on version metadata and command line shape, because the binary is often renamed.

11. Look for the credential theft that came before

Patch domain controllers for CVE-2021-42278 and CVE-2021-42287, both in KEV since April 2022. Look for bursts of Security event 4769 across many service accounts from one host, and remote task or service creation fanning out from one source. Give service accounts with SPNs long random passwords.

12. Preserve evidence first

The researchers' last immediate action is to preserve appliance, VPN, authentication, endpoint, DNS, proxy and firewall telemetry before retention expires. Appliances often keep only days of logs. Export them now, even before you read them.

What changed since first reports

Neither flaw was new on 21 October. The research adds the joined up picture: one operation using both, plus brute force and an old encryption weakness.

The product maker's threat brief has also moved. Its earlier text found no post access activity. Its 19 October update describes ransomware operators using the flaw, then remote management tools, lateral movement over RDP and SMB, credential harvesting, exfiltration and, in one case, a pivot to the virtualisation management layer. It names Qilin among the operators it observed, matching one group in the research's victim overlap, but neither source refers to the other. Treat them as two views of the same exposure. Our post on PAN-OS CVE-2026-0257 and ransomware covers that update, and Edge device zero days, October 2026 places it among the month's other edge flaws.

Where sources disagree

• KEV date for CVE-2026-0257. The threat brief says 13 May 2026; CISA's catalog shows 29 May 2026. We use CISA's date.
• CVE-2026-0257 severity. NVD gives 9.1 under CVSS 3.1; the vendor gives 7.8 under CVSS 4.0. Both are correct for their scheme.
• FortiWeb exploitation. The FortiGuard summary says exploitation was observed in the wild, while a metadata field on the same page reads "Known Exploited: No". CISA lists it in KEV. We treat it as exploited.
• Ransomware use. CISA marks ransomware use "Known" for CVE-2026-0257 and CVE-2019-6693 and "Unknown" for CVE-2025-64446.
• PAN-OS 12.1.0 and 12.1.1. The machine readable advisory lists 12.1 as affected from 12.1.0, but the solution table starts at 12.1.2. If you run either, move to 12.1.7 or later.

Open questions

• How many organisations sit behind the 70,000 credentials, and how many credentials still work.
• Whether access was sold or handed directly to the ransomware groups in the victim overlap.
• Whether other edge products the operators searched for were compromised; current evidence says no.
• What the promised fuller report adds for detecting the FortiWeb step on the device.

What would have helped

Nothing here suggests any organisation did something wrong. Edge devices are hard to run well, and this campaign was built to find the ones that slipped.

Practices any team can use

• An external view of your own edge, rebuilt at least monthly, with owner, version and management exposure per device.
• A written edge patch SLA tied to KEV, measured in days, with exceptions that expire.
• Management planes off the internet, behind an isolated network or separate access gateway.
• MFA wherever a password works, knowing it does not cover authentication bypass flaws.
• Appliance secrets treated as secrets: your own encryption key, low privilege bind accounts, and a rotation runbook listing every credential each device holds.
• An approved list of remote management tools and an alert when anything else appears.
• Exfiltration signals on file servers, and log retention off the box.

Where Safeguard fits

The boundary first. Safeguard does not patch firewall or VPN firmware, scan your public IP ranges, read appliance or VPN logs, or detect remote management tools and Rclone on endpoints. It would not have detected or prevented this campaign.

Where it helps is the software you build around that edge and the record of your response:

• Knowing what is in the code you own. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with results as JSON under ./output), matches components against vulnerability databases and shows which projects contain a given component and version. VPN provisioning scripts, configuration backup jobs and log shippers are built from open source packages that need the same tracking.
• Ranking and gating. Reachability analysis puts vulnerable code paths you actually call first, and policies and gates in the platform can block, warn, notify or require approval at a checkpoint.
• Recording the response. The Compliance and GRC suite has Vendors, Risks, Policies and Evidence, so you can log the appliance risk and attach patch and rotation evidence for frameworks such as SOC 2 and ISO 27001.
• A person on every action. The Safeguard CLI's assistant can edit code and run commands with your approval (/permissions offers Ask, Accept edits, Plan, Auto and Strict), the desktop and phone apps send work to a computer running the CLI where each command is approved or denied, and safeguard exec runs the same work in CI.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh, free, no login) offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

Neither applies to the flaws in this campaign. FortiWeb, FortiOS and PAN-OS are vendor appliance firmware, outside the package ecosystems Zero-Day Discovery covers and outside what Gold builds. These capabilities matter for the open source components in the software you build, where the right habit is pulling patched, signed components from a curated source and rebuilding fast.

Common mistakes

• Patching and stopping. The upgrade does not remove an administrator created months ago or rotate a bind password copied in March.
• Rotating only the obvious passwords. Bind accounts, HA passwords, RADIUS secrets and certificate keys sit in the same configuration.
• Assuming MFA covers a bypass. It covers guessed passwords, not skipped authentication.
• Leaving the HMAC compatibility setting relaxed after a phased GlobalProtect upgrade.
• Hunting by tool name alone. Renamed binaries defeat it; hunt by owner, source, destination and timing.
• Treating no IOC match as all clear, which the researchers explicitly warn against.

FAQ

What is the edge device access broker campaign?

An operation, published by researchers on 21 October 2026, that finds exposed FortiGate, FortiWeb and GlobalProtect devices through scanning services, gets in with CVE-2025-64446, CVE-2026-0257 or brute force, harvests credentials and keeps access with remote management tools. More than 70,000 credentials were exposed.

Which versions fix CVE-2025-64446?

FortiWeb 8.0.2, 7.6.5, 7.4.10, 7.2.12 and 7.0.12 or above, per FG-IR-25-910. FortiWeb 6.4 and FortiAppSec Cloud are not affected.

Which versions fix CVE-2026-0257?

It depends on your PAN-OS line and hotfix; see the table above. On the main lines, 12.1.7, 11.2.12, 11.1.15 and 10.2.18-h6 or later are fixed, as are Prisma Access 10.2.10-h36 and 11.2.7-h13. Cloud NGFW and Panorama are not affected.

Am I affected by CVE-2026-0257 without authentication override cookies?

The vendor says the issue needs authentication override cookies enabled and a specific certificate configuration. Check both, and upgrade either way.

Does MFA stop this campaign?

It stops brute force and stolen passwords, not the CVE-2026-0257 bypass.

Were FortiGate firewalls exploited through CVE-2025-64446?

No. The researchers say FortiGate is not vulnerable to it. FortiGate devices were attacked by password guessing, and their configurations decrypted offline using the default key tracked as CVE-2019-6693.

What should I rotate after an appliance compromise?

Directory bind accounts, local administrators, local VPN users, RADIUS and TACACS secrets, HA passwords, certificate keys and passphrases, and active VPN sessions. If domain administrator access is suspected, follow your directory vendor's domain compromise guidance.

Is this a nation state campaign, and which ransomware group is behind it?

No primary source makes a national attribution and we do not either. The researchers report victims later appearing on Qilin and The Gentlemen leak sites, say the relationship is unconfirmed, and assess the operators as likely initial access brokers.

Fix it without waiting for upstream

The flaws in this campaign live in vendor appliance firmware, so the fixes for FortiWeb, FortiOS and PAN-OS must come from the vendors; nothing below changes that. What follows applies to the open source code and images your team builds and runs alongside those devices.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows this campaign, a firewall or an appliance upgrade. Each shows a real Safeguard flow that applies to the code and scripts your team runs around edge devices.

The first demo is a real CLI session. It installs the CLI, opens the interactive terminal and asks it to fix the lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For a repository of VPN provisioning or configuration backup scripts, you would run the same /scan . and ask the assistant to move a flagged dependency to its fixed version, approving each step.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit; it ends with the upgrade done and tests passing. During an edge incident, that is the habit you want around anything near credentials or production config: every step visible, nothing run without a yes.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. An on call engineer away from a desk can still push a fix to code the team owns, with a person approving each command.

Click through it at your own pace, or open it full screen.

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• Original research, 21 October 2026
• NVD: CVE-2025-64446
• NVD: CVE-2026-0257
• NVD: CVE-2019-6693
• Fortinet PSIRT FG-IR-25-910: Path confusion vulnerability in GUI (CVE-2025-64446)
• Fortinet PSIRT FG-IR-19-007: Hard coded key for configuration secrets (CVE-2019-6693)
• Palo Alto Networks security advisory: CVE-2026-0257 PAN-OS GlobalProtect Authentication Bypass Vulnerabilities
• Palo Alto Networks threat brief: active exploitation of PAN-OS CVE-2026-0257
• CISA Known Exploited Vulnerabilities catalog
• CISA BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces
• Rclone documentation: configuration file

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.