Mending the Fold After a NAS Ransomware Attack

This article was last updated on: November 9, 2026 pm

Introduction

AI has turned vulnerability discovery into an assembly-line business, and the end of that line points straight at the NAS sitting in the corner of your room.

When PHP2Shell (CVE-2026-109618 / CVE-2026-109619) was disclosed in October 2026, it carried a CVSS score of 9.2: pre-authentication remote code execution, no credentials required, with the malicious request completing inside the PHP runtime before the application-layer code even ran. The flaw had been sitting in the codebase for over a decade. Human auditors turned the page with the conclusion that it was “difficult to exploit in practice”; once AI models took over, the complete chain from confirmation to exploitation was worked through within days. Around the same time, Synology NAS users began finding files in their shared folders batch-renamed with the .L0CK3D extension, with a read-me3.txt in every directory containing C3RB3R’s “instructions.”

Put the two together and the chain is uncomfortably clear: AI accelerated vulnerability discovery, a low-level flaw in the PHP ecosystem was rapidly weaponized, and internet-exposed NAS devices were the first row to be flattened. Synology later confirmed that the attackers exploited a vulnerability patched as far back as December 2024, while independent analysis by security vendor 360 pointed to two maximum-severity RCEs that were only fixed in September 2026. Whichever entry point was the real culprit, the conclusion is the same: a NAS that was “patched at some point” is, if the patch isn’t the latest one, not much different from an unpatched device when automated attacks come knocking.

This isn’t about fear-mongering. Quite the opposite: when it comes to NAS ransomware, there are plenty of “too small to bother with” things you can do beforehand, and a clear enough path to mend the fold afterward. None of the items below require you to become a security expert. Start doing them now.

Security Starts with “Turning Off One Port Forward”

📔Note:

My NAS is a QNAP, and I’ve always followed its security best practices. So for this incident, I’d like to talk through QNAP’s security recommendations—the principles are the same across the board.

QNAP’s official security guide doesn’t mince words: exposing a NAS’s network ports directly to the internet is simply insecure. Attackers don’t need to crack your password or guess your account. They just need to scan for management ports open on the public internet and then use a pre-auth vulnerability like PHP2Shell to walk right in.

The first line of defense that actually works is often so small that it makes you wonder, “Can this really help?”

  • Turn off UPnP, DMZ, and port forwarding on your router. If your NAS management interface is reachable from the public internet, you’re using a machine that never powers down to give every automated scanner in the world a fixed target.
  • Route remote access through a VPN; don’t expose the web management port directly. The VPN software that ships with your NAS, or Tailscale, is an order of magnitude safer than “port-forwarding 8080/5001 to the outside.”
  • Disable the default admin account. The first word in any brute-force dictionary is always admin; it’s one of the lowest-cost entry points for an attacker.
  • Enable automatic updates. NAS system updates contain more than new features; most of the time they contain vulnerability fixes. The trouble with manual updates is that you’re always a step behind, and then another—permanently stuck in someone else’s exhaust.

These things sound trivial, maybe even a little “not geeky enough.” But the NAS devices that fell in October 2026 most likely didn’t lose to some ingenious, complex hacker intrusion scheme; they lost to their owners’ earlier decisions: “just expose it to the public internet,” “never update/upgrade,” “admin is so convenient.”

The First Step in Mending the Fold Is Not Reinstalling—It’s Stopping

If .L0CK3D files have already shown up in your shared folders, the most dangerous impulse is to “hurry up and reinstall the system, format the drives, and start over.”

Don’t.

HKCERT’s first piece of advice in its Synology ransomware alert is to isolate immediately: pull the network cable, disconnect from the network, and pause all sync and backup jobs. At the Linux level, the encryptor walks every writable directory with multiple threads; if your cloud backup or an external drive is still connected, it will encrypt the backups too. Unless multi-version locking or offsite isolation is enabled, a Synology Hyper Backup directory is, in the eyes of the ransomware, just another ordinary chunk of storage waiting to be encrypted.

The second step is to preserve evidence. Keep the ransom note, samples of encrypted files, and system logs. Don’t format anything yourself, don’t keep rebooting, and don’t try unidentified decryption tools from the internet in a desperate “maybe this will work” gamble. These actions can not only destroy potential recovery clues but also make things worse.

Only then should you move on to the remediation order: plug the hole first, then restore the data.

Real “Mending”: Automating the Small Stuff with Your NAS’s Built-in Security Center

For example, the QNAP Security Center I’m familiar with essentially does one thing: it turns those small security tasks you “know you should do but always forget” into rules the system enforces automatically.

Its core capabilities aren’t complex, but each one maps directly onto a common path by which NAS devices get ransomware:

File activity monitoring: when a flood of file changes appears on the NAS—the most typical behavioral signature of ransomware—Security Center can automatically trigger one of three protective measures: put the volume into read-only mode to stop the encryption process from writing further; take an immediate snapshot to lock in the state before it is attacked; or pause the snapshot schedule so abnormal snapshots don’t crowd out normal snapshot space. The value of this logic is that it doesn’t depend on you getting up at 3 a.m. to act manually; it steps in during the first window in which encryption behavior occurs.

Snapshots are the lowest-cost path to recovery after the fact. If the ransomware is stopped by read-only mode mid-encryption, or if you at least had one healthy snapshot before the attack, recovery can be as simple as “pick a point in time before the encryption in Snapshot Manager and click Restore.” QNAP’s official recovery guidance likewise recommends rebooting the NAS immediately and updating the firmware to the latest version after restoring a snapshot, and only then migrating the data back—otherwise you’re just putting clean data back into an environment that still has holes.

But snapshots have a fatal boundary: they cannot replace independent backups. QNAP specifically emphasizes in its PHP2Shell remediation guidance that “snapshots on the same NAS cannot replace independent backups.” The reason is simple: if the ransomware gains enough privileges, it can delete or encrypt the snapshots too. What remains usable after a NAS is fully compromised is an offline or immutable backup under the 3-2-1 principle: at least one copy on media the NAS cannot write to, or object storage with an immutable (WORM) policy. HKCERT’s advice is worded almost identically: keep offline or immutable backups and test the restore procedure regularly. A backup you don’t test is no backup at all.

Security Counselor, meanwhile, handles the “configuration-level small stuff”: it periodically scans the NAS’s security settings and tells you which port is still open, which account is still using a weak password, and whether the management interface is still exposed to the public internet. It won’t build a perfect security architecture for you, but it will put the easily forgotten oversights in front of you, one by one.

Mending the Fold Is About the Next Time

When I wrote about Cloudflare’s crisis communications, I wrote a line that applies perfectly to NAS ransomware: failure is not shameful; covering it up is. Don’t bury your head in the sand; don’t lie to yourself.

Being hit by ransomware is not something you need to hide. What truly deserves vigilance is deleting the ransom note once the attack passes, reinstalling the system, and then pretending nothing happened—carrying on with the same configuration, the same patch cadence, the same “if the port’s open, leave it open.” The next automated scan will not spare you because you pretended to forget.

The premise behind “it’s not too late to mend the fold” is that you’re mending the fold, not the sheep. Mending the fold means: applying the patch that should have gone in back in 2024 all the way to the latest version; turning off the port forward on the router that hasn’t been closed since 2022; switching from “manual updates” to automatic updates; turning the snapshot policy from “enable it when I remember” into a permanent rule in Security Center; and moving your only backup from “another folder on the same NAS” to a drive that won’t be encrypted once it’s unplugged.

Each of these, taken on its own, is too small to look like “security engineering.” But the lesson PHP2Shell and C3RB3R taught everyone in October 2026 is precisely this: the speed of vulnerability discovery has been pulled by AI down to days, even hours, while the remediation gap still hides in those small things you thought you’d deal with “later.”

Mending the fold starts with pulling that network cable, closing that port, and clicking that update. It’s not too late—but you have to make the first move.

✅ Checklist

Here is a checklist for mending the fold (not original work; all items come from QNAP Security Center - Security Policies):

  • [ ] Is the NAS running the latest firmware version?
  • [ ] Are all NAS apps updated to the latest version?
  • [ ] Does the NAS check for new firmware versions?
  • [ ] Does the NAS send notifications about new firmware versions?
  • [ ] Has the administrator’s default password been changed?
  • [ ] Does the “password policy” require complex passwords of at least 8 characters?
  • [ ] Are shared folders denied to guest access?
  • [ ] Is two-step verification enabled for the NAS administrator account?
  • [ ] Does the NAS disallow NFS access to shared folders from all IP addresses?
  • [ ] Does the NAS enforce changing account passwords every 90 days?
  • [ ] Is Telnet access disabled on the NAS?
  • [ ] Can the device’s system management services be accessed directly from the public internet?
  • [ ] Is the device connected directly to the public internet?
  • [ ] Does the NAS enforce HTTPS connections?
  • [ ] Has SSH password login been disabled on the NAS?
  • [ ] Is FTP disabled on the NAS?
  • [ ] Does the NAS restrict iFrames?
  • [ ] Does the NAS use TLS 1.2 and later?
  • [ ] Have the default HTTP/HTTPS ports been changed?
  • [ ] Has the NAS enabled network access protection for SSH/Telnet/HTTP/HTTPS/FTP servers? (automatically block after multiple failed attempts)
  • [ ] Has the NAS disabled “run user-defined processes at startup”?
  • [ ] Have there been large-scale abnormal file changes in specified directories?
  • [ ] Is TFTP disabled on the NAS?
  • [ ] Do all installed programs have valid signatures?
  • [ ] Has the SQL server password been changed?
  • [ ] Is access control enabled?
  • [ ] Are scheduled virus scans enabled?
  • [ ] Is the virus definition database up to date?
  • [ ] Does the NAS run a virus scan at least once every 30 days?
  • [ ] Is the antivirus software/scanner secure and up to date?
  • [ ] Is the web server feature disabled?
  • [ ] Is a firewall installed and enabled?
  • [ ] What is the firewall policy level?
  • [ ] Are Docker images updated regularly?
  • [ ] Is a 3-2-1 backup strategy in place? Are backups performed regularly?
  • [ ] Has home broadband been set to “full cone” NAT for convenience?

References

QNAP Official Security Resources

Synology Ransomware Incident and Official Advisories

PHP2Shell (CVE-2026-109618 / CVE-2026-109619)

AI Accelerating Vulnerability Discovery