Old Software Flaws Are Still Being Exploited: What Southwest Florida Businesses Must Check

Cybersecurity headlines often focus on brand-new “zero-day” vulnerabilities. That can leave businesses with the wrong impression: if a flaw is several years old, surely it has already been fixed everywhere that matters.

CISA’s latest Known Exploited Vulnerabilities activity shows why that assumption is dangerous.

On October 8, 2026, CISA added five older vulnerabilities affecting technologies used for file transfer, DNS, document collaboration, Java web applications, and content management. The flaws were originally disclosed between 2015 and 2023, yet CISA now lists them based on evidence of active exploitation.

The affected technologies are:

• ProFTPD, a file-transfer server;
• ISC BIND, widely used for Domain Name System services;
• ONLYOFFICE Document Server, a self-hosted document collaboration platform;
• Apache Struts, a framework used by Java web applications; and
• Strapi, a content-management and application platform.

These products will not appear in every small business. They may not appear on a normal employee-computer patch report at all. One may be inside a vendor-hosted portal, web server, Linux virtual machine, firewall appliance, software bundle, development environment, or inherited cloud account.

That is the real lesson for Southwest Florida small and midsize businesses: the largest vulnerability may be the system no one knows they own.

What changed on October 8, 2026?

CISA’s Known Exploited Vulnerabilities Catalog, commonly called the KEV Catalog, is a prioritized list of security flaws that have evidence of real-world exploitation. A vulnerability does not enter the catalog merely because it has a high theoretical severity score.

The October 8 additions include:

NIST’s National Vulnerability Database identifies ProFTPD CVE-2015-3306 as a critical arbitrary-file-access issue and records its October 8, 2026 KEV addition. NIST likewise records the ONLYOFFICE issue as a critical vulnerability affecting Document Server versions before 5.6.3 under the documented configuration.

Federal remediation deadlines do not automatically become a legal requirement for a private Southwest Florida business. However, CISA urges organizations to prioritize catalog vulnerabilities because the question of exploitability has already been answered: attackers are using them.

Why old vulnerabilities remain useful to attackers

An old vulnerability is not the same as an inactive vulnerability. Several conditions keep older flaws valuable.

Forgotten systems stay online

A server may have been created for a temporary project, inherited through an acquisition, left behind after a website redesign, or placed online by a former vendor. If no current owner is accountable for it, it may keep running for years.

Open-source components can be hidden inside products

A business may never knowingly install BIND, Struts, or ProFTPD. A software vendor, hosting company, managed appliance, website developer, or cloud image may include the component. The organization sees the product name while the vulnerable library or service remains underneath it.

Patching responsibility is unclear

“The vendor manages it” is not a complete answer. The software vendor, hosting provider, website agency, MSP, internal administrator, and customer may each assume someone else is patching the system.

Internet-facing services are continuously scanned

Attackers can automate the discovery of exposed services. They do not need to know a specific company in advance. A vulnerable server can be found because it answers on the internet and displays a recognizable behavior or version.

Business fear delays replacement

Organizations often postpone changes to DNS, websites, file-transfer workflows, or line-of-business applications because those services are important. Ironically, the fear of an outage can preserve the conditions for a larger security incident.

Severity scores can distract from exploitation evidence

Teams sometimes patch only the highest numerical scores. But a medium- or high-rated vulnerability that attackers are actively exploiting may deserve priority over a more severe flaw that is unreachable, mitigated, or not applicable.

The right question is not merely “How high is the score?” It is “Do we run the affected technology, is it reachable, is exploitation known, what could an attacker access, and how quickly can we mitigate it safely?”

Who should pay attention?

The five products are technical, but the exposure can exist across ordinary business relationships.

Businesses with websites or customer portals

Web agencies and software developers may use Apache Struts, Strapi, reverse proxies, Linux servers, or container images behind a public website. A modern-looking website does not guarantee that every underlying component is current.

Organizations using self-hosted collaboration tools

Companies that operate alternatives to Microsoft 365 or Google Workspace may use ONLYOFFICE Document Server directly or as part of a larger file-sharing platform. Healthcare, legal, engineering, nonprofit, and professional-services organizations should identify who operates and patches the server.

Businesses exchanging files with vendors

Manufacturers, construction firms, accountants, insurance agencies, medical organizations, and professional firms may still rely on FTP-based workflows. The service may be hosted internally, by a software vendor, or by a third party.

Organizations operating DNS infrastructure

Most small businesses use DNS through a registrar, cloud provider, internet service provider, or managed service provider. Some, however, operate internal or external BIND servers, or depend on products that bundle BIND. A DNS outage can make websites, applications, email routing, remote access, and internal services appear unavailable.

Businesses with custom or legacy applications

Older Java web applications may depend on Apache Struts. The application may still be essential even if no one currently knows its original architecture. Custom software often survives longer than the team that built it.

MSPs, hosting providers, and software vendors

A provider can multiply risk across customers. One overlooked shared server, remote-management plane, DNS platform, or document service can affect many organizations. Providers need both customer-level inventories and an inventory of their own infrastructure.

The difference between an endpoint inventory and a real asset inventory

Many organizations can produce a list of Windows laptops from their remote monitoring or endpoint-security platform. That is useful, but it is not a complete attack-surface inventory.

A real inventory should also include:

• Windows and Linux servers;
• cloud virtual machines and orphaned cloud accounts;
• containers and container images;
• public IP addresses and internet domains;
• DNS servers, zones, registrars, and name-service providers;
• websites, APIs, portals, and development systems;
• firewalls, VPNs, NAS devices, cameras, and other appliances;
• file-transfer servers and vendor exchange points;
• hosted applications and SaaS integrations;
• disaster-recovery systems and powered-off replicas;
• vendor-managed systems;
• open-source components and software dependencies; and
• assets created outside the normal IT purchasing process.

The inventory also needs ownership. Every important asset should have a technical owner, business owner, data classification, location, internet-exposure status, support status, patch responsibility, backup method, and retirement or review date.

Without ownership, a scanner produces findings but not decisions.

A practical response plan for the five CISA additions

Businesses should not begin by blindly scanning the public internet or changing production systems without authorization. The response should be deliberate and fast.

1. Check whether the technologies exist

Search authorized internal sources for ProFTPD, BIND or named, ONLYOFFICE Document Server, Apache Struts, and Strapi. Useful sources include:

• configuration-management and RMM data;
• Linux package inventories;
• vulnerability-scanner results;
• cloud and hypervisor inventories;
• container registries and software bills of materials;
• web-server and application documentation;
• DNS and registrar records;
• firewall, load-balancer, proxy, and EDR telemetry;
• vendor contracts and architecture diagrams; and
• questions to developers, website agencies, hosting providers, and MSPs.

Search for products and components, not just CVE numbers. A vendor may use a customized or embedded version that does not report itself cleanly.

2. Determine exposure and business importance

For each possible match, establish:

• the exact product and version;
• whether the vulnerable feature or configuration is present;
• whether it is reachable from the internet or untrusted networks;
• what identity or privilege an attacker would need;
• what data, credentials, or connected systems it can access;
• what logs exist;
• who owns the service; and
• what would happen if the service were taken offline.

An internet-facing document or file-transfer server with sensitive customer data deserves immediate attention. An isolated laboratory system may follow a different response sequence, but it still needs an owner and resolution.

3. Follow current vendor guidance

Use the software publisher’s supported release and mitigation guidance. Do not rely only on a version number copied from a general vulnerability page. Packages may be backported by Linux distributors, product vendors may embed components differently, and configuration can affect applicability.

Where an update or mitigation is unavailable, CISA’s catalog action calls for discontinuing use of the affected product. A temporary compensating control must not quietly become the permanent plan.

4. Preserve evidence before disruptive changes

Active exploitation means the response cannot stop at patching. A patch closes a weakness; it does not remove an attacker who may already have gained access.

Before wiping logs or rebuilding a system, preserve appropriate evidence:

• authentication and administrative events;
• application, web, DNS, FTP, proxy, firewall, and EDR logs;
• recent configuration and account changes;
• newly created files, web shells, services, tasks, keys, or containers;
• suspicious outbound connections;
• relevant cloud audit events; and
• a timeline of alerts and administrator actions.

The scope of forensic work should be chosen by a qualified responder based on exposure, exploitability, business impact, and evidence. Not every affected package means compromise, and not every clean antivirus scan proves the system was untouched.

5. Patch, mitigate, isolate, or retire

Use a prioritized decision:

1. Apply the vendor-supported update after validating backups and testing critical workflows.
2. If immediate patching is not possible, apply the vendor’s documented mitigation.
3. Remove internet exposure or isolate the service while the permanent fix is prepared.
4. Retire the system if it is unused, unsupported, or cannot be secured.

Firewall rules and web-application firewalls can reduce exposure, but they should not be assumed to make a vulnerable product safe. Controls need documented scope, testing, monitoring, an owner, and an expiration date.

6. Hunt for signs of exploitation

The hunt should be tailored to the product and environment. It may include reviewing:

• unexpected file reads, writes, uploads, or path traversal patterns;
• unusual FTP commands or file locations;
• DNS service crashes, malformed queries, or repeated restarts;
• web requests containing abnormal method prefixes or encoded traversal characters;
• new administrative accounts or changed permissions;
• access to password hashes or reset tokens;
• processes launched by a web or document service;
• outbound connections from a server that normally receives traffic only; and
• evidence of credential use on connected systems.

Published indicators are useful but incomplete. Attackers can change filenames, IP addresses, domains, and tooling. Behavior and context matter.

7. Validate the business service after remediation

Do not declare success when the package manager reports “updated.” Test the service:

• Can legitimate users authenticate?
• Do documents open and save correctly?
• Do file-transfer jobs still complete?
• Is DNS resolving internal and external names as expected?
• Are APIs, portals, and integrations functioning?
• Are logs, EDR, backups, and monitoring still active?
• Did the update introduce a configuration reset or unsupported dependency?

Security changes that silently break payroll, patient scheduling, vendor exchange, or customer access create another kind of incident.

8. Close the inventory and ownership gap

Once the immediate work is complete, record why the affected software was present, why it was missed, and how the process will change.

Possible improvements include:

• requiring all internet-facing assets to be registered;
• continuous external attack-surface monitoring;
• credentialed scanning of servers and network devices;
• Linux, container, and cloud coverage in vulnerability management;
• software bill of materials collection for custom applications;
• vulnerability-notification requirements in vendor contracts;
• regular reviews of DNS, domains, certificates, and cloud accounts;
• defined patch and emergency-change service levels; and
• a retirement process that removes systems, identities, DNS records, backups, and monitoring cleanly.

What each technology teaches

The five vulnerabilities form a useful checklist of blind spots.

ProFTPD: file-transfer systems can write into trusted workflows

File-transfer servers often connect external parties to internal processes. A dangerous file write may affect a website, shared directory, processing queue, or script. Businesses should verify not only the server version but also where uploaded files go and what automatically processes them.

BIND: availability is a cybersecurity issue

The BIND vulnerability can cause a denial of service. Confidential data does not have to be stolen for the business to suffer. DNS failure can make email, websites, cloud applications, and internal services unreachable. Redundant DNS, configuration control, monitoring, and tested failover are part of security and continuity.

ONLYOFFICE: collaboration platforms hold high-value data

Self-hosted document systems may contain contracts, financial records, personnel information, legal documents, or intellectual property. They also commonly integrate with identity providers and storage platforms. An exposed document service should be treated as both a server risk and a data-access risk.

Apache Struts: frameworks can outlive developers

A business application may keep working long after its original development team is gone. The visible application name may not reveal the framework underneath. Custom applications need a maintained component inventory, upgrade owner, source-code custody plan, and supported hosting path.

Strapi: administrative access must be protected and monitored

The documented Strapi issue emphasizes that not every exploit begins without credentials. Stolen, weak, shared, or excessive administrative access can convert a software weakness into sensitive-data exposure. MFA, least privilege, administrator logging, and rapid offboarding remain important even after patching.

Where AI can help

AI can improve the speed of authorized vulnerability triage when it operates inside a controlled process.

Useful applications include:

• normalizing asset exports from multiple tools;
• matching product names, package names, and version strings;
• summarizing vendor advisories and identifying stated prerequisites;
• reviewing software bills of materials for affected components;
• clustering similar scanner findings;
• explaining unfamiliar configuration files or legacy code;
• generating product-specific validation and test checklists;
• summarizing large volumes of sanitized logs;
• correlating asset, identity, network, and endpoint evidence; and
• drafting executive updates, change plans, and customer notifications for human review.

AI should not autonomously probe public systems, exploit a vulnerability, patch production, block critical traffic, delete a server, or conclude that an environment is clean. It can misidentify backported packages, confuse product versions, hallucinate remediation steps, and miss business-specific dependencies.

Sensitive logs, credentials, source code, customer data, and security architecture should be submitted only to an AI platform explicitly approved for that data. Human responders must verify applicability, preserve evidence, approve changes, and decide when legal, insurance, vendor, or law-enforcement coordination is required.

AI is best used as an analyst’s accelerator—not as the accountable incident commander.

Business continuity: patch urgency without careless outages

An actively exploited vulnerability creates urgency, but urgency does not justify an untested change to DNS, document collaboration, file transfer, or a customer portal.

Before remediation, establish:

• the business owner and technical owner;
• the maintenance window and expected outage;
• a recent, protected, and restorable backup;
• configuration exports and keys;
• the rollback method;
• a functional test plan;
• user and vendor communications;
• manual workarounds for essential processes; and
• a go/no-go decision point.

For Southwest Florida organizations, also consider storm operations, power stability, remote access, and staff availability. Avoid a high-risk change when severe weather may interrupt power, connectivity, or vendor assistance. At the same time, do not let hurricane season become an open-ended reason to leave an exposed system vulnerable.

For DNS, test redundancy and provider access before changing production. For file transfer, preserve partner contact details and define a secure temporary exchange method. For document systems, verify data backups and export options. For public applications, prepare a maintenance page and customer-support message.

Resilience means the organization can reduce cyber risk while continuing or restoring the business service.

Questions to ask your IT provider, hosting company, or web developer

Business leaders can use these questions immediately:

1. Do we operate ProFTPD, ISC BIND, ONLYOFFICE Document Server, Apache Struts, or Strapi anywhere?
2. Have you checked hosted, Linux, cloud, container, appliance, and disaster-recovery environments—not only employee computers?
3. Which of our systems are reachable from the internet?
4. Who owns patching for every website, portal, DNS service, and file-transfer workflow?
5. What exact versions and configurations are in use?
6. Has current vendor guidance been applied and independently verified?
7. Were any affected services exposed before remediation?
8. What logs were preserved, and what compromise assessment was performed?
9. Could the affected server reach customer data, credentials, backups, or other systems?
10. How do you monitor CISA’s KEV Catalog and convert additions into customer-specific actions?
11. What is the emergency-patching service level for an internet-facing exploited vulnerability?
12. How are unsupported or ownerless systems identified and retired?
13. Do our contracts clearly assign vulnerability notification and remediation responsibility?
14. When was our external attack surface last reconciled with our internal asset inventory?

A credible answer should include evidence: asset identifiers, versions, exposure, patch or mitigation status, validation results, residual risk, and named ownership.

How Managed Intelligence Advisors can help

Managed Intelligence Advisors can help Southwest Florida organizations turn CISA alerts into business-specific action rather than generic fear.

That can include:

• identifying internet-facing domains, IP addresses, services, and cloud assets;
• reconciling RMM, EDR, vulnerability, cloud, DNS, backup, and vendor inventories;
• locating Linux packages, containers, open-source components, and custom applications;
• validating whether a vulnerability actually applies to the deployed version and configuration;
• prioritizing remediation using exploitation evidence, reachability, data access, and business impact;
• coordinating vendors, web developers, hosting providers, and internal owners;
• designing safe patch, mitigation, isolation, rollback, and service-validation plans;
• reviewing logs and coordinating qualified incident response when compromise is possible;
• strengthening segmentation, privileged access, monitoring, and backups;
• documenting vendor responsibility and emergency-notification expectations;
• establishing ongoing KEV monitoring and response procedures; and
• creating an executive-ready risk register with accountable owners and deadlines.

The objective is not to chase every vulnerability with equal urgency. It is to know what the organization runs, identify what attackers are actually exploiting, fix the highest-risk exposures safely, and verify that the business still works afterward.

Suggested call to action: Request an Internet-Facing Asset and Known Exploited Vulnerability Readiness Review from Managed Intelligence Advisors.