Saturday, 15 August 2026

France's tax authority cut the intruders' accounts in June and July and found no data theft, it took the criminal's sale listing two months later to establish that 678,000 records had already gone

France's Ministry of Economy and Finance confirmed on 2026-08-14 that a malicious actor had obtained illegitimate access to the information system of the Direction générale des Finances publiques (the national tax authority) during June and July 2026, on the basis of credential impersonation of a DGFiP agent and of an authorised third party (Ministère de l'Économie et des Finances, 2026-08-14). Investigations conducted since 2026-08-12 established that before the accesses were cut, they had been used to view and extract data on a total of 678,000 individuals and businesses: tax data including the reference taxable income, the family quotient and the withholding-tax rate, and for companies the registered name and SIREN identifier, along with cadastral data on the addresses and surface areas of properties. DGFiP states that users' own Espaces Finances publiques accounts were not compromised, and it notified the CNIL as soon as the data theft was identified (Ministère de l'Économie et des Finances, 2026-08-14).

The operationally interesting part is the sequence, and it is a failure mode worth copying into a playbook. DGFiP detected the intrusions and immediately cut off every account involved, the containment step worked. But in the ministry's own words, the access reviews carried out at that point did not reveal that the intrusions had led to data theft, which it attributes to the sophistication of the attack. What surfaced the exfiltration was external: an actor using the alias ZeroBytes advertised the dataset on a cybercrime forum on 2026-08-12, and only the deep investigations that followed established the scope (Ministère de l'Économie et des Finances, 2026-08-14 · The Register, 2026-08-14). Between containment and discovery lay roughly two months in which the organisation believed it had handled the incident. Two of the actor's claims go further than anything the government confirms, and the gap between them is worth holding onto. ZeroBytes advertised the database as containing details of more than 2 million French taxpayers (against the 678,000 the ministry has established) and claimed the access was obtained using stolen credentials and a multi-factor-authentication bypass technique; it also claimed to retain access to DGFiP's systems and offered to sell that alongside the data (The Register, 2026-08-14). DGFiP disputed the claim that ZeroBytes retained access in its statement of the following day (The Register, 2026-08-14); its own published statement addresses neither that claim nor the multi-factor element, and records instead further precautionary cut-offs of access to sensitive information systems while investigations continue to determine the precise nature and volume of extracted data (Ministère de l'Économie et des Finances, 2026-08-14).

The access path carries no vulnerability: it is a valid agent account plus an authorised external party's credentials, which is the same shape as the compromised professional account at France's Ministère de l'Éducation nationale in July and the external service-provider account at Żabka. DGFiP's teams are working with the ministries' senior defence and security official and with ANSSI, and the authority will file a criminal complaint and contact each affected individual and business directly (Ministère de l'Économie et des Finances, 2026-08-14).

Triage: a legitimate tax-administration account queries citizen and business records all day, so record access is not the signal. The discriminators are volume and shape against that account's own baseline; sustained bulk retrieval or export where the role's normal pattern is individual case lookups, activity outside the agent's working hours, and an authorised third-party account reaching record classes its contracted purpose never needed.

The '2,500-organisation LiteLLM breach' was mostly not LiteLLM: 95% of the identified victims were collected before the poisoned packages existed, through the Trivy scanner their pipelines pulled unpinned

The widely reported figure (more than 2,500 organisations compromised through poisoned LiteLLM packages) turns out to describe the wrong artifact for almost all of them. SOCRadar re-analysed the exposure dataset row by row and found that "For 2,085 organizations, or 95% of the 2,188 that were identified, data collection activity ended before March 24, when the poisoned LiteLLM packages were published to the registry" (SecurityWeek, 2026-08-14 · SOCRadar, 2026-08-13). Collection that stops before the malicious packages exist cannot have come from them. SOCRadar times the start against the upstream event instead: the earliest collection record sits eighteen minutes after the poisoned Trivy build published, activity surged while malicious Trivy images were live on Docker Hub, and it closed once the registry quarantined the LiteLLM packages (SecurityWeek, 2026-08-14).

The upstream compromise is documented by the vendor itself. Aqua Security's incident advisory records that on 19 March "The attacker force-pushed 76 of 77 version tags in the aquasecurity/trivy-action repository and all 7 tags in aquasecurity/setup-trivy, redirecting trusted references to malicious commits", publishing a malicious Trivy build at the same time (Aqua Security, 2026-04-01). LiteLLM's own maintainers state the connection plainly: "We believe that the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow" (LiteLLM, 2026-03-24). A security scanner is an unusually good place to put credential-stealing code, because it is a tool organisations deliberately run inside their build systems with access to the material they are scanning.

One detail from Aqua's write-up deserves to outlive this incident. The poisoned tags carried GitHub's "Immutable" badge: "The attacker may have deliberately published immutable releases after force-pushing, locking in the malicious state. Organizations should not rely solely on the 'Immutable' indicator. Pinning to full commit SHAs remains the only truly immutable protection" (Aqua Security, 2026-04-01). A control that displayed as satisfied while being subverted is worse than an absent one, because it ends the review.

What the correction is worth to this constituency is visible in one of the confirmed victims. CERT-EU assesses "with high confidence that initial access was obtained through the Trivy supply-chain compromise, which was publicly attributed to a threat actor known as TeamPCP", in an intrusion into a European Commission cloud account from which "A significant volume of data (about 91.7 GB compressed) was exfiltrated ... including personal data such as names, email addresses, and email content" (CERT-EU, 2026-04-02). That is an EU institution reached through a build-pipeline dependency, not through a package a developer chose to install.

Triage: a security scanner reaching out during a build is normal behaviour, so egress from the runner is not by itself the discriminator. What separates this from a healthy pipeline is the pairing of a scanner invocation with credential-store and environment reads it has no reason to make, and outbound traffic to a destination that is not the scanner's own update or vulnerability-database endpoint, with the reference in the workflow file being a mutable tag rather than a commit SHA as the precondition that made it possible.

Builds on: 2026-08-06/litellm-callback-hook-post-inference-tool-call-forgery

Threema and its Swiss colocation partner were hit by the same adaptive DDoS wave, the attack moved to the hosting layer, and only the self-hosted customers stayed up

Threema, the Swiss end-to-end-encrypted messenger, published an account on 2026-08-14 of a two-day disruption: a series of large-scale DDoS attacks targeted Threema and its colocation partner Nine, and Threema states it is not entirely clear whether it was the primary target or whether the attacks were directed at multiple targets (Threema, 2026-08-14). The service was unavailable on the Tuesday between 19:30 and 23:30 CEST; the attacks resumed on Wednesday morning and produced intermittent brief interruptions until normal operations were restored at 12:23. Threema notes that its status page was initially not updating because of a technical issue unrelated to the attack, and that it took the page offline until that was fixed, a small detail with a wider lesson, since the channel an organisation uses to tell users what is happening shares infrastructure and failure modes with the thing that is failing.

Threema is explicit about what the incident was not: a denial-of-service attack targets only the availability of an online service, not its security, and even a successful one gives attackers no access to systems or data (Threema, 2026-08-14). It describes the defensive problem as a contest of resources in which sophisticated attackers continuously change their sources and patterns during an attack, producing what it calls a cat-and-mouse game, and notes that even with effective DDoS protection in place, temporary disruption cannot always be prevented when an attacker has considerable technical and financial resources, as, it says, may be the case with state actors. That is a general observation about well-resourced adversaries; Threema does not attribute this incident to one, and no other party has. Threema says it is adding specialised DDoS protection that filters attack traffic upstream of its own infrastructure, and an update on the same post records that protection as now activated in the production environment (Threema, 2026-08-14).

The transferable point for an operator sits in the two facts Threema puts either side of the outage. The attack reached the colocation partner as well as the service, which means an application-layer mitigation scoped to the service's own edge is not scoped to the whole failure domain; the hosting provider's capacity is a shared dependency, and a tenant is exposed to a volumetric attack aimed at a neighbour. And customers running Threema OnPrem, on their own infrastructure, were unaffected throughout and used their instances without interruption (Threema, 2026-08-14). For a public-sector body that has adopted a hosted secure-messaging service as its out-of-band or emergency communications channel, that is the operationally relevant sentence: the deployment model, not the protocol, decided who could still talk to each other that evening.

NHS Blood and Transplant sent organ-offer messages naming recipients over an unencrypted pager network, and because pager broadcasts leave no receiver log, it cannot scope who received them

A BBC investigation established that NHS Blood and Transplant (the service that coordinates organ transplants across the UK) routinely sent the names, dates of birth and the types of organs being offered or needed to members of hospital transplant teams using pagers, unaware the messages were not encrypted (BBC News, 2026-08-14). The messages also carried tissue-match scores and immunosuppression risk factors for the people receiving transplants. NHSBT acknowledged this was a data breach after being alerted by the BBC, said it was "deeply sorry", reported the breach to the Information Commissioner and has stopped sending patient data this way; its head of organ transplantation, Anthony Clarkson, said the service had been using the channel for urgent communications where speed can be critical, and that "We were surprised that these messages were not encrypted, and that vulnerability was there." The ICO confirmed NHSBT reported an incident and that it is making inquiries (BBC News, 2026-08-14).

The property that makes this different from an ordinary disclosure is the absence of a receiver-side record. Paging is a one-way broadcast: the BBC reports NHSBT's position that because recipients of pager messages cannot be tracked, it is unclear whether the unencrypted information was accessed or how many people may have been affected (BBC News, 2026-08-14). Luca Arnaboldi, an assistant professor at the University of Birmingham quoted in the investigation, described the technology as "never meant for privacy", noted that a broadcast reaches anyone on the right frequency across a wide area, and characterised the result as "an unauditable log of leaked information". The exposure was not limited to NHSBT: over a ten-day sample the BBC found hundreds of messages on the same network from ambulance trusts, hospitals and fire services, including mental-health incident details, medication details and the name of a patient trying to take their own life. North West Ambulance Service and Northern Ireland Ambulance Service, both named as users, said their messages did not include patients' names; NWAS said pagers have now been fully withdrawn (BBC News, 2026-08-14).

Responsibility here sits with configuration rather than with a defect. The company operating the paging network told the BBC it provides encrypted paging and secure-messaging solutions with "customers determining how those services are deployed", that it has no visibility of or control over the content its customers transmit, and that its terms make clear radio signals may be intercepted and advise customers not to send sensitive or personal information over radio (BBC News, 2026-08-14). In 2019 the then-Health Secretary, Matt Hancock, announced that the NHS in England should stop using pagers by 2021, and parts of the organisation continued regardless; the Department for Health said that where "legacy technologies" are still in use, patient information should be "handled securely and in line with data protection requirements" (BBC News, 2026-08-14).

JWR: a phishing kit that puts a live operator on an encrypted WebSocket into the victim's session, reading card and code digits as they are typed and choosing which one-time-code channel to demand

Cisco Talos published a dissection on 2026-08-13 of a phishing framework its developer brands "JWR", and assesses with medium confidence that it is a variant of "The Outsider", a phishing-as-a-service platform, based on several similarities in the client engine scripts and functionalities of the two platforms (Cisco Talos, 2026-08-13). The kit's client engine impersonates login and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna and banks, rendering across dozens of distinct phishing pages. Talos reports operator-facing status messages written entirely in Simplified Chinese, which it states indicates a Chinese-speaking operator, and observed a real-world campaign delivering the kit through SMS lures about toll or road-pricing fees and postal or courier fees, carrying a link (Cisco Talos, 2026-08-13).

The architectural change from an ordinary credential-harvesting page is the point of the research. JWR keeps an AES-CTR-encrypted WebSocket open between the victim's browser and the operator's console for the duration of the session, and streams every input field's keystrokes live: the console shows "partial card numbers, partial passwords, and partial verification codes as the victim types, without needing to wait for the victim to click any submit button" (Cisco Talos, 2026-08-13). That inverts the economics of one-time codes. A stolen code from a logged form is worth whatever remains of its validity window; a code read as it is typed, by an operator who is simultaneously driving a real session on the genuine site, is worth a completed transaction. Talos documents the mechanism explicitly: once the operator accepts the entered card data, "the operator sends one of the instructions: to_sms, to_2fa, to_pin, or to_app, directing the victim to a verification page to confirm their identity with a one-time code." The operator chooses which verification channel to demand, in real time, based on what the victim's bank actually uses, a rejected code re-prompts, an accepted one proceeds and the victim is redirected to the real site. A separate instruction lets the operator inject a code of their own choosing into the page without any victim-visible navigation.

Two further details bear on how easily this is caught. The framework carries an anti-analysis guard that "performs a self-referential .toString().search() call against a backtracking regex" to detect whether a debugger has attached and modified the function's apparent source (Cisco Talos, 2026-08-13), alongside decoy variables scattered specifically to mislead static analysis. And the Shopify integration is built to defeat origin-based judgement: the kit derives its WebSocket connection's base address from a legitimate signed parameter that Shopify itself passes between checkout steps, so the channel appears to originate from a plausible checkout domain while also letting the fake cart reproduce the victim's real products, quantities and totals. Talos compared JWR against three other phishing kits from the same ecosystem and found no shared code implementation despite behavioural similarity, which places this in a lineage of tradecraft rather than a shared codebase. Talos ships detection coverage for the threat through its own products.

Triage: a payment page legitimately opens outbound connections, so connection volume is not the discriminator. What separates this from a genuine checkout is the shape and persistence of the channel, a long-lived, bidirectional encrypted WebSocket opened immediately on page load and held for the duration of form entry, carrying traffic in both directions while the user types, against a page presenting a payment brand. Talos is explicit that the origin is deliberately engineered to look plausible for the Shopify path, so domain reputation alone will not separate the two; the behaviour of the channel will.

Mustang Panda's CoolClient backdoor gains a kernel driver signed with a 2013 certificate that expired in 2014, and it hides the malware's own C2 traffic by hooking the driver Windows uses to report network state

Kaspersky's GReAT team published a teardown on 2026-08-14 of a new variant of CoolClient, "a backdoor family attributed to the HoneyMyte APT group (also known as Mustang Panda) that has been used in their cyber-espionage campaigns targeting organizations across Asia and Russia" (Kaspersky Securelist, 2026-08-14). The variant introduces what Kaspersky describes as a previously undocumented kernel-mode driver, installed as a Windows service, that significantly expands the malware's stealth. Kaspersky identified victims in Myanmar, Mongolia, Pakistan and Russia, including confirmed government entities, and reports that across the observed intrusions CoolClient was consistently deployed as a secondary backdoor following a PlugX infection, the group continuing to use PlugX as its initial post-compromise implant before transitioning to CoolClient. The Hacker News covered the same research the same day (The Hacker News, 2026-08-14).

The detail that makes this worth a defender's attention is not that a rootkit exists but where its author decided to spend effort. The driver implements 33 IOCTL handlers, although the analysed sample uses only three during normal execution (Kaspersky Securelist, 2026-08-14): one registering the implant's own process as protected, one registering filesystem and registry paths to hide, and one registering the command-and-control IPv4 address. That third one is the interesting capability. The driver hooks the Windows component responsible for reporting network state to user-mode callers and strips the malware's registered C2 addresses from the results, so a responder running a connection-listing tool on the live host sees a machine with no connection to the attacker's infrastructure. The unused 30 handlers describe the intended capability envelope rather than what this sample did: shellcode injection into a target process, unlinking kernel modules from the loaded-module list, removing Protected Process Light status, disabling and restoring kernel notification callbacks, loading a further driver manually, and a handler that writes to an arbitrary kernel address. Concealment is enforced through three complementary mechanisms, object-handle callbacks protecting the injected process, a filesystem minifilter denying access to protected paths, and a registry callback that removes protected keys from enumeration results and denies direct access, with the implant's own registered processes exempted from the filtering.

Two preconditions bound the whole capability, and both are useful to a defender. Kaspersky reports the implant checks for full access to the Service Control Manager and the presence of SeTcbPrivilege before it extracts and installs the driver at all; where those are absent, it skips the kernel component and proceeds with the user-mode implant. Administrator rights are reached beforehand through a user-account-control bypass combining remote-procedure-call-based process creation with parent-process spoofing, a technique class already publicly documented rather than a novel evasion. The user-mode chain preceding it is classic sideloading: a renamed legitimate Sangfor-branded executable placed in a directory masquerading as a Windows Defender install path, with Defender exclusions added for that path beforehand, loading the attacker's first-stage library and injecting the final implant into another process. The signing certificate is the other bounded fact: the driver is signed, but with a commercial certificate issued to a Chinese company that was valid only from August 2013 to September 2014 (Kaspersky Securelist, 2026-08-14). Kaspersky found other, older malicious drivers signed with the same certificate but states no evidence connecting them to this campaign.

Triage: legitimate third-party software loads signed kernel drivers routinely, so a driver load is not by itself the signal. The discriminators here are the certificate and the callback pattern: a driver whose signing certificate expired more than a decade before the load, registering object-handle callbacks, a filesystem minifilter and a registry callback in close succession shortly after a newly installed service appeared, is not an ordinary endpoint agent. On the user-mode side, a Sangfor-branded executable or one named for Windows Defender running from a directory that is not the genuine Defender path (particularly where Defender exclusions were added for that same path moments earlier) is the pre-escalation shape, and it is visible before the kernel component ever loads.

Builds on: 2026-08-17/patchcord-sheetcord-google-sheets-c2-browser-shortcut-hijack

GeoServer: an unauthenticated SQL injection in the jsonArrayContains filter is being exploited with no CVE and no patch, and NCSC-CH has put it in front of Swiss operators

A security researcher publicly disclosed an unauthenticated SQL-injection flaw in GeoServer on 2026-08-12, and attackers began probing for it the same day. The defect sits in jsonArrayContains, an OGC filter expression used to test whether a JSON array field contains a given value; user-supplied filter arguments reach the backend database query without adequate sanitisation, letting an unauthenticated caller alter the query's logic. The reporting states the function can be used with PostGIS and Oracle JDBC data stores (SecurityWeek, 2026-08-14), and Switzerland's NCSC records the prerequisite as "Network access to an exposed GeoServer instance configured with PostGIS or Oracle JDBC data stores" (NCSC-CH, 2026-08-14). watchTowr's Jake Knott told SecurityWeek the firm began seeing exploitation attempts within hours of disclosure and has since recorded hundreds of them from a small number of source addresses (SecurityWeek, 2026-08-14); Field Effect separately published on early exploitation attempts against the flaw on 2026-08-13, and states the observed activity consisted primarily of scanning and probing for vulnerable systems with no confirmed compromises described in public reporting as of that date (Field Effect, 2026-08-13). Knott puts it the same way to The Hacker News: attackers are probing to identify vulnerable systems, triggering errors and not proceeding further (The Hacker News, 2026-08-13). That distinction matters for triage; this is mass reconnaissance against an unpatchable exposure, not yet a wave of confirmed intrusions, and the window to reduce exposure is still open.

Two things make this worse than its missing CVE suggests. There is no identifier, so a purely CVE-driven patch process, scanner feed or SBOM pipeline will not surface it at all, the same blind spot this pipeline recorded on the Metabase zero-day six days ago. And there is no fix: NCSC-CH's advisory states plainly that no patch is currently available and tells operators to identify exposed instances, restrict public access and monitor for exploitation (NCSC-CH, 2026-08-14). Escalation beyond data theft depends on the database account's privilege: The Hacker News quotes Knott saying the flaw could ultimately lead to remote code execution, and reports the researcher's claim that an administrator-level database account makes code execution achievable (The Hacker News, 2026-08-13). Knott also notes GeoServer's history of being targeted at scale, with multiple GeoServer flaws already in CISA's Known Exploited Vulnerabilities catalog (SecurityWeek, 2026-08-14).

The relevance to this constituency is the deployment pattern rather than a named victim: GeoServer is a standard component of government geoportals and INSPIRE-directive spatial-data infrastructure (cantonal and municipal GIS, land-registry and environmental-agency mapping services) and SecurityWeek notes it is used across government, agriculture, telecoms and transit (SecurityWeek, 2026-08-14). No Swiss or EU victim has been named publicly. Detection concepts, telemetry class first: in web-access telemetry for the GeoServer front end and any reverse proxy ahead of it, surface requests whose OGC Filter or CQL expressions carry jsonArrayContains arguments containing SQL metacharacters, quote characters or stacked-query syntax rather than well-formed JSON values; in database telemetry, watch for query-syntax errors and unexpected statement shapes issued under the GeoServer service account, since early probing tends to surface as malformed queries before it succeeds; in process-execution telemetry with parent lineage, any child process spawned by the Java servlet container hosting GeoServer is a strong post-exploitation signal, because GeoServer has no legitimate reason to spawn one.

Triage: legitimate GIS clients construct jsonArrayContains filters routinely, so the presence of the function in a request is not the signal. The discriminators are the argument's shape (quote characters, SQL keywords or stacked statements where a JSON value belongs) and the pairing of such a request with a database error or an anomalous query from the GeoServer service account moments later.

CVE-2026-26035, FortiWeb: one non-default RADIUS admin setting turns any username and password into a valid GUI/CLI login, alongside an FGFM impersonation bug and a FortiClient flaw reachable by anyone who can answer a laptop's DNS

Fortinet issued patches for eight vulnerabilities across its products on 2026-08-12 (SecurityWeek, 2026-08-13). Four of the flaws in that batch matter to a defender's next week. The most consequential is CVE-2026-26035 (CVSS 8.8, CWE-287): where FortiWeb's Remote RADIUS Type Admin authentication is configured with specific, non-default settings, a remote unauthenticated attacker can log into the FortiWeb GUI or CLI with a random username and password (Fortinet PSIRT, 2026-08-12). The setting in question is named in the advisory's own workaround: the Wildcard option on a Remote Type administrator account, reached in the GUI under System > Administrators. The affected branches, read from Fortinet's CSAF record rather than the advisory's rendered table, are FortiWeb 8.0.0 through 8.0.2, 7.6.0 through 7.6.6, 7.4.0 through 7.4.11, 7.2.0 through 7.2.12 and 7.0.0 through 7.0.12. Released fixes exist for three of those five: 8.0.3, 7.6.7 and 7.4.12. The 7.2 and 7.0 branches are answered only by builds the record marks as upcoming (7.2.13 and 7.0.13) so an estate on either has no patch to install today and the Wildcard configuration check is its whole remediation.

CVE-2026-70468 (CVSS 7.3, CWE-288) is the management-plane counterpart: a remote unauthenticated attacker holding a valid certificate can impersonate any FortiGate managed by a FortiManager that has a specific CLI option set, via crafted FGFM protocol requests (Fortinet PSIRT, 2026-08-12). The option is fgfm-peercert-withoutsn, and disabling it is the vendor's stated workaround. Affected are FortiManager 7.6.1, 7.4.3 through 7.4.5 and 7.2.5 through 7.2.9 plus the corresponding FortiManager Cloud versions, fixed in 7.6.2, 7.4.6 and 7.2.10; FortiManager 8.0 is listed as not affected. CVE-2026-70466 (CVSS 4.8, CWE-184) is an incomplete list of disallowed inputs in the FortiWeb WAF that lets an unauthenticated attacker bypass policies via specifically crafted requests (Fortinet PSIRT, 2026-08-12), a lower score, but a WAF that can be walked past is a compensating control that has stopped compensating. Its version data is the one to read carefully: 8.0.0 through 8.0.2 are answered by 8.0.3 and 7.6.0 through 7.6.5 by 7.6.6, but the 7.4, 7.2 and 7.0 branches are all listed as affected at every version with no fixed build at all (migration is the only remediation, and Fortinet offers an interim virtual patch, FG-VD-10009598.0day, in FortiWeb signature database update FMWP 26.071) the concrete lever for the three branches with no fixed build.

The fourth flaw in the batch is the one that reaches past the data centre. CVE-2026-70465 (CVSS 7.3, CWE-120) is a buffer copy without checking the size of input in FortiClient for Windows that "may allow an unauthenticated attacker in a position to alter or craft DNS responses to the targeted host to execute arbitrary code via malicious packets" (Fortinet PSIRT, 2026-08-12). The precondition is not a credential but a network position: anyone able to answer the endpoint's DNS queries (a hostile or compromised local network, a captive portal, an on-path attacker upstream of a home or hotel connection) can reach the code path. That is precisely the position a remote-working laptop puts itself in every time it joins an untrusted network before the VPN comes up, which makes this a teleworker-fleet problem rather than a server-patching one. FortiClient for Windows 7.4.0 through 7.4.3 upgrade to 7.4.4 and 7.2.0 through 7.2.11 upgrade to 7.2.12; the 8.0 branch is not affected. Fortinet's stated workaround is to disable application-based filtering in the FortiClient EMS remote-access profile's VPN tunnel settings. SecurityWeek notes Fortinet makes no mention of any of these vulnerabilities being exploited in the wild (SecurityWeek, 2026-08-13).

None of them is reported exploited: SecurityWeek records that Fortinet makes no mention of any of these vulnerabilities being exploited in the wild. What lifts them above the ordinary patch queue is that two of them are configuration-gated, which cuts both ways: an estate that never enabled the Wildcard option or fgfm-peercert-withoutsn is not exposed at all and needs only a routine upgrade, while one that did is exposed right now and can close the hole today with a settings change rather than a maintenance window. That makes the first task an inventory question, not a patching question, and it is answerable in minutes across a fleet. The certificate precondition on the FortiManager bug is worth reading precisely: it does not say a certificate issued to the impersonated FortiGate, and the advisory's own framing is an alternate-path authentication bypass, so a defender should treat any valid certificate the deployment would accept as sufficient rather than assuming device-specific binding.

Detection concepts, telemetry class first: in administrative authentication logs on FortiWeb, a successful GUI or CLI admin login for a username that does not exist in the backing RADIUS directory is the signature of this bypass being used, the login succeeds locally, so the discriminator is the mismatch between the accepted account and the identity store that was supposed to authorise it. In management-fabric telemetry on FortiManager, watch for FGFM session establishment from a source presenting a certificate whose subject does not correspond to the device serial the session claims, and for a managed FortiGate appearing to check in from an unexpected address or twice from different sources. Fortinet edge and management products have a sustained recent history of rapid post-disclosure weaponisation (this pipeline recorded a Gunra ransomware campaign abusing older FortiOS authentication-bypass flaws for initial access four days ago) so the interval between a published advisory and a working exploit is the planning assumption here, not the absence of exploitation today.

CVE-2026-19188, Haiwell IoT Cloud HMI Gateway: the diagnostic ping in the web interface runs attacker-supplied shell commands as root, unauthenticated (CVSS 10.0)

CISA published ICS advisory ICSA-26-225-02 on 2026-08-13 for CVE-2026-19188, an OS command injection (CWE-78) in the Haiwell IoT Cloud HMI Gateway, a human-machine-interface gateway from a China-headquartered vendor that CISA reports deployed worldwide across the energy, critical manufacturing, and water and wastewater sectors. The advisory places the defect in the gateway's Net Check diagnostic feature, reachable via the /setting endpoint: the cmdPing Socket.io event fails to properly sanitize user-supplied input before passing it to the underlying operating system, so an attacker injects and executes arbitrary OS commands with root privileges (CISA, 2026-08-13). CISA scores it CVSS 3.1 base 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, network-reachable, low complexity, no privileges, no user interaction, and a scope change reflecting that the injected commands run outside the web application's own boundary.

Two properties in the structured record decide the urgency, and neither is the score. The advisory's SSVC decision data records exploitation as none observed but automatability as yes; CISA's assessment that the steps from reconnaissance through exploitation can be reliably scripted against every reachable instance (CISA, 2026-08-13). A no-credential, no-interaction root primitive that a script can find and fire at scale does not stay unexploited because nobody has tried yet; it stays unexploited until somebody writes the loop. The second is remediation shape: only version 3.40.1.12 appears in the affected list, and Haiwell's fix is patch version Scada-v3.50.1.19, published as a download on the vendor's own site rather than as a firmware push, so applying it is an operator action on each unit (CISA, 2026-08-13). CISA's standing guidance in the same advisory is to minimise network exposure for control-system devices, keep them off the internet, place them behind firewalls isolated from business networks, and use more secure methods such as a VPN where remote access is required.

For a defender the exposure question is sharper than the patch question, because an HMI gateway exists to be reached remotely, that is its product function, and the diagnostic ping is a feature an operator is meant to use. Detection concepts, telemetry class first: in network telemetry at the perimeter and in front of the OT segment, surface any inbound session to the gateway's management interface from outside the expected engineering-access source ranges, and specifically WebSocket or Socket.io connections carrying cmdPing events whose host argument contains shell metacharacters, a semicolon, pipe, backtick or command-substitution syntax where a hostname or address belongs. On the device or in any host telemetry available from it, a root-owned process spawned by the gateway service other than the ping utility it legitimately invokes is the post-exploitation signal, as is an outbound connection initiated by the gateway process shortly after inbound management traffic; an OT gateway that starts calling out immediately after being asked to run a diagnostic is not doing what it was asked.

Triage: the Net Check feature genuinely spawns a ping process when an engineer uses it, so process creation from the gateway service is not by itself the discriminator. What separates the two is the argument and the source: a legitimate diagnostic carries a bare hostname or IP address from an engineering workstation inside the maintenance path, while the exploited call carries shell syntax in the same field and arrives from outside that path, and the resulting process is something other than the ping binary.