What’s changed?

• Fixed a small bug (but very important if you use VFSs that connect to your storage via UNC paths, like SMB/CIFS on Windows) that was recently introduced in v8.8.0 and prevented the enumeration of virtual-root directories if the UNC path was not properly closed with the system’s path separator - this issue only and exclusively affected the Windows version of our software

• Updated a library dependency because they fixed a vulnerability in their own code, which every software built with it (including ours) had the potential to inherit

• As per our recently shared plan, this release also adds a ton more of the planned automation-related features, highly requested by our customers, among which:

  • Webhooks: subscribe to any of the numeric log event IDs (or whole blocks of them) and receive signed JSON over HTTPS. HMAC-SHA256 signatures, retries with backoff, and a delivery ID for de-duplication on the receiving side

  • Global webhooks for SuperAdmins (every event on the node) and per virtual site webhooks for Admins (only that site’s events), each behind its own permission

  • Built in protection against server side request forgery: private and loopback targets are refused unless both the SuperAdmin policy and the webhook allow them; redirects are never followed

  • A live event stream over Server Sent Events on the REST API, filtered by event, block and level

  • An event catalog endpoint: the registry of event IDs as JSON, for user interfaces and agents

  • Dry run, ETag and idempotency extended to LDAP, SSO providers, certificates and Shield configuration

• Bumped up the usual set of minor dependencies

As always, you can download the most recent release from our website. Or, if you are running any version from v8.2.0 (and up) you can use its built-in zero-downtime self-update feature directly from within the SuperAdmin UI.

Thank you all for trusting our software with your secure file transfers!

This was the first of three planned minor releases, all about automation and AI orchestration, to add features that have been strongly requested (we should probably say “demanded”) by our Customers.

The plan goes like this:

• v8.8.0 established the general foundation: automation tokens, all the related security and role-based access features, automation-specific audit trail, mutation idempotency, optimistic concurrency, and machine-readable error codes

• v8.9.0 will add event-notification webhooks, server-side forgery protections, event live-streaming via SSE over REST API, event catalog, and full machine-readable OpenAPI compliant definitions

• v8.10.0 will come full circle with the release of a dedicated MCP server to expose Syncplify Server!’s API to AI orchestration agents (gated and secured by all of the above), AI-specific scoped authorization tokens with strict permission enforcement, mandatory TLS verification, and dry-run for all operations (to be authorized by a human operator)

All of it will be optional, and none of it will be on by default.

And let us be clear. This is a set of tools for you - the Customer - to use. Nothing else. Our promise and pledge never to feed your information or your files to an AI agent stands and remains carved in stone. We have never done that, we don’t do that, and we never will.

It is, though, undeniable that today’s world moves at AI speed, and not to include tools for AI to interact with our software in a controlled, reliable, and secure manner would only mean to be left behind.

So we’re doing it. And we’re doing it with caution: in stages, carefully testing each stage, overthinking each security aspect, in an effort to deliver an effective and safe solution that does exactly what you, our Customers, are asking for.

If a symbolic link (or, on Windows, a directory junction) pointing outside a VFS root already exists inside it, a user can follow it to reach files outside their home folder.

Affected

Versions 6.0.0 through 8.7.1, on Windows and Linux.

The advisory states “all versions before 8.8.0”; that is inaccurate and we have asked VulnCheck to correct it.

Are you exposed?

Only if such a link exists inside one of your VFS roots. Syncplify Server! users cannot create one unless you have explicitly granted them the permission to create symlinks (off by default). Otherwise, it must be created by someone or something with direct write access to that folder on disk.

Intentional links are not a vulnerability: if an administrator placed a link there on purpose, users reaching its target is the intended behavior.

Fix

1. Upgrade to v8.8.0 (released October 25, 2026).
   It adds a per-user "Follow symlinks" setting: Always, Only if target lands inside of the user's root, or Never. It applies to Windows junctions too.

2. After upgrading, every existing user is set to "Always" (same as before), so intentional links keep working.

3. For every user who should not follow links outside their root, change it to "Only if target lands inside of the user's root" or "Never".

If you keep "Always" for a user, make sure their permission to create symlinks is off, and check their root for links you didn't create:
Linux: find /path/to/vfs/root -type l
Windows: dir /AL /S C:\path\to\vfs\root

A note on intentional links

Some of our customers deliberately place symbolic links or directory junctions inside VFS roots to make better use of their storage. If a link was created on purpose by an administrator who knows where it points, that is not a vulnerability: it is a configuration choice and a useful feature.

Starting with v8.8.0, each user account has a “Follow symlinks” setting:

• Always (same behavior as previous versions)

• Only if target lands inside of the user’s root

• Never

The default is Never for all newly created user profiles. If you rely on links that point outside a user’s root, set that user to Always after upgrading. When you do, make sure that user’s permission to create symlinks stays off: “Always” is safe only when every link in that root was placed there by you.

Advisory: https://www.vulncheck.com/advisories/syncplify-server-symbolic-link-jail-escape

An authenticated user can bypass a Permission Override by addressing the protected folder with different capitalization or its Windows 8.3 short name.

Affected versions

Versions 4.0.0 through 8.7.1, Windows only.

The advisory states “all versions before 8.8.0”; that is inaccurate and we have asked VulnCheck to correct it. Linux is not affected.

Are you exposed?

Only if you run Windows and at least one of your users has Permission Overrides configured. If not, this does not apply to you.

Fix

Upgrade to v8.8.0 (released October 25, 2026).

Can’t upgrade yet? Do this:

1. Move each folder that needs different permissions out of the user’s home folder, to a separate location on disk.

2. Mount it in the user’s namespace as a Virtual Folder, with the permissions it needs. Virtual Folders are not affected by this bug.

3. Remove the corresponding Permission Overrides.

Removing the overrides alone is not a mitigation: step 1 and 2 are what protect the data.

Advisory: https://www.vulncheck.com/advisories/syncplify-server-permission-override-bypass-via-path-casing

What’s changed?

• Fixed two yet-to-be-published CVEs (CVE-2026-112343 - Permission Override Bypass in Syncplify Server! Virtual Filesystem Path Matching and CVE-2026-112344 - Home Folder Escape via Symbolic Link Following in Syncplify Server!); we are grateful to the security researchers who found them for ethically abiding by the coordinated vulnerability disclosure principles, thus allowing us time to fix these two bugs before releasing their research which inherently explains how to exploit them… if there ever was a Syncplify Server! release you absolutely must update to, this is that release

• The automatic self-update feature now also covers HA clusters in full, performing staggered updates of each node, using temporary leased tokens to guarantee uninterrupted availability of your file-transfer services throughout the entire update process

• The live sessions data-table in the real-time dashboard now has a toggle for the operator to decide whether to keep it always in compact or expanded mode

• More statistical information about each user activity is now displayed in the summary page of each user account in the Admin UI (very useful to the operator for troubleshooting)

• Added a host of automation-related features, all of which had been highly requested by our customers, among which:

  • Automation tokens: unattended credentials for the SuperAdmin and Admin REST APIs. A token is minted by an operator who signed in with their second factor, belongs to that operator, is never broader than that operator’s own permissions, and can be narrowed further when it is created

  • Automation token security features:

    • tokens are read-only by default (writes must be enabled per token)

    • 90-day expiration (can be increased to a maximum of 1 year

    • per-IP allow-list to control network origin of token usage

    • token can never create other tokens (an operator with 2FA is required)

    • automatic notification 7 days prior to token expiration

    • all write operations and mutations come with a dry-run feature

  • Complete automation audit trail: every change made with a token is recorded with the token and the operator who owns it; rejected token attempts and scope refusals are log events of their own

  • All mutations have been made idempotent, so that automation engines mistakenly running the same cycle more than once cannot cause unexpected results or instability

  • Optimistic concurrency: ETag on reads and If-Match on writes, so an automation agent never overwrites a change a human made in the meantime

  • Stable, machine readable reason codes in every error response, including authentication and permission refusals, documented in the manual with the guarantee that a code never changes its meaning

• Bumped up the usual set of minor dependencies

As always, you can download the most recent release from our website. Or, if you are running any version from v8.2.0 (and up) you can use its built-in zero-downtime self-update feature directly from within the SuperAdmin UI.

Thank you all for trusting our software with your secure file transfers!

Several of our customers have reached out to ask whether their Syncplify software is exposed. The short answer: it is not. None of our products use PHP, so there is nothing to patch on our side.

This isn’t luck, and it isn’t the first time. Since Syncplify was founded almost 13 years ago, one of our guiding principles has been to keep external dependencies to a bare minimum (ideally zero). Every dependency is code we didn’t write, can’t fully audit, and have to trust.

That principle has served our customers well before. When Heartbleed hit OpenSSL in 2014, Syncplify software was not affected. When the Terrapin attack targeted SSH/SFTP servers in 2023, again, our customers were not affected.

No software is immune to bugs, including ours of course, and we’ll keep treating security as a first-class citizen and a never-ending task. But fewer dependencies means a smaller attack surface, and that is the guarantee our philosophy gifts to all our customers.

If you’re spending this week patching other systems, we hope it helps to know your SFTP server is one item you can already cross off your to-do list.

What’s changed?

• This release shows more of the users’ statistics in the Admin UI, adding last successful login time and IP address, plus some authentication-related usage statistics

• Bumped up the usual set of minor dependencies

As always, you can download the most recent release from our website. Or, if you are running any version from v8.2.0 (and up) you can use its built-in zero-downtime self-update feature directly from within the SuperAdmin UI.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• As previously announced, this is the release that adds full support for ACME style certificates; it works both with Let’s Encrypt and with any in-house ACME-compatible CA supporting TLS-ALPN-01, and it works by binding either its own internal responder to port 443 or by forwarding port 443 from your firewall/router to any of your HTTPS bindings (for added flexibility) - with certificate life-spans getting shorter and shorter, this was by far the most requested feature by the vast majority of our customers

• The real-time session data-table now has a toggle to keep it always in its expanded form (useful for SOC environments)

• The missing last-op timestamp in the real-time session data-table has now been fixed

• The previously empty public host key viewer has now been fixed

• Bumped up the usual set of minor dependencies

As always, you can download the most recent release from our website. Or, if you are running any version from v8.2.0 (and up) you can use its built-in zero-downtime self-update feature directly from within the SuperAdmin UI.

Thank you all for trusting our software with your secure file transfers!

Our stance, expressed in this post, covers exactly one thing: the content of your files will never become AI-training material. Not for us, not for anyone we could sell it to.

Most vendors can offer you that only as a promise. A clause in a privacy policy, a line in their terms of service, a commitment that lasts until the company changes their mind, raises a new investment round, gets acquired, or sends you a thirty days’ notice that their terms are changing. Policies can be revised, it happens all the time.

Ours is a property of the architecture. Your files never reside on our infrastructure, and we hold no credentials into your storage. There is no corpus sitting in our cloud waiting for a change of heart, a new owner, or a tempting offer. We cannot feed your files to an AI agent of our own, and we cannot sell their contents to anybody, because we never hold them in the first place.

Here are two questions you should ask to your current managed file transfer vendor:

• Can you technically read the contents of my files?

• If your terms of service changed tomorrow, what would physically prevent you from using them or selling them?

Across most of this market the answer to the first question is YES, which turns the second question into a mere business decision. We are not accusing anyone of anything. The option simply exists for them, and it does not exist for us (by design).

If privacy is a requirement for you rather than a preference, SFTP.cloud is your most sensible option. A promise can be rewritten in an day. An architecture would have to be rebuilt from scratch.

SFTP.cloud is live. Try it free for 14 days, no credit card required.

We did more than that.

Let’s Encrypt is a “special case” of the more generic ACME, and many of our customers are, in fact, running their own ACME certificate roots and directories, in their own private or semi-private networks. We have added true enterprise-grade for all that, not only Let’s Encrypt.

We’re in the testing and QA phases now, we’re planning on releasing this big update within the next couple of weeks… stay tuned!

What’s changed?

• Fixed a bug that caused uncompressed log files not to be deleted upon their archival (gzip); this bug only affected the Windows version of our software

• Fixed a UI glitch that prevented the export of the host’s SSH public keys

• Added the ability to customize the tab title and “favicon” for WebClient!

• Bumped up the usual set of minor dependencies

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Some password managers (like Keeper for example) append extra (unrequested) fields during the creation of a new passkey; up until and including v8.6.0 we treated any extra field as a threat, which caused Syncplify Server! to simply reject the request outright. As of v8.6.1 the verification process has become slightly more lenient, and some (not all) unrequested fields are now simply ignored, which allows such password managers to enroll passkeys even though their request is technically incorrect, but only after the request has gone through thorough server-side sanitization

• Bumped up a few minor dependencies

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

Every log line that has a severity level of INFO or above (that includes WARNINGS and ERRORS of course) now gains a numerical eventId.

All event IDs are documented in the manual.

This might seem like a small change, until you realize that in 2026 logs are no longer read by humans. They are analyzed by automated processes, fed to SIEM systems, and ever more frequently processed by AI agents.

Of course all the human-readable comments in our logs are still there. This was an additive feature, not a replacement. But having clear and consistent event IDs associated to each meaningful log line makes a world of difference when it comes to automating the processing of those logs (for example by a SOC).

As always, you can download the most recent release from our website, or if you’re running any version newer than v8.3 you can simply update your software live, with the push of a button in its SuperAdmin UI.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed a minor bug that caused the Users collection not to be imported from an old V6 backup if any of the user accounts had no credentials at all; if you had no user accounts in your new V8 after importing your old V6 backup, this release fixes that issue

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• The recently introduced automatic self-update feature suffered from a bug that made it unable to use local on-prem DNS resolvers to check the maintenance plan validity (causing false positives that customers found confusing); This release fixes such odd behavior.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Added an integer normalizer to the PKCS#1 importer (only to make it easier to import backups from older versions with configurations older than 6 years ago)

• Bumped up a few minor dependencies

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

They have no idea who you are, which is the unintuitive part, and it’s also why the whole subject tends to get quickly dismissed as a “a problem for next year… or the one after that”.

It’s not like a Mission: Impossible movie, where someone is sitting outside your building with a laptop inside a suspiciously windowless white van. This is a slow game, patient… and cheap: capture encrypted traffic off a backbone, store it, and wait. Storage is the only cost, and storage has never been cheaper.

This strategy has a name: harvest now, decrypt later (or HNDL for short). It’s an attack against the key-exchange, which occurs at the start of a session where two machines agree on a secret to protect a channel anyone can read. Everything after that depends on it. Break the key exchange and you have the session. All of it. Whenever you get around to it.

Classical key-exchange is breakable by a sufficiently large quantum computer. We’ve known how to for years. The only question still open is the date, and that date is approaching faster than ever before.

The session you are having today is the one you cannot fix

A session captured in 2026 and decrypted in 2034 is a 2026 breach with a 2034 discovery date. No amount of later diligence can go back in time to fix it. The upgrade has to happen before the traffic exists, which means now.

If you transfer payroll files, patient records, insurance claims, financial statements, engineering drawings, legal discovery… very little of that becomes harmless in a decade. Some of it never does.

What we actually negotiate

Every protocol we terminate negotiates a hybrid post-quantum key exchange:

• SFTP negotiates mlkem768x25519-sha256, which is ML-KEM-768 combined with X25519

• FTPS, FTPES and HTTPS negotiate X25519MLKEM768, the TLS 1.3 equivalent

And hybrid is the keyword here. Both halves run, and the session key is derived from both. An attacker has to break the classical exchange and the ML-KEM to decrypt the session.

And behind the protocol endpoints…

The four protocols are the part your clients connect to. But there is a second set of connections behind them that most vendors never talk about: the platform’s own control plane, and its relative inter-component data plane.

For example, a session on SFTP.cloud involves three components: the Protocol Head that terminates your connection, the control plane that authorizes it, and the Storage Connector running inside your own network. Every link between those components is mutually authenticated TLS (or mTLS for short) and every one of those links also negotiates a hybrid post-quantum key exchange.

Where everybody else stands

We checked the published documentation of nine other vendors on September 21, 2026. Their own official release notes, cipher lists and security pages. Here’s what we found.

AWS Transfer Family has support for hybrid ML-KEM key exchange since May 2025, selected through a security policy, but they only support it for SFTP. Their own security policy reference shows the TLS cipher section is unchanged, so AWS Transfer Family’s FTPS remains only classical.

Files.com has a standing documentation page on post-quantum cryptography, where they say they will ship across HTTPS, FTPS and SFTP when the ecosystem is ready. They also say that there is no target date, and their published cipher list confirms nothing has shipped.

Five other vendors are documenting cryptographic work and leaving post-quantum out. GoAnywhere added four classical Diffie-Hellman key exchange algorithms to its FIPS mode in April 2026. Cleo added three more in the Harmony 5.8.1 line, patched as recently as 10 September 2026. CrushFTP publishes a complete enumerated key exchange list with no hybrid entry, in a changelog that tracks cryptography closely enough to record removing DSA. Serv-U's July 2026 release notes document an OpenSSL update to version 3.0.21, which is several series below the one that introduced ML-KEM. MOVEit Transfer 2026's release notes give OpenSSL 3 and FIPS mode as the cryptography headline and doesn’t mention post-quantum anywhere.

Finally, three other vendors publish too little to say anything about them. Kiteworks, Couchdrop and sftpcloud.io do not publish their cipher inventories, or at least we weren’t able to find them. Absence of a mention is not evidence of absence though. All we can say about these is that we simply don’t know what they support.

Before you compare datasheets…

If you go and read those pages yourself you will run into statements like “FIPS 140-3 everywhere”, often as the headline cryptographic claim for a 2026 release.

FIPS 140-3 is a validation that a cryptographic module is correctly built and correctly implements approved algorithms. It says literally nothing about quantum resistance, because the approved algorithms it validates are only the classical ones.

So the two properties are independent. A product can be FIPS 140-3 validated and still not at all quantum-secure.

The client’s role in all this

The client has to cooperate. A hybrid post-quantum key exchange requires both ends. Connect with an OpenSSH 8 client and you will get a classical exchange, because the alternative would be to refuse the connection.

To ensure older client software is supported, SFTP.cloud does also offer classical key-exchange algorithms, but hybrid post-quantum are always preferred when the client-side also supports them. And if your SFTP.cloud site runs on a Dedicated Tier instance, you can configure strict post-quantum resistance, refusing all classical-only algorithms outright (if you so wish).

Check it yourself, it only takes a minute

You do not have to take any of this from us. Against any SFTP endpoint, ours or your current one run this:

ssh -vvv -p 22 user@endpoint 2>&1 | grep -i “kex: algorithm”

If the answer contains mlkem or sntrup, that session was post-quantum. If it comes back with curve25519-sha256 or a diffie-hellman-group variant, it was not.

And for your FTPS, FTPES, or HTTPS endpoints, ask the TLS handshake which group it settled on. You just need OpenSSL 3.5 or later to run this:

openssl s_client -connect host:port -groups X25519MLKEM768 </dev/null 2>&1 | grep -i “group\|Negotiated”

Run it against us. Then run it against the MFT solution you use today.

Sources

• OpenSSH post-quantum cryptography

• Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3

• AWS Transfer Family, post-quantum security policies and security policy algorithm reference

• Files.com, post-quantum cryptography and published cipher list

• GoAnywhere MFT release notes

• Cleo Harmony 5.8.1 release notes

• CrushFTP SFTP algorithm list and build changelog

• Serv-U 2026.3 release notes

• MOVEit Transfer 2026, what’s new

SFTP.cloud terminates SFTP, FTPS, FTPES and HTTPS in front of storage you already own, without holding your storage credentials and without writing your files to our disks. How it works covers the architecture, and Security covers the threat model.

• A bug in our logging library, specifically affecting the syslog target, has been identified and fixed; now a stuck syslog server can no longer cause resource channel lock-up in your Syncplify software.

As always, you can download the most recent release from our website, or if you’re running Server! v8.4.0+ or R2FS! v3.0.0+ you may (more easily) self-install this update with the push of a single button in the web UI.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• If you’re running any version of Syncplify Server! between v8.1.2 and v8.4.0 your service might CRASH (and auto-restart) when the following two events happen to occur symultaneously:

  • a log file is rotated

  • a client disconnects at the exact same time

  Version 8.5.0 fixed that specific race condition. We apologize to anyone affected by this bug, and we urge everyone to update to v8.5.0 so that this doesn’t happen anymore.

• Usual small set of little bug-fixes and quality of life improvements

As always, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

But v8.4.0 carries a lot more than that. It carries a robust set of security improvements which would not have been possible without the help of one of our customers, but since we’re a security company we’re not going to name them here. We’ll just say this: You know who you are, and we cannot thank You enough!

They provided us, free of charge, with the best security assessment and pen-testing our software has ever been put through. Ever.

And that act of kindness and genuine support lead v8.4.0 to also include the following changes and improvements:

• More sensible default configurations for newly deployed instances (do not apply to updates/upgrades for obvious reasons) including but not limited to:

  • STARTTLS auth now defaults to “Required” on FTP bindings

  • Pinned-key mTLS is now on by default for all R2FS! bindings

  • SyngoDB management service now binds to 127.0.0.1

  • More sensible SANs in default self-signed certificates

  • More sensible HTTP security headers by default

  • Worker process auto-restart is now enabled by default

• Tightened ACL on database and log files

• Tightened systemd unit file configuration for all services (Linux only)

• Fixed “Timing Oracle” exposure that allowed an attacker to tell apart existing from non-existing usernames by simply measuring the server’s response time

• Legacy ssh-rsa weak host key algorithm was an automatic “re-entrant” if the SSH/SFTP service had any RSA host key in its configuration (now disabled really means disabled instead)

• Hardened build pipeline now prevents builds from a “dirty” repo (a repo that has uncommitted changes) and forces PIE executable builds on Linux

The report we received also included a couple of false positives, which we verified (not assumed) to be false positives, and as such were not addressed.

It’s important to understand that all the security improvements to the executables and environment are automatic for everyone, new install and updates/upgrades alike. But all the improvements to the default configurations are only applied to new installs, so if you’re updating/upgrading to v8.4.0 from an older version you’ll still have to review your own configuration to ensure it’s the tightest possible (compatibly with your specific needs).

We hope this addendum to the previous v8.4.0 release note effectively conveys why we consider v8.4.0 such an important update for everyone running our software.

As usual, thank you all for your attention, and for being part of our journey.