Daily Cybersecurity News – August 11, 2026

What happened

The FBI and South Korea’s National Police Agency issued a joint advisory warning that the Gunra ransomware gang is breaching critical infrastructure by exploiting two authentication-bypass vulnerabilities in Fortinet firewalls.

Gunra, which emerged in April 2025 and is built on leaked Conti source code, uses CVE-2024-55591 and CVE-2025-24472 to gain privileged access, steal data, encrypt systems, and extort victims. The group shifted to a ransomware-as-a-service model, recruits initial access brokers under aliases such as “Golden Community,” and deploys both Windows and Linux variants. Ransom demands frequently exceed $10 million with 5–7 day deadlines.

Who is affected

Organizations running vulnerable Fortinet FortiOS (7.0.0 through 7.0.16) and FortiProxy versions, especially in healthcare, financial services, and government sectors worldwide.

Critical infrastructure and industrial organizations are primary targets; Dragos recorded multiple Gunra incidents against industrial entities in early 2026.

Why it matters

Successful exploitation grants super-admin privileges on edge firewalls, enabling full network compromise, data theft, and encryption that can disrupt essential services.

Both CVEs are confirmed in CISA KEV as actively exploited in ransomware campaigns, with high EPSS scores indicating likely ongoing abuse. Operators face multi-million-dollar extortion and operational downtime.

How it could have been prevented

Immediately apply Fortinet patches for CVE-2024-55591 and CVE-2025-24472. Restrict management interface exposure, enforce multi-factor authentication, monitor for unusual privileged access, and segment critical networks. For Gunra’s Linux variant, defenders can sometimes recover files using file timestamps without paying. Share indicators with CISA/FBI and industry ISACs.

What happened

Researchers at Nanyang Technological University used an AI agent pipeline called iFinder to discover 84 previously unreported security flaws in open-source and commercial 4G/5G core network software. Developers confirmed 83; 81 received CVE numbers.

The most serious flaw allows an attacker who can reach internal links to hijack a subscriber’s data session by injecting a higher-priority forwarding rule that reuses an existing ID, causing the network to deliver the victim’s traffic to the attacker. It was demonstrated end-to-end on OpenAirInterface and validated on two commercial cores (one fixed as CVE-2026-8233). A secondary path uses a legitimate SIM to hide control messages inside the data tunnel.

Who is affected

Operators and vendors running affected 5G/4G core implementations, including open-source projects (OpenAirInterface, eUPF, Open5GS, SD-Core, free5GC and others) and commercial cores.

Cloud-deployed cores are especially exposed if internal interfaces are misconfigured and reachable from the internet; five of seven open-source cores were vulnerable to the SIM-based path. 23 confirmed flaws remain unpatched.

Why it matters

Session hijacking can intercept or redirect subscriber traffic, enabling eavesdropping, fraud, or further network compromise. As operators move cores to the cloud, previously internal interfaces become more exposed.

Uneven patching leaves operators running unfixed code with assigned CVEs, and the AI-driven discovery method shows scalable vulnerability hunting against complex telecom stacks.

How it could have been prevented

Apply available patches from vendors and open-source maintainers immediately. Audit and restrict access to internal control-plane interfaces; do not expose them to the internet. Enforce proper authentication and uniqueness checks on forwarding rules and session IDs. Monitor for anomalous session manipulations and validate configurations against 3GPP expectations. Prioritize fixing the remaining 23 unpatched issues.

What happened

Tenet Security researchers demonstrated “Ghostjacking,” a technique that tricks an organization’s own AI coding or operations agents into rerouting email and web traffic around firewall controls, effectively enabling domain takeover and persistent access.

A single fake bug report or planted log entry (for example, a blocked request recorded by Cloudflare’s managed rules) is read by the AI agent as legitimate. The agent then rewrites DNS, points domains at attacker infrastructure, or executes attacker code using permissions it already holds. The method succeeds against common developer stacks including Cloudflare, Datadog, and Sentry, and was shown nine out of ten times against Claude Code on Cloudflare’s recommended setup. Researchers also demonstrated “self-exploit” chains where one AI builds an attack another accepts. Findings were presented at DEF CON 2026.

Who is affected

Organizations that grant AI agents broad access to code, infrastructure, logs, DNS, or security tooling—especially those using Cloudflare (reported in 42% of Fortune 500), Datadog (48%), or Sentry (millions of developers).

Half of Fortune 500 companies are estimated vulnerable based on tool prevalence. Exposed public keys (e.g., Datadog frontend keys) and default AI agent configurations increase risk.

Why it matters

The attack abuses trusted, already-granted agent privileges so traditional firewalls and perimeter controls become irrelevant; defenders see only normal agent activity. It enables silent traffic rerouting, backdoors in agent memory/tools/config, credential and data theft, and long-term persistence.

As companies rapidly adopt autonomous AI agents with production access, this class of prompt/injection-via-trusted-data attacks expands the insider-like threat surface without needing to breach the network first.

How it could have been prevented

Limit AI agent permissions to least privilege; never grant unrestricted DNS, firewall, or production code-write access. Sanitize and validate all inputs the agent consumes (logs, bug reports, alerts, tickets). Prefer human-in-the-loop approval for high-impact actions such as DNS changes. Rotate and restrict public/frontend API keys. Monitor agent actions for anomalous configuration or routing changes. Treat agent memory and tool configurations as sensitive assets requiring integrity checks.

What happened

Security researchers created a fake cryptocurrency/DeFi startup called Ballena Azul, posted developer jobs, and hired three individuals they assess as North Korean IT operatives. Every issued virtual machine was instrumented for full recording.

The hires cleared interviews and onboarding using inconsistent or forged identity documents (mismatched addresses, licenses, bank accounts; one image showed Google Gemini processing and a SynthID watermark). Once inside, the operatives performed reconnaissance (dxdiag, systeminfo, wmic), checked geolocation, installed remote-access tools, synced personal accounts, and logged into services—providing the researchers detailed tradecraft. The operation follows earlier research in which the same team posed as facilitators.

Who is affected

Any organization that hires remote IT workers, especially in tech, crypto, software development, or roles with source-code and internal-system access.

North Korean IT worker schemes have previously placed operatives at more than 100 U.S. companies using stolen identities, generating millions in revenue for the regime.

Why it matters

A successful placement gives the operative legitimate employee credentials and expected access to source code, internal systems, and potentially customer data—turning a hiring decision into an authorized insider threat that is hard to detect with traditional perimeter controls.

Salaries are remitted to North Korean entities, funding the regime; the workers also conduct reconnaissance and may install persistence. U.S. authorities have prosecuted facilitators and issued joint alerts on the tactic.

How it could have been prevented

Implement rigorous identity verification beyond documents: video interviews with liveness checks, cross-check addresses/SSNs/bank details against multiple sources, examine image metadata and AI watermarks (e.g., SynthID), and watch for inconsistencies. Use isolated, monitored VMs for new remote hires with restricted access. Monitor early-day reconnaissance commands and unexpected remote-desktop or account-sync activity. Consult the July 31 joint alert and related DOJ guidance on North Korean IT worker indicators.

What happened

OpenAI released GPT-5.6-Cyber, a specialized model based on GPT-5.6 Sol and available only through the higher-tier Daybreak Red vetted-access program for cybersecurity professionals. It is trained for zero-day discovery and exploit-chain development and refuses far fewer dual-use research requests.

On an internal benchmark of exploit-chain, authentication-bypass, and privilege-escalation tasks it completed 95% of requests versus 1.5% for the standard guarded GPT-5.6. It also outperformed prior models on ExploitGym. OpenAI researchers used it to find previously undocumented bugs, including two V8 flaws in Chrome that could be chained for memory corruption and sandbox escape (fixed by Google as CVE-2026-15903), plus high-severity issues in a mobile OS, a database, and a kernel (details still under coordinated disclosure).

Who is affected

Vetted cybersecurity researchers and organizations with Daybreak Red access who want advanced AI assistance for offensive security research and vulnerability discovery.

Broader impact on the security community through newly found and disclosed vulnerabilities; the model itself is restricted to reduce misuse risk.

Why it matters

Lower refusal rates and stronger exploit-development performance accelerate legitimate defensive research and zero-day discovery, but also raise the capability bar for dual-use AI tools. OpenAI assessed the model at the High (not Critical) threshold under its Preparedness Framework—shortly after pausing work on the more capable Astra model over similar concerns.

Builders and operators benefit from faster identification of serious flaws (such as browser sandbox escapes) while needing to track the expanding set of AI-assisted findings.

What happened

CERT Polska detailed a December 29 cyberattack on a Polish combined heat and power (CHP) plant that marked the first observed case of attackers reaching an OT network through a private APN (dedicated mobile data network used by a Distribution System Operator).

The plant supplies heat to about 50,000 residents. Attackers shut down a steam turbine and water-treatment system, interrupting cogeneration; operators restored service before customer heat or power was affected. The entry path began at a compromised wind-farm substation FortiGate (internet-exposed VPN without MFA), moved to a Teltonika cellular router on the private APN, and reached a WAGO PFC200 PLC at the CHP plant that still used factory-default credentials. The PLC’s cellular modem was later found damaged. The incident coincided with coordinated attacks on ~30 renewable sites and another CHP plant.

Who is affected

Polish energy-sector operators, especially those using private APNs for distributed energy resources, wind-farm substations, and CHP plants with cellular-connected PLCs or routers.

Similar architectures are common in distributed energy and grid operations globally; any OT environment treating private cellular networks as fully trusted is exposed.

Why it matters

Private APNs are widely assumed to be isolated and secure, yet a single compromised edge device can provide a lateral path across otherwise unrelated facilities into industrial control systems. Default credentials and lack of MFA on VPN concentrators turned a remote foothold into OT disruption.

The attack shows how IT/OT convergence and shared cellular infrastructure create unexpected blast radius; timely restoration prevented outages for tens of thousands, but the dwell and wipe actions demonstrate destructive intent.

How it could have been prevented

Eliminate factory-default credentials on all PLCs, routers, and industrial devices. Require MFA and restrict internet exposure of VPN/firewall management interfaces. Segment private APN-connected devices; treat the APN as untrusted and apply network controls, monitoring, and least-privilege access between sites. Inventory and harden cellular-connected OT assets. Report unexplained OT disruptions promptly for investigation. Apply vendor patches and secure configurations to FortiGate and similar edge devices.

What happened

Poland’s CERT Polska revealed a previously unrecognized cyberattack on a smaller combined heat and power plant that occurred on the same December day as coordinated strikes against more than 30 renewable-energy sites and a larger heat plant. The smaller plant serves roughly 50,000 residents.

Operators initially attributed the steam-turbine and water-treatment shutdown to contractor error during maintenance; CERT Polska investigated because of timing. Attackers spent 11 days in reconnaissance, then disabled Siemens controllers, locked operators out with new passwords, wiped network-device configurations, and set addresses to unreachable values. Service was restored in about two hours without interrupting customer heating. The path used a private cellular APN reached via compromised wind-farm infrastructure. The broader campaign was later attributed to Russia’s FSB; this specific incident was not separately attributed in the supplementary report.

Who is affected

Polish critical-energy infrastructure operators and residents dependent on the affected CHP plant (~50,000 people). The wider December campaign threatened nearly 500,000 people with potential blackout.

Any operator relying on private APNs, shared cellular infrastructure between distributed energy sites, or devices with default credentials faces similar risk.

Why it matters

The attack nearly disrupted heating during a severe cold snap and demonstrated cross-facility lateral movement over infrastructure assumed to be isolated. Initial misattribution as human error delayed recognition, underscoring the need to investigate anomalous OT failures.

It highlights destructive tactics (controller lockouts, config wipes) aimed at slowing recovery and the value of thorough post-incident analysis even for low-priority reports. European energy operators must reassess trust in private mobile networks and inter-site connectivity.

How it could have been prevented

Harden all edge firewalls and VPNs with MFA and minimal exposure. Change default credentials on PLCs and controllers immediately. Micro-segment devices on private APNs and monitor east-west traffic between energy sites. Implement robust logging and anomaly detection on OT networks. Establish clear escalation paths for unexplained process interruptions. Follow CERT Polska guidance and NIS2-aligned reporting practices that encourage sharing of suspicious operational events.