Why an Optional Module Few Customers Use Can Still Be Your Front Door

Kiteworks said the critical flaw that prompted its September 2026 precautionary shutdown lived in Advanced Forms, a module used by fewer than 1% of its customers. That figure was offered as reassurance. For most defenders it should land as a question: do you know whether you are in the 1%? And more broadly, do you know which optional features on your internet-facing platforms are switched on, who switched them on, and what they expose? This piece is about the security economics of optional modules and how to build a feature inventory before a vendor's phone call forces you to.

The 1% problem

Enterprise platforms are sold as suites. A managed file transfer product ships with collaboration, email encryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key., web forms, APIs and integrations; a security appliance ships with VPN, web proxy, mail filtering and a management portal; a CMS ships with plugins and themes. Vendors license these modules separately, but the code for all of them is usually present in every installation. Whether a given module is reachable from the internet depends on configuration, licensing and, often, an administrator's decision years ago that nobody documented.

From the attacker's side, a module used by 1% of customers is not less valuable. It is less scrutinized. The core transfer engine of an MFT platform has been fuzzed, pen-tested and attacked in the wild for a decade. A data-collection module added recently, sold to a niche such as FedRAMPFedRAMP🛡️The US Federal Risk and Authorization Management Program, a standardized process for assessing and authorizing cloud services used by federal agencies. Products or modules sold to FedRAMP-bound customers often serve a small, specialized user base, which can mean less real-world security scrutiny than a vendor's core offering.-bound government contractors, has had a fraction of that attention. Bugs cluster where attention does not.

From the defender's side, the 1% framing produces a false sense of exemption. Kiteworks asked everyone to shut down precisely because neither it nor its customers could quickly establish who was exposed. The news coverage of the Kiteworks precautionary shutdown and Advanced Forms flaw made clear that this uncertainty, not the bug itself, is what turned a niche vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. into a global outage.

Why unauthenticated-facing modules are different

Not every optional module carries the same risk. The ones that matter are those that accept input from people who have not authenticated. Public web forms, anonymous upload links, self-registration pages, guest-access portals and unauthenticated API endpoints all run code on your server on behalf of anyone on the internet. A vulnerability in that code is a pre-authentication vulnerabilityPre-Authentication Vulnerability🛡️A flaw that can be exploited without valid credentials or an active session, typically by sending crafted input to a network-exposed service. Pre-auth bugs in internet-facing systems are the most urgent class to patch because any remote attacker can reach them. by definition: no stolen credential, no phishingPhishing🛡️A social engineering attack using fake emails or websites to steal login credentials or personal info., no insider required.

A web-forms module is a textbook example. Its whole purpose is to let outsiders submit structured data and attachments. That means it parses untrusted input, stores files, and often hands the results to internal workflows or databases. Each of those steps is an opportunity for injection, deserializationDeserialization🛡️The process of converting stored or transmitted data back into an object. Insecure deserialization can allow attackers to execute code by manipulating serialized data., path traversalPath Traversal🛡️A web vulnerability (CWE-22) where user-supplied input in a file path escapes the directory the application intended to serve from, typically via parent-directory references, letting an attacker read or write files elsewhere on the server. or upload abuse. The feature is doing exactly what it was designed to do when it becomes the attack path.

Contrast that with an optional reporting module only administrators can reach after logging in. A flaw there is serious, but it is one step removed from the internet. Your inventory should rank modules by how far they are from an unauthenticated user, not by how many people in the business use them.

Build the inventory

You cannot manage the attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. of features you do not know are enabled. The inventory has four parts.

Start from the outside. Scan your own external ranges and map every path, port and virtual host each platform exposes. Compare what you find against what the product's documentation says a default install exposes. Anything beyond the default is an enabled feature; anything you cannot explain is a finding.

Then go inside. For each platform, pull the list of licensed and enabled modules from the administrative console. Reconcile it against the external scan: a module that is licensed but not exposed is a lower priority; a module that is exposed but nobody remembers licensing is your highest.

Record ownership. For every enabled module, identify the business owner who requested it and the last time anyone confirmed it is still needed. Features whose owner has left the organization are prime candidates for disabling.

Classify by exposure. Tag each module as unauthenticated-facing, authenticated-external, or internal-only. This is the field that lets you answer a vendor's emergency advisory in minutes rather than days.

Store this in the same asset register you use for the servers themselves. A CMDB entry that says "MFT server" without listing its enabled modules is as incomplete as one without an IP addressIP Address🔐A unique numerical identifier assigned to every device connected to the internet..

Turn the inventory into decisions

Once you can see the modules, the choices are straightforward.

Disable what you do not use. Every optional module that is enabled without an owner or a current business case should be switched off. This is the cheapest attack-surface reduction available, and it costs nothing in licensing because the code is already paid for.

Front what you must keep. Where an unauthenticated-facing module is genuinely needed, put a web application firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. or reverse proxyReverse Proxy🛡️A server that sits in front of one or more backend services, terminating client connections and forwarding requests to the backend. It is the standard place to add authentication, TLS and access control to a service that lacks its own, without modifying the application. in front of it that can block a path or content type quickly. That gives you a per-feature kill switchKill Switch🔐A VPN feature that blocks all internet traffic if the VPN connection drops, preventing data leaks. the vendor may not provide, so an emergency advisory does not require a full shutdown. It is a stopgap, not a fix, but it turns a nine-hour outage into a targeted rule.

Log it distinctly. Route the unauthenticated paths to their own log stream so that hunting for exploitation of one module does not mean sifting the whole platform's traffic.

Ask the vendor the hard question. Can they disable a single module across all customers remotely? Can you disable it locally without taking the platform down? If the answer to both is no, that is a procurement finding to raise before the next renewal. The learn article on why managed file transfer platforms are an extortion crew's favorite target explains why MFT vendors in particular should expect this question now.

Rehearse the emergency

Finally, use the inventory to script the response you will need when the next advisory arrives without a CVE. For each unauthenticated-facing module, write down the exact steps to disable it, block it at the proxy, or take the host offline, along with who is authorized to approve each action and what breaks when you do it. When a warning comes, the question "are we affected?" should be answerable from the register, and the question "how do we stop the bleeding?" should be answerable from the runbook. The companion piece on how to bring a file-transfer server back online safely after a precautionary shutdown covers the other half of that runbook.

Kiteworks' customers spent a weekend dark because a module most of them did not use might have been reachable on their servers. The vendor's response was defensible. The uncertainty that made it necessary is something you can eliminate on your own systems this quarter, with a spreadsheet and a scanner.