PGM Ransomware: One Vendor Outage Takes Argentine Towns Offline

On 23 October 2026, ransomware hit the servers of Program Consultores S.A., the Córdoba company behind the PGM municipal management platform, taking tax, payment and website services offline in towns across at least five Argentine provinces. Councils that rely on a hosted vendor should confirm their own backups, export paths and contracts now.

This post is about one vendor and many governments. Program Consultores says its software serves more than 250 municipalities and comunas in 11 provinces, according to Diario Crónica. When its shared hosting went down, every town that ran tax lookups, debt payments and cashier collections through it lost those services at once. Nobody inside those town halls had to make a mistake for that to happen.

We work from two official municipal statements (Roldán in Santa Fe and Tanti in Córdoba), the company's statement as reported by the regional press, comments from a Río Gallegos official reported by local media, and guidance from CISA, NIST and Argentina's data protection agency. Spanish quotes are our translations. Program Consultores has not published anything on its own website that we could reach, and it has not said how the attackers got in. We do not guess.

What happened

Early on Friday 23 October, ransomware encrypted files on the server infrastructure that Program Consultores uses to host PGM for its municipal customers. Diego Robles, chief of cabinet of the Río Gallegos municipality in Santa Cruz, told the local outlet TiempoSur that the malware got in at 04:30, according to El Monterizo, which carried his comments on 24 October. Robles described it as "a virus that encrypts all the data and won't let you access it."

By morning, town halls were posting notices. The Municipality of Roldán, in Santa Fe province, published a note on its official website on 23 October titled, in translation, "National PGM outage: the program used by several municipalities across the country, including Roldán." It said Roldán and every municipality using the same support were "without a system" because of an attack on the provider's server, and that the problem was national, not local.

The Municipality of Tanti, in the Punilla valley of Córdoba, posted its own notice the same afternoon. It said that because of a computer attack the PROGRAM system was out of service, which temporarily limited service to the public. It added that the civil registry and the driving licence office were not affected, and that there was "no estimated date of restoration" yet.

Diario Crónica's Friday report counted at least 17 municipalities in five provinces with interruptions: Córdoba, Santa Fe, Santa Cruz, San Luis and Corrientes. It noted that some towns confirmed the failure officially while others were identified only because their web platforms stopped responding, and that a dead portal does not necessarily mean every internal system was down. By Friday evening, the paper said, the company had not issued a public statement on scope or restoration.

The company's statement arrived through the press. La Estafeta Online and Hoy Día Córdoba both reported on 23 October that Program Consultores sent a communication to its municipal customers, which the outlets then quoted. In it the company said a virus had encrypted files and left servers for some municipalities inoperative. It said there had been "no extraction of confidential information or databases," that the incident hit the infrastructure where its systems are hosted rather than the security of the systems themselves, and that it was "not related to the vulnerabilities reported by the official PHP team." We report each of those points as the company's statement. None of them has been independently verified in anything we could find.

La Estafeta also reported that some municipalities received ransom demands of up to three bitcoins to restore their systems. El Monterizo, citing Robles's comments to TiempoSur, reported a demand of three bitcoins in Río Gallegos that doubled every 12 hours if unpaid, and said the company did not agree to it. We have not seen a ransom note, and no official source has named a ransomware group.

On Saturday 24 October, Diario Nuevo Día in Río Gallegos reported that the company was reinstalling operating systems on the affected servers together with each administration's IT staff, would keep working through the weekend, and had not set a date for full restoration or said how many customers were hit. El Monterizo described the recovery as replacing or reformatting server disks, reinstalling everything on the company's central servers, reinstalling and configuring the platform, and then having each municipality restore data from its last backup.

Timeline

Times for the Roldán and Tanti posts come from the publication timestamps their WordPress sites return. We treat them as approximate local times.

Who is affected

The table below lists every municipality named in the reporting we read. "Confirmed by" says who put the town on the list. A town named only by a press roundup may have had a partial outage or only a dead web portal.

That is 24 names. Diario Crónica's own count was at least 17. The company has not confirmed a number. The tracking site's entry for Idiazábal says the municipal administration reported no confidential data stolen or disclosed, which repeats the company's line rather than adding evidence.

The services named across the reports are the same everywhere: municipal websites, tax and rate systems, debt lookups, online payments through the platform, cashier collections, online procedures and the Hacienda (finance) office. Tanti said its civil registry and driving licence office kept working. Roldán said its offices stayed open, with slower service.

Residents are affected too, in a quieter way. If you pay rates or fees in one of these towns, the online payment link may fail or show stale balances until restoration finishes. Keep receipts of anything you paid in person during the outage.

How a shared host turns one incident into many

PGM is a hosted platform. Each town gets its own section, but the servers, the hosting stack and the operations team are shared. You can see that from the outside. On the municipal websites we checked, the "check your debt" or "claims" buttons point to paths on one shared domain, one short code per town:

This is a normal and sensible design for a small vendor serving hundreds of small governments. It is also why one encryption event reached five provinces in a morning. When the host goes, every tenant goes with it.

The company's statement draws a line between its applications, which it says are secure and working, and the hosting infrastructure, which was hit. That may be accurate. For a town hall it makes no practical difference. A tax system that is correct but has no server to run on still cannot take a payment. When you assess a hosted vendor, the infrastructure it runs on is part of the product you are buying.

Recovery runs on the same shared path. Per El Monterizo's account, the provider first rebuilds its central servers, then reinstalls and configures the platform, and only then can each town restore its own data from its last backup and check that things work. Every town waits for the first two steps, and each town's restore depends on how recent and complete its backup is. Río Gallegos expected to restore from its last backup. If a town's most recent copy is a week old, a week of payments and procedures has to be re-entered or reconciled by hand.

Is this connected to PHP2Shell?

The company says no. Its statement, as quoted by La Estafeta Online and Hoy Día Córdoba, says the incident is not related to the vulnerabilities reported by the PHP team. That is the company's statement, and nothing public confirms or contradicts it.

What we can say is the timing. PHP published fixes for CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell, on 21 October, two days before the attack. Both are rated critical and both allow remote code execution on unpatched PHP web servers. The overlap in dates is timing only. No source we read says how the attackers got into the provider's systems, and no source says which language or runtime PGM uses. We cover PHP2Shell itself in our PHP2Shell explainer and the wave of public sector outages around it in governments taking websites offline over PHP2Shell.

The reason it still matters: any public body running PHP web applications, hosted or not, should have patched PHP by now regardless of what caused this incident. The versions are in the Technical details below.

Technical details

This section lists what primary and named sources have published. A lot is still missing, and we say where.

What has been published

What has not been published

• No indicators of compromise. No hashes, file extensions, ransom note names, IP addresses, domains or wallet addresses have been published by the company, a municipality or a national CERT that we could find.
• No ransomware family or group. No official source names one. Treat any name you see on social media as unconfirmed.
• No initial access vector. The company has not said how the attackers got in. That includes whether it was a remote access service, stolen credentials, a web application flaw or something else.
• No software versions. No PGM version, operating system version or web stack version has been published, so there is no affected and fixed versions table for PGM itself.
• No national CERT note. We searched for a notice from Argentina's national CERT and found none as of 25 October.

What we observed from outside, 25 October

These are our own checks from a single location, not statements by the company. They describe reachability, not cause.

Municipal websites themselves (Roldán, Tanti, Cosquín, Goya, El Chaltén, Villa Carlos Paz, Río Gallegos) all answered normally. They are hosted separately from the platform, which fits the statements: the town's website shell stays up, and the parts that call into the shared platform fail.

PHP2Shell versions, for context only

The company says the attack is unrelated to PHP2Shell. We include the versions because many public bodies run PHP and should confirm they are patched regardless. Both advisories were published on 21 October 2026 and both carry a CVSS v4 base score of 9.2. Neither advisory reports exploitation in the wild; both describe remote code execution validated by the reporters.

What to do now

The steps below split by who you are. None of them needs the vendor's help, and most can start today.

If your municipality uses PGM or any hosted platform like it

1. Write down what stopped working. List every service that depends on the platform: online payments, debt lookup, cashier collection, procedures, the claims form, any data feeds to the province. This becomes your recovery checklist and your contract evidence.
2. Switch to manual intake with a log. Take payments and requests in person with a numbered paper or spreadsheet log, so you can reconcile once the platform returns. Tanti and Roldán kept offices open; that only works if each transaction is recorded somewhere the platform cannot lose.
3. Find your last backup and check it. Ask your IT staff, today, where the town's most recent copy of its PGM data is, how old it is and whether it has ever been restored. If the provider holds the only copy, write that down too.
4. Ask the vendor for specific answers in writing. What data of ours was on the encrypted servers? Is our backup stored separately from the encrypted infrastructure? Which logs show whether our data was accessed or copied? Who is the named contact for our town? When will you share technical findings?
5. Watch for fraud aimed at residents. Outages invite fake payment links and calls pretending to be the municipality. Publish one official channel for updates and say plainly that the town will not ask for payment through new links or messages.
6. Keep a record for your data protection obligations. Argentina's data protection agency (AAIP) publishes recommended security measures for personal data in Resolución 47/2018. Even where a notification is not mandatory, keep a written record of the incident, what data was involved, what the vendor said and when.
7. Plan for re-entry. When the platform comes back, reconcile your manual log against it before reopening online payments, so residents are not charged twice or shown false arrears.

If you are a hosted software provider for government

1. Separate tenant backups from production. Copies that can be reached from the production network with the same credentials can be encrypted with it. CISA's #StopRansomware Guide recommends offline, encrypted backups that are tested regularly.
2. Keep golden images and build from code. The same guide recommends prepared images and infrastructure as code so systems can be rebuilt quickly, with templates backed up offline. A rebuild measured in hours rather than days changes the outcome for every tenant.
3. Practise per-tenant restore. Restoring one town's data into a clean environment should be a routine task with a measured time, not a first attempt during an incident.
4. Publish an incident page you control. If your own website is unreachable, customers learn about your incident from newspapers. Keep a status page on separate hosting.
5. Give customers a way to export their own data. A regular, automatic export of each tenant's data to the tenant is the simplest protection against a single point of failure.
6. Patch what faces the internet first. If you run PHP anywhere, confirm you are on the fixed versions above.

Commands for checking backups and versions

These checks are generic. Use the ones that match your systems.

Check that a backup repository is intact and that a recent snapshot exists:

# restic
restic -r /path/to/repo snapshots --latest 3
restic -r /path/to/repo check --read-data-subset=5%

# BorgBackup
borg list /path/to/repo | tail -n 3
borg check --verify-data /path/to/repo

Prove a database dump can actually be read, not just that the file exists:

# PostgreSQL custom-format dump
pg_restore --list municipal_backup.dump | head -n 20

# MySQL or MariaDB plain dump: check it ends cleanly
tail -n 1 municipal_backup.sql   # expect "-- Dump completed"

# Record a hash so you can show later the copy did not change
sha256sum municipal_backup.dump | tee municipal_backup.dump.sha256

Look for mass file changes in a short window on a Linux file server, a common sign of encryption in progress:

find /srv/data -type f -newermt "2026-10-23 04:00" ! -newermt "2026-10-23 08:00" | wc -l
find /srv/data -type f -newermt "2026-10-23 04:00" -printf '%f\n' | sed 's/.*\.//' | sort | uniq -c | sort -rn | head

On Windows, check whether shadow copies still exist. Ransomware often deletes them, and CISA's guide lists backup-impairing tools among the signs to hunt for:

vssadmin list shadows
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'; StartTime=(Get-Date).AddDays(-3)} | Select-Object -First 20

Check the PHP version on any PHP host you run:

php -v
php -r 'echo PHP_VERSION, PHP_EOL;'
# Debian or Ubuntu packages: look for the CVE in the changelog
apt changelog php8.3-fpm | grep -m1 CVE-2026-109618
# RHEL family
rpm -q --changelog php-fpm | grep -m1 CVE-2026-109618

List the vendor-hosted endpoints your public website depends on, so you know what breaks when a provider goes down:

curl -s https://www.example-municipio.gob.ar/ \
  | grep -oE 'https?://[a-zA-Z0-9.-]+' | sort -u

Run that last one against your own municipal site. Every domain it prints that you do not operate is a dependency you should have in your vendor register.

What changed since first reports

The first reports on Friday morning described a few Punilla towns with dead portals. By Friday evening, Diario Crónica had at least 17 municipalities in five provinces, and a public tracking site lists 24 names. The company's statement moved from absent on Friday afternoon, per Diario Crónica, to a communication quoted by several outlets later that day. On Saturday the account added specifics from Río Gallegos: the 04:30 entry time, the doubling ransom and the plan to restore from the last backup. What has not changed: no group, no vector, no indicators and no restoration date.

Open questions

• How did the attackers get in? Nothing published answers this.
• Was data copied before encryption? The company says no. Many ransomware operations copy data first and threaten to publish it, so independent confirmation would help every affected town.
• How many municipalities were affected in total? The company has not said.
• Were tenant backups held by the provider on the same infrastructure that was encrypted?
• Will Argentina's national CERT or a provincial authority publish technical details or indicators?

What would have helped

Nothing here would have stopped an attacker from reaching a vendor's servers. These are the things that shorten the outage and shrink the damage when a shared provider goes down. NIST's Cybersecurity Framework 2.0 groups much of this under supply chain risk management, and the language is useful when you write it into a contract.

For municipalities and other buyers

• Know your critical suppliers and rank them. NIST CSF 2.0 GV.SC-04 says "suppliers are known and prioritized by criticality." A platform that takes every payment the town receives is at the top of that list.
• Write recovery into the contract. GV.SC-05 calls for supply chain security requirements in contracts. In practice that means a recovery time objective, a recovery point objective, how fast the vendor will notify you, what logs you can see, and where your backups live.
• Include the vendor in your incident plan. GV.SC-08 says relevant suppliers should be included in incident planning, response and recovery. Know who you call at 05:00 on a Friday and what you will do while you wait.
• Hold your own copy of your data. PR.DS-11 says backups are created, protected, maintained and tested. If the only copy of your tax roll is on the vendor's servers, your recovery point is whatever the vendor managed to keep.
• Verify a backup before restoring from it. RC.RP-03 says the integrity of backups and restoration assets is verified before use. Restoring from a copy that was already tampered with restarts the incident.
• Ask software questions before you buy. CISA's Software Acquisition Guide for Government Enterprise Consumers, released 1 August 2024, gives procurement teams a list of questions to put to suppliers about how their software is built, deployed and maintained. It is written for US agencies, but the questions travel.
• Ask for an SBOM that covers the hosted service. CISA's 2026 Minimum Elements for a Software Bill of Materials, published with the NSA, the FBI and international partners on 29 July 2026, covers software as a service as well as installed software. An SBOM from a hosted vendor tells you which runtimes and libraries your data runs on, so you can ask the right question the day a new critical flaw is announced.

For hosted providers

• Offline, encrypted, tested backups per tenant, per CISA's guide.
• Golden images and infrastructure as code so a rebuild is fast and repeatable.
• Segmentation between tenant environments where practical, so one compromised component does not reach every customer.
• Phishing-resistant multifactor authentication on every administrative path, and least privilege for operations accounts, both on CISA's list.
• Patch internet-facing systems first, and keep an inventory of the runtimes and libraries in every image you deploy.
• An incident communication plan with a status page on separate hosting and a prepared first notice for customers.

Where Safeguard fits

Safeguard would not have prevented this attack, and we do not claim it would have. It does not run a provider's backups, restore a vendor's servers or decrypt files. Here is where it does help.

• Knowing what your vendor runs. If a hosted provider gives you an SBOM, safeguard scan --sbom vendor-sbom.json analyses it and matches its components against vulnerability databases. The day a new critical flaw lands in a common runtime, you can see whether your vendor's declared components are in scope and ask a precise question, instead of a general one.
• Knowing what you run. For the systems a municipality or provider builds itself, safeguard scan --dir . covers a repository and safeguard scan --image <name> builds an SBOM of a container image. Results land as JSON under ./output. The platform shows which projects contain a given component and version, so "are we running the vulnerable PHP build anywhere?" becomes a query, not a hunt.
• Prioritising. Reachability analysis ranks the vulnerable code paths your application actually calls, and policies and gates in the platform can stop a known vulnerable version from shipping again.
• A vendor register with evidence. Safeguard's compliance suite (GA) includes Vendors, Questionnaires and Risks views, so the supplier criticality list, the contract questions above and each vendor's answers live in one place you can show an auditor.
• For providers fixing their own stack. Autonomous remediation can open tested fix pull requests when a fixed version exists. It ships switched off, with every category set to Manual. The Safeguard CLI's assistant can edit code and run commands with your approval, and since CLI v11.10.0 it asks before any command that changes something.

Where Safeguard does not help: a provider's ransomware, the provider's backup design, its network segmentation, or the speed of its rebuild. Those sit with the vendor and its operations team.

Zero-Day Discovery and Gold

Two GA capabilities are about reducing the window between a flaw existing and a fix running in production. Neither has anything to do with this incident's cause, which is unknown, and we make no claim that either would have changed it.

• Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Language runtimes such as PHP core and operating systems are outside what it covers.
• Gold Open Source at gold.safeguard.sh is free with no login: CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API.

The habit that matters for a software provider is simple: pull patched, signed components from a curated source and rebuild quickly, so that a rebuild after an incident starts from a known clean base.

Common mistakes

• Treating "applications were not affected" as reassurance. If the infrastructure hosting the application is down, the service is down. Ask about recovery time, not application security.
• Assuming the vendor's backup is your backup. It may be on the same infrastructure that was encrypted. Hold a copy you control.
• Treating "no data was stolen" as settled. It is the vendor's statement. Ask what evidence supports it, such as network logs covering the hours before encryption.
• Restoring without checking. A backup taken after the attackers got in can carry their access back with it. Verify integrity and check for persistence before reconnecting.
• Posting updates only on social media. Residents need one stable official channel. Tanti said it would post updates through its official channels; that is the right instinct.
• Waiting for the vendor before acting. Manual intake, resident fraud warnings and backup checks are all in the town's own hands from the first hour.
• Naming a ransomware group before anyone official has. Guesses spread and are hard to correct.

FAQ

What is PGM and who makes it?

PGM is a municipal management platform made by Program Consultores S.A. of Córdoba. Towns use it for tax and rates, debt lookup and payment, procedures, cashier collections and parts of their websites. Diario Crónica reports the company serves more than 250 municipalities and comunas in 11 provinces.

Which municipalities were affected?

Reports name 24 towns in Córdoba, Santa Fe, Santa Cruz, San Luis and Corrientes. Roldán and Tanti confirmed it on their official websites. Río Gallegos issued a notice reported by local press. Diario Crónica counted at least 17. The company has not given a number.

Was personal data stolen?

The company says there was no extraction of confidential information or databases, according to its statement as quoted by La Estafeta Online and Diario Nuevo Día. That has not been independently verified. Residents should watch for phishing that uses municipal branding regardless.

How much was the ransom?

Some municipalities reported demands of up to three bitcoins, according to La Estafeta Online. Río Gallegos's chief of cabinet said its demand doubled every 12 hours, as reported by El Monterizo citing TiempoSur. El Monterizo reports the company did not agree to pay.

Was this caused by PHP2Shell?

The company says it was not related to the vulnerabilities reported by the PHP team. That is the company's statement. PHP published the PHP2Shell fixes two days earlier, on 21 October, but the link is timing only and no source has said how the attackers got in.

Which ransomware group did it?

No official source has named one. We do not name a group.

When will services come back?

No date had been given as of 24 October. The recovery involves rebuilding the provider's servers, reinstalling the platform and then restoring each town's data from its last backup.

I live in one of these towns. What should I do?

Use the municipality's official website or office for any payment. Do not pay through links received by message or email during the outage. Keep receipts for anything you pay in person so you can check your balance once the system returns.

What should other councils learn from this?

Rank suppliers by how much of your service depends on them, write recovery times and backup location into contracts, keep your own copy of your data, and include the vendor in your incident plan. NIST CSF 2.0 GV.SC-04, GV.SC-05 and GV.SC-08 describe exactly these steps.

Does an SBOM help with a hosted service?

Yes, partly. CISA's 2026 SBOM minimum elements cover software as a service. An SBOM tells you what a vendor's platform is built from, which helps you ask precise questions when a new critical flaw is announced. It does not tell you how the vendor runs backups or segments its network.

This incident started at a hosted provider, so most of what follows applies to the software a provider builds and ships, and to any municipal team that builds its own applications. The habit is the same either way: do not let a known vulnerable component sit in production waiting for someone else's schedule.

Fix it without waiting for upstream

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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

None of these demos shows this incident. Each shows a real product flow, and we say how the same flow applies to a hosted government platform or the team that runs one.

This real CLI session installs Safeguard, opens the interactive terminal and asks it to fix a lodash CVE in a repository. The assistant reads the finding and advisory, asks before any command that changes something, moves lodash to 4.17.21, runs the install and tests with approval, and pushes nothing. A provider rebuilding its platform image after an incident could run the same scan against the new image and ask the assistant to move the base image or PHP runtime to a fixed version before redeploying.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A municipal IT team that maintains its own tools alongside a hosted platform, such as a reconciliation script for the manual payment log, could pick that folder, ask for a vulnerable library to move to its fixed version, and decide on every change before it lands.

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

This session connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A provincial or municipal risk team could connect Claude the same way and ask which of its own projects contain a component named in a new advisory, keeping write tools switched off, which is the question every council wanted answered the week PHP2Shell landed.

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

To try it on your own projects, download Safeguard and follow the CLI docs. For related reading, see ransomware at a cloud provider and third party risk, finding affected products fast with SBOMs and October 2026 security incidents and what would have helped.

Quick check

Sources

• Municipalidad de Roldán: National PGM outage, the program used by several municipalities, including Roldán (23 Oct 2026, Spanish)
• Municipalidad de Tanti: Interruption of the municipal computer system (23 Oct 2026, Spanish)
• Diario Crónica: A massive computer attack took dozens of municipal websites offline (23 Oct 2026, Spanish)
• La Estafeta Online: Company ruled out data theft; ransom demands in bitcoin (23 Oct 2026, Spanish)
• Hoy Día Córdoba: Cyber attack leaves several Punilla municipalities without systems (23 Oct 2026, Spanish)
• Diario Nuevo Día: Río Gallegos municipality reports a cyber attack (23 Oct 2026, Spanish)
• Diario Nuevo Día: The company denied data theft and explained what happened (24 Oct 2026, Spanish)
• El Monterizo: The ransomware that paralysed municipal procedures, three bitcoins demanded (24 Oct 2026, Spanish)
• KonBriefing: Cyber attacks tracker, Argentina entries for 23 Oct 2026
• PHP (php-src on GitHub): GHSA-w8hw-w9fx-j79w, RCE via OOM corruption, CVE-2026-109618
• PHP (php-src on GitHub): GHSA-6wmf-4rv5-p3rp, RCE via stale global state, CVE-2026-109619
• CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide
• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29 (26 Feb 2024, PDF)
• CISA: Software Acquisition Guide for Government Enterprise Consumers released (1 Aug 2024)
• CISA: Updated Minimum Elements for a Software Bill of Materials released (29 Jul 2026)
• Argentina, AAIP: Resolución 47/2018, recommended security measures for personal data (Spanish)

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