#criticalinfrastructure

GAO published its third report on cybersecurity regulatory harmonization on September 28, 2026, and if you have read the first two, you already know most of what is in it. Six industry panelists from energy, financial services, and healthcare told GAO, again, that federal cybersecurity rules overlap, conflict, and cost real money to comply with. This is the fourth time since 2020 that GAO has said some version of this sentence, and the twelfth year running that information security has sat on GAO’s High Risk list. Nobody in this story is surprised by any of it, which is itself the story.

But buried in footnote 14, on page 4, is the detail that actually matters. National Security Memorandum 22, the White House directive that was supposed to be the coordinating spine of federal critical infrastructure policy, is gone. Not repealed, not superseded by a new memorandum with a different number. Just gone from the public website, “under review” since sometime before August 2026, with no explanation and no return date. GAO’s footnote is the driest possible way to report that a governing national security document disappeared from public view while the very agencies it was supposed to coordinate kept generating the conflicting paperwork it was meant to fix.

A Memorandum With No Forwarding AddressNSM-22 was signed in April 2024 to replace a decade old Obama era directive, and it did what these documents do; it named the Department of Homeland Security as the lead coordinator, designated CISA as the “National Coordinator for Security and Resilience,” reaffirmed the 16 critical infrastructure sectors, and ordered a biennial National Risk Management Plan. It was, in the language of the trade press at the time, a “good first step.” It was also, per GAO’s own report, the connective tissue between an alphabet soup of sector regulators who were each writing their own cyber incident reporting rules without much reference to each other.

That memorandum is now archived on a “frozen in time” Biden administration website, unavailable through the current White House’s own channels. GAO’s report says only that it “was under review and was no longer available on the White House’s public website” as of August 2026. There is no public indication of what replaces it, when a replacement might arrive, or whether the current administration considers the underlying coordination problem worth solving through the same mechanism. In March 2026, the White House did issue a new national cyber strategy that promised to remove burdensome or ineffective regulations and increase coordination; whatever that strategy is, it apparently did not require keeping the last coordination directive online while the new one gets sorted out.

This is the part GAO cannot say directly, because GAO audits process, not politics, but the panelists said it for them. Participants told GAO there is tension between reliability and modernization, that companies are pushed toward new technology while stuck inside compliance frameworks that do not move at the same speed. Take away the coordinating memorandum in the middle of that tension, and you have not solved the duplication problem. You have removed the one document whose entire job was to say who is supposed to solve it.

The Rule That Keeps Almost ArrivingIf NSM-22 is the memo nobody can find, CIRCIA is the rule nobody can finish. Congress passed the Cyber Incident Reporting for Critical Infrastructure Act in March 2022, giving CISA 24 months to propose a rule and 18 more to finalize it. CISA hit the first deadline, publishing its proposed rule in April 2024. It has missed every deadline since. The statutory finalization date was October 2025. CISA missed that, moved the target to May 2026, missed that too after a DHS appropriations lapse postponed a round of stakeholder town halls, held those town halls in June, and now says the rule is finally coming this month, September 2026, three and a half years after the statute that ordered it and eleven months past the deadline that statute set.

The industry panelists, naturally, have feelings about this. Most participants named the proposed CIRCIA rule or the SEC’s cybersecurity disclosure requirements as the regulations most likely to conflict with their own sector’s rules, the only two cited across all three sectors on the panel. A few in financial services walked GAO through what compliance actually looks like in practice; a single cyber incident can trigger a 72 hour reporting clock under the National Credit Union Administration, a four business day clock under the SEC, and a 24 to 72 hour clock under the still unfinished CIRCIA rule, each with its own definition of what counts as reportable. One participant put it about as plainly as a GAO transcript allows, describing what should exist instead as one report that satisfies multiple requirements where the underlying information is the same.

CIRCIA itself contains a provision meant to do exactly that, letting a covered entity skip reporting to CISA if it already reported “substantially similar” information to another agency on a similar timeline. It is a good idea sitting in a rule that has been not yet final for three and a half years, which means the harmonizing mechanism industry keeps asking for has existed on paper since 2022 and has never once taken effect.

Same Six Chairs, Same ComplaintsGAO’s methodology section is almost touching in its consistency. This is the third panel in a series that started in 2025, and GAO notes plainly that the views expressed in July 2026 “were generally similar” to the two prior sessions. Six panelists, three sectors, one afternoon of Zoom, and a report structure that has by now calcified into ritual; identify the duplicative regulations, quantify how many, note limited progress, list the same three suggestions that never quite get adopted (harmonize incident reporting, consolidate agency authority, increase collaboration).

What has changed between reports is not the complaints. It is the backdrop against which the complaints are being repeated. In 2025, industry was asking for harmonization while CIRCIA’s rule was merely late. By the second report in March 2026, it was later. By this third report, the rule is theoretically imminent, but the document that was supposed to make sure it plays well with SEC, HIPAA, NCUA, and everything else has quietly disappeared from public view. GAO can keep convening panels and counting regulations for as long as Congress asks it to. What it cannot do, and does not pretend to do, is explain why the coordinating apparatus keeps getting thinner every time the underlying problem gets documented again.

Six industry executives spent three hours in July telling GAO, on the record for the third time, that the federal government’s cybersecurity rules do not talk to each other. The federal government’s response, so far, has been to remove the memo that was supposed to make them.

Read Time:3 Minute, 42 Second

A Fresh Look at the ExposureResearchers have identified 4,980 internet-facing hosts referencing Danfoss in their web content, according to an October 13 update from the open-source intelligence account International Cyber Digest, based on a Shodan search. The finding comes just days after attackers remotely triggered defrost functions on refrigeration systems at French supermarkets overnight between October 11 and 12, spoiling chilled and frozen stock in the process. Earlier reporting indicated affected stores saw internal temperatures climb as high as 50°C during the incident.

France accounts for the largest share of exposed hosts by a wide margin, with 2,911 results, or roughly 58% of the global total. South Africa follows with 517, then Germany with 171, Portugal with 158, and the United States with 141. Smaller numbers appear in Poland, Belgium, Sweden, Spain, and the Netherlands. International Cyber Digest estimates that around eight in ten of the identified hosts are located in Europe.

What the Numbers Don’t ProveIt is worth being precise about what a Shodan search like this actually shows. The scan looks for pages that reference Danfoss in their web content, not confirmation that every listed host is a vulnerable refrigeration controller, or that any individual system has already been compromised. A separate, more filtered search returned a slightly lower figure of 4,551 results. Neither search reveals firmware versions, confirms successful attacks against specific hosts, or indicates how many individual stores each exposed controller manages.

France Confirms Widespread CompromiseFrance’s national cybersecurity agency, CERT-FR, issued an alert on October 12 confirming numerous compromises involving Danfoss AK-SM and AK-SC refrigeration management devices, and instructed operators to immediately disconnect affected systems from the internet or restrict access through other means.

Danfoss has acknowledged that the affected refrigeration management systems were running outdated firmware, and has repeated its standing advice for customers to update supported equipment and retire legacy systems that no longer receive security patches.

A Date-Based Authentication BypassIndependent research from industrial security firm Claroty’s Team82 points to a specific weakness that may help explain how attackers gained access. The team found that the AK-SM 800A platform generates a daily administrative authentication code based on the device’s current date, meaning anyone who can reproduce the underlying algorithm could calculate a valid code and obtain an administrative session, effectively bypassing the system’s configured password entirely.

That flaw is now tracked as CVE-2025-41450, affecting AK-SM 8xxA firmware versions earlier than R4.2, which Danfoss has since patched. The U.S. Cybersecurity and Infrastructure Security Agency’s advisory also lists two related flaws in versions prior to R4.3.1: CVE-2025-41451, a command injection vulnerability in the device’s email alert settings that Team82 says could allow code execution once an attacker is authenticated, and CVE-2025-41452, a web server configuration weakness that could let an authenticated attacker manipulate how web traffic is handled or disrupt the management interface.

Investigators have not publicly confirmed that this specific vulnerability chain was what enabled the French supermarket incidents. A separate, unverified claim circulating online suggests some affected systems used a default “admin” username paired with a password that simply changes to the current date, a detail that, if accurate, would make the authentication weakness especially easy to exploit without any technical skill.

Why Centralized Refrigeration Controls Are High-RiskThe AK-SM 800A is designed to manage multiple refrigeration units through a single web interface, giving operators centralized control over temperature limits, schedules, alarms, and user accounts. That convenience is also what makes exposed management interfaces so dangerous: unlike a typical IT breach, a compromise here can directly affect physical operations, in this case the cooling systems that keep food safe for consumption.

Recommended Next StepsCERT-FR’s guidance for operators who suspect compromise includes immediately restricting network access to trusted service providers, performing a factory reset, applying all available firmware updates, rotating passwords and other credentials, auditing user accounts, and fully reconfiguring the system before reconnecting it.

Remove direct internet exposure for refrigeration and building-management controllers.

Segment operational control networks away from general business networks.

Use properly secured, authenticated remote access methods rather than open internet-facing interfaces.

Verify firmware is updated past R4.2 (AK-SM) and R4.3.1 for the related flaws before reconnecting equipment.

For retailers running similar equipment, the message is clear: patching alone is not enough if the management interface remains reachable from the open internet.

Read Time:3 Minute, 8 Second

The FBI and U.S. Department of Justice have seized seven domains associated with two hacking platforms allegedly operated by China-based Integrity Technology Group. The court-authorized action targets Microscan and FishHub, tools that investigators say supported large-scale vulnerability discovery, spear phishing, malware delivery, data theft, and persistent access.

Court documents unsealed in the Western District of Pennsylvania connect the operation to Flax Typhoon, a threat group widely tracked by security researchers. U.S. authorities allege that Integrity Technology Group holds Chinese government contracts and supplied capabilities used to identify and compromise targets. The October 8 disruption removes important access points, but it does not automatically evict attackers from previously breached networks.

Compromised Devices Powered Large-Scale ScanningInvestigators say Integrity Tech used a Mirai variant to assemble a botnet of internet-connected equipment. That network and other infrastructure supported Microscan, a Python-based web application containing more than 1,300 penetration-testing scripts. Operators could centrally scan websites and services for weaknesses affecting products such as Oracle WebLogic, WordPress, Jenkins, Apache Struts, OpenSSL, and Juniper ScreenOS.

Authorities traced Microscan activity back to at least 2017. Named scanning targets included a South Carolina power company, airports in Japan and Poland, energy providers in Taiwan, a multinational non-governmental organization, and Taiwanese universities. A scan identifies possible entry points; it should not be confused with proof that every listed organization was successfully breached.

The seized domain c0cc[.]cc provided access to Microscan. Taking it away is intended to interrupt the operators’ workflow and deprive customers of a central interface for managing findings. The action follows a September 2024 disruption of an Integrity Tech botnet containing more than 200,000 routers, cameras, recorders, and network-attached storage devices worldwide.

FishHub Enabled Phishing and Follow-On AccessFishHub served a different phase of operations. Prosecutors allege it supported targeted phishing and the delivery of additional malware after an initial foothold. That follow-on code could grant remote access or search for particular files and transfer them to infrastructure controlled by Integrity Tech.

Approximately 20 Taiwanese universities were confirmed as FishHub victims, according to the government account. Five seized domains—98aicai[.]com, 98aicode[.]com, linkedinns[.]net, outlook3650[.]com, and youtubecard[.]com—supported malware delivery. Another domain, 98aiblog[.]com, was associated with SoftEther VPN software used to maintain unauthorized remote connections.

The broader advisory describes password spraying against Microsoft Exchange interfaces, automated email theft, and VPN-based persistence. Those observations provide context for Integrity Tech-linked activity, though defenders should not assume every technique was a feature of FishHub itself.

Domain Seizure Is a Starting Point for DefendersInfrastructure disruption can impose costs and generate valuable intelligence, but compromised organizations may still contain malware, stolen accounts, scheduled tasks, VPN tools, or alternate access paths. Security teams should use the newly published indicators to review historical DNS, proxy, firewall, identity, email, and endpoint telemetry.

Patch internet-facing applications and network devices, prioritizing known exploited weaknesses.

Disable unnecessary services and restrict administrative interfaces to trusted management networks.

Require phishing-resistant multifactor authentication where possible and investigate password-spraying patterns.

Search for unexpected SoftEther or other remote-access installations and unusual outbound transfers.

Preserve logs and isolate affected hosts before removing access if compromise is suspected.

Matches should be investigated in context because domain or IP contact alone may not establish an intrusion. Conversely, a clean check against the seized domains cannot rule out alternate infrastructure. Organizations with relevant exposure should trace activity from the earliest suspicious event, identify every affected identity and system, and rotate credentials only from trusted devices. They should also revisit older alerts that may have been closed as routine scanning. The seizures make a mature operation harder to run; defenders must complete the job inside their own environments.

Read Time:3 Minute, 38 Second

Security researchers have tracked a sharp, nine-day spike in scanning and exploitation attempts against internet-exposed Hikvision surveillance equipment in Ukraine, with almost all of the activity aimed at a four-year-old command injection flaw that still haunts unpatched devices. The surge ran from September 21 through October 1, 2026, a period that overlapped with intensified Russian missile and drone strikes — though analysts have stopped short of linking the two.

A Sudden Spike After Months of QuietAccording to a timeline published by threat-intelligence firm GreyNoise, the activity began with low-key reconnaissance from a Ukrainian IP address on September 21, probing service ports without firing off an actual exploit. Two days later, on September 23, the picture changed: exploitation attempts shot up and continued at an elevated pace for more than a week, a level of focused attention on Ukrainian targets that hadn’t been seen in months.

Just four IP addresses were responsible for nearly all of the exploitation traffic. Three traced back to PureVPN exit nodes registered to AS56630 in Lithuania, while the fourth belonged to a domestic Ukrainian network that GreyNoise did not publicly identify. The firm assessed with low confidence that the Ukrainian address might be connected to the same operator running the VPN nodes, while cautioning that commercial VPN exits are shared infrastructure and can’t be treated as solid proof of a single actor acting alone.

An Old, Well-Known FlawThe target of nearly every attempt was CVE-2021-36260, a critical command injection vulnerability in the web server component of various Hikvision cameras and network video recorders. The bug carries a maximum-severity CVSS score of 9.8 because it can be triggered remotely, without authentication or any user interaction, letting an attacker run arbitrary commands on the device’s underlying operating system.

Notably, the attackers appear to have relied on a publicly available Nuclei scanning template built specifically to probe for this flaw. Every logged request used the same basic command test with no follow-up payload, which points toward automated vulnerability sweeping rather than a hands-on-keyboard intrusion. GreyNoise was careful to frame its findings as evidence of exploitation attempts, not confirmed device takeovers — a distinction that matters a great deal when judging how serious this specific wave actually was.

Why Exposed Cameras Are a Real RiskEven if this particular campaign turns out to be routine scanning rather than a targeted operation, the stakes around vulnerable surveillance hardware in a conflict zone are not hypothetical. Cybersecurity News has previously documented more than 80,000 exposed, vulnerable Hikvision devices discovered in a 2022 sweep, underscoring just how long this exposure problem has lingered. More pointedly, Ukrainian authorities disclosed in January 2024 that they had disabled two cameras that Russian intelligence services had compromised specifically to monitor Kyiv’s air defenses and critical infrastructure.

That history illustrates what’s plausible when a camera network goes unpatched and internet-facing — unauthorized remote command execution could, in principle, let an attacker watch live feeds, pivot into connected networks, or disable equipment at a sensitive moment. It does not, however, establish who is behind the current scanning wave or what their end goal might be.

What Operators Should DoCISA and Hikvision have both published guidance for defending against CVE-2021-36260, and the fix is straightforward even though the exposure has proven durable. Organizations running Hikvision cameras or recorders — especially in Ukraine or other high-risk regions — should treat this as a prompt to check their exposure immediately. Recommended steps include:

Identify every Hikvision camera and NVR model in the environment and confirm which firmware version is installed.

Apply Hikvision’s official firmware patches for CVE-2021-36260 without delay.

Remove direct public internet access to camera management interfaces wherever possible.

Segment surveillance equipment onto its own network, isolated from core business or operational systems.

Monitor logs for repeated connection attempts to camera web services, particularly from VPN exit ranges.

It’s worth stressing that changing device passwords will do nothing here — this is an unauthenticated flaw in how the device parses incoming requests, so a firmware update is the only real remedy. Given how often this four-year-old bug keeps resurfacing in fresh campaigns, organizations that haven’t verified their patch status recently would be wise to do so now, regardless of whether they believe themselves to be a likely target.

Read Time:3 Minute, 45 Second

A now-patched vulnerability in Sungrow’s iSolarCloud management platform could have let an attacker log into any customer’s account without knowing their password, exposing remote control over solar inverters, battery systems, and entire solar plants across Europe, China, Australia, and other regions. The flaw was disclosed by security researchers at Jakkaru and fixed by Sungrow within roughly a day of being reported — but the scope of what it could have enabled makes it worth a closer look.

A Business-Logic Flaw in the Login ProcessSungrow is one of the largest solar inverter manufacturers in the world, with the company reporting more than 870 gigawatts of power electronic converters deployed globally as of June 2025; Jakkaru’s own estimate puts that figure above 1,000 GW today. Its iSolarCloud platform is the remote management layer that lets customers and administrators monitor and control solar assets from anywhere.

Despite the platform’s use of encrypted REST API calls, request signatures, and custom headers — defenses designed to make tampering difficult — Jakkaru’s researchers found a logic error sitting in the authentication flow itself. While reviewing a login parameter called login_type, they discovered that submitting one specific value caused the system to authenticate the account tied to the supplied email address while completely disregarding whatever was entered in the password field. In other words, knowing a target’s email address alone was enough to get into their account.

The flaw was especially dangerous because it left no trace: iSolarCloud did not send an email alert or any other login notification when an account was accessed this way, meaning an intruder could get in, quietly use account-recovery options to lock in longer-term access, and the legitimate owner might never know.

What an Attacker Could Have DoneJakkaru found that regular customer accounts and administrative accounts lived inside the same shared management environment, which raised the stakes considerably — compromising the right account could mean escalating straight to administrative control over an entire regional cloud deployment. According to the researchers, that level of access would have allowed an attacker to:

View and modify details of connected solar plants.

Remotely start or stop inverters and battery storage systems.

Access registered organizations and user accounts tied to the platform.

Push custom firmware to cloud-connected devices.

That last capability is the one that should concern grid operators most. A malicious firmware push could alter how a device behaves at a fundamental level, and coordinated action across many compromised systems at once could cause a sudden, simultaneous drop in solar generation — a real concern as inverters take on a bigger share of national energy infrastructure. This goes well beyond a typical data-exposure bug; it’s a pathway to operational disruption of physical energy equipment.

Part of a Recurring Pattern in Solar InfrastructureThis isn’t an isolated incident for the inverter industry. Cybersecurity News has previously reported on a separate study that uncovered 46 distinct flaws spread across major inverter vendors, including weaknesses tied to communication dongles, insecure direct object references, and hard-coded credentials — with Sungrow systems among those implicated. Other reporting has flagged tens of thousands of internet-exposed solar devices, including dashboards and data loggers left reachable directly from the public internet. Taken together, this disclosure reinforces a pattern that security researchers have been warning about for a while: the rapid buildout of distributed solar infrastructure has outpaced the security hardening of the cloud platforms managing it.

Sungrow’s Response and Recommended Next StepsJakkaru reported the issue directly to Sungrow’s Product Security Incident Response Team, and the company shipped a hotfix within a day — a response the researchers characterized positively. That said, Sungrow has not published a CVE identifier, a list of affected firmware versions, or a customer-facing patch version number for this specific issue, which makes independent verification harder for asset owners. Solar plant operators and administrators relying on iSolarCloud should take these precautions regardless:

Confirm that iSolarCloud accounts and connected devices are running current, updated software.

Change account passwords and enable multi-factor authentication wherever it’s supported.

Audit user and administrator accounts for old installers or third parties that no longer need access.

Avoid exposing inverter management interfaces, gateways, or data loggers directly to the public internet.

Separate administrative tooling from standard customer-facing portals to limit the blast radius of any single compromised account.

As solar capacity continues to scale, incidents like this one are a reminder that the cloud platforms coordinating distributed energy resources deserve the same security scrutiny traditionally reserved for the grid itself.

Read Time:3 Minute, 30 Second

An Iranian-aligned threat cluster used a convincing recruitment exercise to target a likely Iraqi software engineer connected to critical infrastructure. The campaign, tracked as Blinder Tunnel, paired a fake Dubai Airports careers portal with a weaponized Visual Studio project that could execute attacker code as soon as the victim opened the supposed coding test.

Palo Alto Networks Unit 42 tracks the activity as CL-STA-1178 and assessed with high confidence that it has an Iranian nexus. Researchers found no evidence that Dubai Airports itself was breached or vulnerable; its identity was used as social engineering cover. Preparations date to November 2025, while the observed operation became active in March 2026.

A patient recruitment lure built trust firstThe initial package was an Inno Setup application named “Dubai Airport Careers.” It opened a local imitation of a recruitment site, accepted credentials supplied by the supposed hiring team and displayed a ten-question human-resources form. Investigators found that this first stage neither stole the entered information nor installed malware.

That restraint appears deliberate. By making the portal behave like a plausible application process, the operators reduced suspicion before delivering a personalized archive named DubaiAirport_Carrers_IT_Test.zip. Its instructions addressed the target and asked the candidate to open a C# flight-management project, then correct a simple loop error.

The technique exploits an important developer trust assumption: a source project looks like material to inspect, not an executable installer. Yet modern development environments evaluate project metadata automatically. The victim did not need to compile the program for the malicious chain to begin.

Visual Studio project launches the infectionA modified FlightManager.csproj abused Visual Studio’s background evaluation behavior. It created a misleading RuntimeBrokers directory beneath local application data and launched RuntimeBroker.exe. The attackers then altered an application configuration file to hijack AppDomainManager, causing malicious code to load before the legitimate host application.

The configuration also disabled Event Tracing for Windows, weakening a telemetry source defenders use to identify suspicious .NET execution. The chain proceeded through DLL sideloading: a renamed legitimate Visual Studio hosting binary loaded an attacker-controlled RuntimeBroker.dll, identified as the ShelbyLoader V2 loader.

ShelbyLoader established persistence with a registry Run value, collected a fingerprint of the host and communicated through GitHub’s API. It could upload system details, retrieve tasks and use encrypted information in GitHub issue comments as a fallback. GitHub removed infrastructure identified during the investigation.

Backdoor and tunnels support deeper accessThe loader decrypted ShelbyC2 V2, a backdoor capable of receiving operator commands. A component named PsProxy.dll executed commands through the PowerShell engine without launching the familiar PowerShell.exe process, helping activity blend past detections based only on process names.

The attackers also staged Blackwood, an in-memory wrapper around the Chisel tunneling utility. It could create encrypted tunnels and a reverse SOCKS proxy, providing a route to systems beyond the initially compromised workstation. In a critical-infrastructure environment, that capability turns one developer endpoint into a potential pivot point for long-term access.

Researchers associated the cluster with Iran through infrastructure, victim selection and an operational mistake: metadata in an audio file referenced an Iranian music site. Related credential-harvesting infrastructure also targeted an Israeli entity during May and June 2026.

Detection and prevention prioritiesOrganizations should treat unsolicited coding exercises as executable content. Candidates can verify recruiters through independent corporate channels and open unfamiliar projects only in disposable, isolated environments. Security teams should monitor development tools as closely as office documents and browsers.

Alert on unusual msbuild.exe activity and projects that launch processes during evaluation.

Investigate signed binaries loading unknown DLLs from user-writable directories.

Monitor changes to .NET configuration files and attempts to disable ETW.

Review GitHub API traffic that does not match normal repository workflows.

Isolate suspected hosts, rotate exposed credentials and examine lateral-movement paths.

The campaign succeeds by making each step look familiar: a job application, a coding task, Visual Studio components and GitHub traffic. Defenders need to evaluate the complete sequence rather than trusting any one legitimate-looking element. For engineering teams operating around sensitive infrastructure, project files from outside the organization warrant the same caution as macros, scripts and unsigned executables.