City of Columbia SC Ransomware Attack: What We Know and What Helps

The City of Columbia, South Carolina, confirmed on 23 October 2026 that it is the victim of a ransomware attack first detected on 20 October. Apps such as MyColaSC and GIS are offline; police, fire, 911, water and bill payment still work. The city has not said whether personal data was taken. Residents should call (803) 545-3300 for service requests.

The short version

• Detected: Tuesday 20 October 2026, by city IT, who contacted SLED the same day.
• Confirmed as ransomware: Friday 23 October, in a City Manager video and a written update.
• Offline: MyColaSC, online Animal Services, parks reservations and GIS. Working: police, fire, 911, water and payments.
• Data: the city says sensitive data was on the affected network and it is still assessing whether any was accessed or taken.
• Not disclosed: the ransomware family, the entry point, any ransom demand or any group claiming the attack.
• The lesson for other cities: resilience, not attribution. Know which services must never go down, keep backups an attacker cannot reach, and keep an inventory of the software and vendors behind every resident-facing app.

What happened

Columbia is the capital of South Carolina. On 20 October the city's IT staff identified what the city called "suspicious activity within the network." The city says its IT department immediately contacted SLED to investigate, assess the scope and determine the potential impact. Affected applications were taken offline as a precaution, which the city describes as a way to contain the incident and support the investigation and recovery.

Local outlets carried the city's first statement on the evening of 20 October. That statement called it a "security incident" affecting select applications and services, listed six resident-facing services as affected, and said public safety and utility systems were working. It gave no cause and no restoration timeline.

On 21 October the city posted the same statement on its own news page. Later that day it posted a separate notice saying Animal Services would close to the public on Thursday 22 October for internal staff training, so that staff could keep the shelter running "during the ongoing disruption to the City's network and shelter management software." The shelter was due to reopen at noon on Friday 23 October. Local reporting by WIS and HERE Columbia also describes the shelter closing temporarily on Wednesday 21 October because of the outage.

On the evening of Friday 23 October, City Manager Teresa Wilson posted a video on the city's Facebook page confirming that the city had been hit by ransomware, according to WIS. The same night the city published a written update on columbiasc.gov titled "City of Columbia Provides Update on Cybersecurity Incident." That update is the most complete primary statement so far, and most of this post rests on it.

Timeline

All times are as published. Eastern Daylight Time (EDT) is four hours behind UTC in October. Where a source gave only a UTC timestamp, we show both.

What the city has not said

This list is as important as the one above. As of 24 October the city has not disclosed:

• the ransomware family or the group behind it;
• how the attacker got in, or when the first access happened;
• whether a ransom was demanded, or what the city will do about one;
• whether any personal information was copied out of the network;
• how many people, if any, are affected;
• when the offline services will return.

The phrase "involved sensitive data" is easy to over-read. It tells you sensitive data sits on the part of the network the incident touched. It does not, on its own, tell you that data was viewed or stolen, and the city is explicit that it is still assessing that question. Nothing we have seen links this incident to any specific vulnerability, product or CVE.

Who is affected

The absence of Business Licensing and Planning and Development Services from the 23 October list could mean those services came back, or that the city simply summarised differently. The city has not said either way, so treat both as possibly still affected and call the department directly.

Why the services that stayed up matter

According to the city, every life safety and core utility service kept running through a confirmed ransomware attack: police, fire, 911, water and payments. We do not know what architecture or decisions produced that outcome in Columbia, and we will not guess. But it is the outcome every city should plan for, and the rest of this post is about how.

How municipal ransomware usually unfolds, in plain language

This section describes the general pattern that federal guidance documents, not what happened in Columbia. The city has not disclosed its attack path.

Ransomware against a local government is rarely a single event. The joint CISA, MS-ISAC, NSA and FBI #StopRansomware Guide describes a sequence that usually runs over days or weeks before anyone sees a ransom note:

1. Initial access. The guide lists the usual ways in: internet-facing services such as remote desktop left exposed, unpatched VPNs and other edge devices, phishing that leads to stolen credentials or malware, and compromised third parties such as managed service providers.
2. Establishing a foothold. Attackers commonly install remote management tools or command and control frameworks so they can return.
3. Moving sideways. They harvest credentials, enumerate Active Directory and look for administrator accounts that reach many systems.
4. Taking data. Many groups copy data out before encrypting anything, so they can threaten to publish it. The guide names tools such as Rclone as signs of this stage.
5. Removing recovery options. Attackers try to delete shadow copies and find and destroy reachable backups. The guide notes that many variants specifically look for accessible backups.
6. Encryption and extortion. Files and systems are encrypted, and a ransom note appears.

Technical details

This is the section where we would normally list affected versions, CVE numbers, file hashes and indicators of compromise. For this incident, none have been published. The city, SLED and the FBI have released no indicators, no malware name and no initial access vector, and we will not invent any. What we can give defenders is the exact public record, the legal framework that applies in South Carolina, and the concrete technical controls from federal guidance written for exactly this kind of attack.

Published indicators

If indicators are published later, they will most likely appear in a SLED or FBI release, or in a CISA advisory if the variant is part of a wider campaign. Check those before relying on any third-party list.

The city's disclosure records

The update page itself sat behind a browser challenge when we tried to load it directly, so we read the full text from the city's public RSS feed at https://columbiasc.gov/feed/. Local outlets quote the same wording.

Service status matrix

Contact points published by the city

The South Carolina breach notification framework

The city has not said that personal information was acquired, and the law below only applies if it was. We include it because residents will ask what happens next, and because every South Carolina local government should know these provisions before it needs them.

Section 1-11-490 of the South Carolina Code covers breaches of security of agency data. Its definition of "agency" includes any agency, department, board, commission or committee "of the State or a political subdivision of it." The key provisions:

The definition of personal identifying information comes from Section 16-13-510(D). It includes Social Security numbers, driver's license and state ID numbers, checking and savings account numbers, credit and debit card numbers, PINs, electronic identification numbers, digital signatures and dates of birth, plus names and addresses when linked to those other elements. Note that this list is broader than the one in the separate business breach statute, Section 39-1-90, which applies to "a person conducting business in this State."

Two practical points follow. First, "acquisition" is the trigger, which is why investigators spend so much effort establishing whether data left the network, not just whether an attacker could see it. Second, the law enforcement delay in subsection (C) means a quiet period after an incident does not, by itself, tell residents anything about whether a notice is coming.

Federal guidance: the specific technical controls

The #StopRansomware Guide (September 2023 update, from CISA, MS-ISAC, NSA and FBI) is the most directly relevant technical reference for a city IT team. Several of its recommendations are concrete enough to check this week:

CISA also offers free Cyber Hygiene services to state, local, tribal and territorial governments. Vulnerability scanning checks public static IPv4 addresses continuously, sends weekly reports and sends ad hoc alerts for urgent problems such as risky services and known exploited vulnerabilities. Web application scanning covers the OWASP Top Ten with monthly reports. Sign up by emailing vulnerability@cisa.dhs.gov with the subject line "Requesting Cyber Hygiene Services"; CISA says service typically begins within three business days.

What changed since first reports

What to do now

If you live in Columbia

1. Use the phone line for service requests. Call (803) 545-3300 for anything you would normally report in MyColaSC. Call 911 for emergencies.
2. Pay bills through the normal channels. The city says the Payment Center and online payment services are working. Use the payment link on the city's own website rather than one sent to you in a message.
3. Expect scams that borrow the headline. After a public incident, criminals often send messages pretending to offer refunds, credit monitoring or "verification." The city has not announced any notice to individuals. If you receive one, check it against the city's website or call the city before clicking anything or giving information.
4. Consider a credit freeze if you are worried. A freeze with the three nationwide credit bureaus is free in the United States and stops new credit being opened in your name. You do not need to wait for a breach notice to do this.
5. Watch for an official notice. If the investigation finds that personal identifying information was acquired, South Carolina law requires notice to affected residents, subject to law enforcement delay. The city has said it will provide updates on "any identified impacts to information."

If you run IT for a city, county or utility

These steps are drawn from the #StopRansomware Guide and CISA's services, adapted with real commands. Run them only against systems and address ranges you own.

1. Write down your never-down list, and its dependencies. For each critical service (dispatch, 911, water control, payments, payroll), record the servers, accounts, directory services, network paths and vendors it depends on. If a citizen portal shares a domain controller or a hypervisor cluster with dispatch, that is your first segmentation project.

2. Check what you expose to the internet. From an outside network, scan your own public ranges for the services the guide says should never be exposed:

# Scan only address ranges your organisation owns
nmap -Pn -p 22,139,445,3389,5985,5986 --open -oN exposed.txt 203.0.113.0/24

Then sign up for CISA's free Cyber Hygiene scanning so someone else checks continuously.

3. Check SMB settings on Windows servers. The guide recommends SMB 3.1.1 with encryption or signing. In PowerShell on each server:

Get-SmbServerConfiguration |
  Select-Object EnableSMB1Protocol, RequireSecuritySignature, EncryptData
# Expect EnableSMB1Protocol = False and RequireSecuritySignature = True

4. Confirm PowerShell logging is on and retained. The guide asks for at least 180 days of retention:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -ErrorAction SilentlyContinue
Get-WinEvent -ListLog 'Microsoft-Windows-PowerShell/Operational' |
  Select-Object LogName, MaximumSizeInBytes, LogMode

5. Hunt for the precursors the guide names. If you collect process creation events (Windows Security event 4688 with command line, or Sysmon event 1), search for shadow copy and boot configuration tampering:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-14)} |
  Where-Object { $_.Message -match 'vssadmin(.exe)?\s+delete|bcdedit(.exe)?.*recoveryenabled|wbadmin(.exe)?\s+delete' } |
  Select-Object TimeCreated, Message

Also look for remote management tools you did not install, and for unexpected large outbound transfers from servers that hold resident data.

6. Prove your backups are out of reach and restorable. An "offline" backup that is mounted to a domain-joined server is not offline. Test a restore, not just a backup job. For example, with restic:

restic -r /mnt/offline-repo snapshots
restic -r /mnt/offline-repo check --read-data-subset=5%
restic -r /mnt/offline-repo restore latest --target /tmp/restore-test --include /srv/permits

Whatever tool you use, the evidence you want is a recent, timed restore of a real application to clean hardware.

7. Keep golden images and infrastructure as code current. If you cannot rebuild the citizen portal server from a known template, you will be restoring the attacker's persistence along with your data. Keep templates in version control with an offline copy.

8. Inventory the software inside each resident-facing app. Permit portals, reservation systems and GIS front ends are built from open source libraries and container images. Generate a software bill of materials (SBOM) for each one you build or host, and ask vendors for SBOMs for the ones you buy. When an advisory lands, you want to answer "which of our services run this?" in minutes, not days.

9. Agree your reporting path before you need it. The city's sequence (local IT, then state law enforcement, with federal partners as needed) is a sensible model. Write down names and phone numbers for your state police cyber unit, your FBI field office, CISA, your cyber insurer and your outside counsel. Keep a printed copy, because email may be the first thing you lose.

What would have helped

This section is for any local government. It is not a judgement on the City of Columbia, which by its own account detected the activity, called in state investigators the same day, kept public safety and utility services running, published a phone workaround and confirmed ransomware publicly within four days. We do not know how the attacker got in, so we cannot say what would have stopped it, and we do not claim that anything would have.

Practices that keep a city running through ransomware

Decide what must never go down, then isolate it. The single most important design decision is that dispatch, 911, water and payments do not share failure domains with the citizen portal. That means separate administrative credentials, separate management networks and, where possible, separate directory trust. The #StopRansomware Guide's recommendation to segment by business unit and separate IT from operational technology is the starting point.

Keep backups an attacker cannot reach. Offline or immutable copies, encrypted, with credentials that are not stored in the domain an attacker will try to own. Test restores on a schedule, and time them, because the restore time is what decides how long residents wait.

Be able to rebuild, not just restore. Golden images and infrastructure as code let a team stand up clean servers and reload data, rather than restoring a server image that might contain the attacker's tools.

Patch what faces the internet first, and know what you expose. Federal guidance puts internet-facing servers and known exploited vulnerabilities at the top of the patch queue. CISA's free scanning for local governments is one of the easiest wins available. Our October edge device zero-days roundup covers several edge device flaws from this month; we are not suggesting any of them is linked to Columbia.

Require phishing-resistant MFA where it counts. Email, VPN, remote access and every administrator account. Separate admin accounts from daily accounts.

Keep a current inventory of resident-facing software and the vendors behind it. For each portal and tool: who built it, where it runs, what it connects to, which open source components it contains, and who to call at the vendor. This is the work that turns "we took several apps offline as a precaution" into "we brought them back one by one, in order, with confidence."

Put security terms in vendor contracts. The guide calls out managed service provider and third-party access specifically. Limit it, log it and write requirements into the contract, including notice obligations if the vendor is compromised. Our post on third-party risk lessons from the IDCF Cloud ransomware incident goes deeper on provider risk.

Rehearse the response, including on paper. The guide asks for a hard copy and an offline version of the plan, approved in writing by leadership.

Where Safeguard fits

Safeguard is a software supply chain security platform. For a city ransomware incident, be clear about what that does and does not cover.

What Safeguard does not do here. It does not detect intrusions, monitor networks, stop ransomware from running, protect Active Directory, manage backups or respond to an incident. It is not an EDR, a SIEM, a backup product or an incident response service. The city has not disclosed the attack path, so we cannot say Safeguard would have prevented this, and we do not claim it.

What Safeguard does do that is relevant. Resident-facing apps such as permit portals, service request tools and map viewers are software, and much of that software is open source libraries and container images. Known vulnerable components in internet-facing apps are one of the entry points federal guidance warns about. That part is in scope.

• Know what you run. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> reads an SBOM a vendor gave you. Results land as JSON under ./output. In the platform you can see which projects contain a given component and version, which is the question you need answered when an advisory names something you might run.
• Match against vulnerability data, then rank by reachability. Findings are matched against vulnerability databases, and reachability analysis shows which vulnerable code paths your application actually calls, so the internet-facing services get fixed first.
• Stop vulnerable versions shipping. Policies and gates are evaluated in the platform and in CI with safeguard exec, so a rebuilt portal cannot go back online with a known exploited vulnerability in it.
• Fix with approval. Autonomous remediation opens fix pull requests and ships switched off by default. The Safeguard CLI's assistant can edit code and run commands with your approval, using /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. Desktop and phone apps can send work to a computer running the CLI and approve each command.

None of this replaces segmentation, offline backups, MFA, logging or an incident response plan. It covers the software you build, host and ship.

Zero-Day Discovery and Gold

Two Safeguard capabilities are aimed at the period before and just after a vulnerability becomes public. They support the general habit this post argues for, which is rebuilding quickly from known good components. Nothing below is about this incident, whose cause is undisclosed.

• 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. It covers seven package ecosystems. It does not cover Windows servers, network appliances, VPN concentrators or commercial municipal software, which is where many local government incidents begin.
• Gold Open Source at gold.safeguard.sh is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid. It provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages. An artifact loses its badge if it regresses.

The point is the habit: when you rebuild a public app after an incident, pull patched, signed components from a curated source rather than whatever was cached on the old build server.

Common mistakes after a municipal ransomware incident

Rebooting or wiping before evidence is captured. The guide warns that powering down destroys memory evidence. Disconnect first, image second, rebuild third.

Restoring the newest backup without checking it. Attackers often sit in a network for days before encrypting. The newest backup may contain their tools. Work with investigators to choose a restore point.

Bringing a portal back online on the same credentials. Reset passwords and keys after the environment is clean, not before, and not only for the accounts you know were used.

Assuming "no data mentioned" means "no data taken." Many ransomware groups copy data before encrypting. The legal trigger in South Carolina is acquisition, and establishing it takes time. Do not reassure residents prematurely in either direction.

Open questions

• Which ransomware variant was used, and has any group claimed the attack?
• How did the attacker get in, and when?
• Was any personal information acquired, and if so, whose?
• Have Business Licensing and Planning and Development Services been restored, given they were not listed on 23 October?
• When will MyColaSC, GIS, parks reservations and Animal Services online services return?
• Will the FBI become formally involved, as the city says is possible?
• Is the staff time and attendance system affected, as one anonymous employee told WIS?

We will update this post when the city or investigators answer any of these.

Related reading

• October 2026 security incidents: what would have helped
• IDCF Cloud ransomware: third-party risk lessons
• SBOM incident response: finding affected products fast
• Incident response playbook for a compromised dependency

FAQ

What happened to the City of Columbia, South Carolina?

City IT staff spotted suspicious activity on the network on 20 October 2026 and contacted SLED. On 23 October the city confirmed it was a ransomware attack. Several resident-facing online services were taken offline as a precaution, and SLED is leading the criminal investigation.

Which city services are down?

In its 23 October update the city lists MyColaSC, online Animal Services, Parks and Recreation reservations and GIS. Its first statement also listed online Business Licensing and Planning and Development Services. The animal shelter closed to the public for parts of 21 and 22 October.

Are 911, police, fire and water affected?

No, according to the city. It says the Columbia Police Department, Columbia-Richland Fire Department, 911 communications, Columbia Water systems and the Payment Center, including online payments, remain operational.

Was my personal information stolen?

The city has not said. It says the incident "involved sensitive data within the City's network" and that investigators are assessing whether any information was accessed or compromised. If personal identifying information was acquired, South Carolina law requires the city to notify affected residents, subject to delay if law enforcement asks for it.

Who is behind the attack?

The city has not named anyone. The coverage we read does not report any group claiming responsibility. Be careful with leak site listings that mention "Columbia": other organisations share the name.

Is the FBI investigating?

SLED leads the investigation. The city says SLED may work with the FBI and other state and federal partners. On 23 October the FBI told WIS it was aware of the breach but was not involved.

When will services be back?

The city has not given a timeline. It says it will restore impacted applications "as safely and efficiently as possible" and will provide further updates.

Could Safeguard have prevented this?

We do not know how the attacker got in, so we cannot say, and we do not claim it. Safeguard helps teams know which open source components and container images their applications contain, fix known vulnerabilities with approval, and stop vulnerable versions shipping. It does not detect intrusions or stop ransomware, and it is not a substitute for segmentation, backups and incident response.

Fix it without waiting for upstream

When a city rebuilds a resident-facing app after an incident, the components that go into the rebuild matter. This applies to the software you build and host, not to the attack in Columbia, whose cause is undisclosed.

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

These are real product sessions on other examples. None of them shows this incident, City of Columbia systems or a ransomware response.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a city, you would run the same scan against the repository behind a permit portal or a service request app before it goes back online, and ask the assistant to move any vulnerable dependency to its fixed version. It asks before each command.

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

The local runner demo shows setting up the runner on your own machine, approving it with its device code, then scanning from the terminal. After an incident, many teams rebuild on a clean, isolated machine before anything reconnects to the city network. The same flow lets you scan rebuilt images and repositories on that machine, under your control.

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

The mobile demo is a real Android session: it sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. Columbia confirmed this attack on a Friday night, which is when incidents tend to land. The same flow lets an on-call engineer approve a dependency upgrade or a rebuild from a phone without being at a desk.

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

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

Quick check

Sources

• City of Columbia: City of Columbia Provides Update on Cybersecurity Incident (23 Oct 2026) (primary; full text read from the city's news feed)
• City of Columbia: news feed, including "City of Columbia Advises of a Security Incident Affecting Select Services" (21 Oct 2026) and the Animal Services closure notice (21 Oct 2026) (primary)
• South Carolina Code of Laws, Title 1 Chapter 11, Section 1-11-490: breach of security of agency data (primary)
• South Carolina Code of Laws, Title 16 Chapter 13, Section 16-13-510: definition of personal identifying information (primary)
• South Carolina Code of Laws, Title 39 Chapter 1, Section 39-1-90: business data breach notification (primary)
• CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide (primary)
• CISA: Cyber Hygiene Services (primary)
• CISA: report an incident (primary)
• FBI Internet Crime Complaint Center: annual reports (primary)
• WIS: Columbia officials address security incident to online citizen services (20 Oct 2026)
• WIS: Columbia city manager confirms ransomware attack behind service outages (23 Oct 2026)
• WACH: City of Columbia confirms ransomware attack disrupting online services (24 Oct 2026)
• HERE Columbia: City of Columbia confirms ransomware attack, services offline (24 Oct 2026)
• ABC News 4: SLED investigating suspicious activity in City of Columbia network (20 Oct 2026)
• WLTX via Yahoo News: City of Columbia confirms ransomware attack (23 Oct 2026)
• WLTX via Yahoo News: City of Columbia reports "network security incident" (20 Oct 2026)

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