ctipilot.ch
Sun · 26 Jul 2026
All daily briefs ↗
Daily brief · UTC day

Sunday, 26 July 2026

10 verified findings from 2 runs · the settled record for this UTC day, in the classic brief order.

Criticality
Kind
Topic
Region
TL;DR · the day in one read
  1. 01WP2Shell is now confirmed exploited in the wild — unpatched WordPress needs a compromise assessment, not just a patch. The WordPress Core "WP2Shell" pre-auth RCE chain (CVE-2026-63030 route confusion in the unauthenticated REST batch endpoint, chained with CVE-2026-60137 SQL injection) went from "no confirmed in-the-wild exploitation" at first coverage to confirmed exploitation: CISA added both CVEs to the Known Exploited Vulnerabilities catalog on 2026-07-21, and honeypot operators and incident responders reported live exploitation attempts and real intrusions from 2026-07-19. Any WordPress 6.9.0–6.9.4 or 7.0.0–7.0.1 instance that was internet-reachable before it was patched to 6.9.5 / 7.0.2 must now be treated as a compromise-assessment target.
  2. 02An espionage toolkit that only decrypts its final implant on the target machine, and talks C2 through the Telegram Bot API. Zscaler ThreatLabz documents a previously undocumented three-stage toolkit used against government entities, attributed with moderate-to-high confidence to an East-Asia-based actor. The chain is a hunt-relevant combination rather than a novel exploit: an ISO delivers a legitimate ASUSTek binary that side-loads a malicious DLL to execute under a trusted vendor executable; the TELESHIM backdoor persists via scheduled tasks and uses the Telegram Bot API for command-and-control so its traffic resolves to a mainstream service; and the final BINDCLOAK implant decrypts only with a key derived from the victim machine's volume serial number, so it will not run in a sandbox or on an analyst's copy.
  3. 03Two national CERTs escalated the July Oracle cycle: 219 of the Fusion Middleware fixes need no authentication at all. Oracle's July 2026 Critical Patch Update carries 1,449 patches, of which Fusion Middleware alone accounts for 355 — 219 of them remotely exploitable without authentication and nine distinct CVEs at CVSS 10.0, each reachable over a standard network protocol with no credentials. NCSC-NL (NCSC-2026-0252) and CERT-FR (CERTFR-2026-AVI-0920) both issued advisories inside this window, with NCSC-NL assessing that large-scale abuse in the short term is very likely. No exploitation of the new CVEs is confirmed; the CVSS-10.0 set includes Oracle Data Integrator (CVE-2026-47056) and Oracle Coherence (CVE-2026-60217), and the exposure that matters is internet-reachable Fusion Middleware rather than the patch count.
01Active threats, incidents & disclosures1 item
NOTABLENATOB1

FakeAgent — malvertising hosts a fake AI-desktop-app download page on the vendor's own trusted domain, delivering SectopRAT by DLL side-loading

The interesting part of this campaign is not the payload but the hosting. Huntress reports that between 2026-07-21 and 2026-07-22 "at least 29 organizations fell victim to a malvertising campaign" in which users searching for the Claude Desktop application were served a sponsored result whose link genuinely resolved to claude.ai — the vendor's own domain (Huntress, 2026-07-22). The destination was a public, user-created artifact on the platform, built to imitate the official download page and viewed some 7,100 times before it was removed (Help Net Security, 2026-07-23). Every control that keys on domain reputation — ad-network vetting, corporate URL allowlists, certificate inspection, the user's own glance at the address bar — reported a trustworthy destination, because the destination genuinely was the vendor's site. Only the onward redirect to attacker infrastructure serving the installer left the trusted domain.

Execution follows a signed-binary side-loading pattern rather than running unsigned attacker code directly. The fake installer drops a repurposed JetBrains Chromium Embedded Framework helper alongside a trojanised libcef.dll packed with VMProtect; as Huntress puts it, "By maliciously modifying that function in the DLL, an adversary can achieve execution in the context of a trusted and signed executable" (Huntress, 2026-07-22). A second persistence chain repeats the trick with an IBM SPSS binary side-loading tempdir.dll, adding GPU-based anti-analysis checks and an unusual unpacking step — "The malware's decryption routine isn't a typical CPU-based decryption routine: instead, it is a compiled DirectX shader", which moves the decryption work off the CPU paths that sandboxes and emulators instrument. The delivered payload is SectopRAT, an information stealer and remote-access tool with hands-on-keyboard capability (BleepingComputer, 2026-07-23); Huntress is the source for what it reaches for and how it is controlled — plaintext strings referencing browser logins, cookies, autofills and credit cards, and command-and-control data stored in the Ethereum blockchain, the takedown-resistant technique known as EtherHiding (Huntress, 2026-07-22).

Triage: DLL side-loading under signed third-party binaries produces telemetry that looks legitimate at the process level — the signed JetBrains or IBM SPSS executable is genuinely signed, and its presence on a developer or analyst workstation can be entirely normal. The discriminators are location and lineage: the signed helper running from a user-writable download or temporary directory rather than its installed application tree, loading a module of the expected name from that same directory, with no parent installation of the product it belongs to. A browser or installer process as the immediate ancestor, followed by reads of browser credential stores by that process tree, is the sequence worth alerting on; the signed binary alone is not.

Between July 21 and July 22, at least 29 organizations fell victim to a malvertising campaign

By maliciously modifying that function in the DLL, an adversary can achieve execution in the context of a trusted and signed executable

The malware's decryption routine isn't a typical CPU-based decryption routine: instead, it is a compiled DirectX shader

Huntress 2026-07-22
threat26 Jul 14:02Zmulti-sourceOpen finding ↗
NOTABLECVE-2026-47056 +2NATOA1

Oracle July 2026 CPU — nine unauthenticated CVSS 10.0 flaws in Fusion Middleware, with NCSC-NL assessing large-scale abuse as very likely in the short term

Oracle's quarterly Critical Patch Update is normally exactly what the routine patch cycle exists to absorb, and most of the July 2026 release is. What separates this one is a concentration that two national CERTs judged worth their own advisories inside the following week. On Oracle's own account, "This Critical Patch Update contains 355 new security patches , plus additional third party patches noted below, for Oracle Fusion Middleware. 219 of these vulnerabilities may be remotely exploitable without authentication" (Oracle, 2026-07-16); CSOonline reports the same split, noting that "Fusion Middleware was particularly hard hit, with new security patches for 355 security vulnerabilities, 219 of them remotely exploitable without authentication, meaning they can be exploited over a network without requiring user credentials" (CSOonline, 2026-07-22).

Two counts differ between the sources, and the difference is worth knowing before you brief anyone. NCSC-NL states that the most severe vulnerabilities, nine of them, received the highest score of 10.0 (NCSC-NL, 2026-07-22), while press coverage says ten. Both are right about their own object: Oracle's Fusion Middleware risk matrix carries ten rows at base score 10.0 but only nine distinct CVE identifiers, because CVE-2026-60365 appears twice — once under Oracle HTTP Server and once under the WebLogic Server Proxy Plug-in (Oracle, 2026-07-16). NCSC-NL's total for the component also differs from Oracle's, 345 fixes against Oracle's 355. Nine distinct maximum-severity CVEs is the figure to use.

Each of the nine is reachable over a standard network protocol — HTTP, LDAP, SOAP, or raw TCP in Oracle Coherence's case — with no authentication and no user interaction. NCSC-NL's advisory lists the maximum-severity CVE identifiers, among them CVE-2026-47056 and CVE-2026-60217 (NCSC-NL, 2026-07-22); it does not itself pair those identifiers with products, so the pairing, the component names and the affected versions all come from Oracle's risk matrix rather than the advisory — Data Integrator 12.2.1.4.0 and 14.1.2.0.0 in the Rest Service component, and Coherence Core 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0 (Oracle, 2026-07-16). The remaining maximum-severity cases sit across Oracle Access Manager, HTTP Server, Platform Security for Java, WebCenter Content, Service Delivery Platform, Unified Directory and the WebLogic Server Proxy Plug-in. On the database side CVE-2026-61211 (CVSS 9.9) abuses DBMS_CLOUD to reach full server control, though that one is post-authentication.

The escalation is the CERT assessment rather than any observed activity. NCSC-NL's advisory states that "Because of the large number and the severity of these vulnerabilities, the NCSC considers it very likely that large-scale abuse will take place in the short term" (NCSC-NL, 2026-07-22), and CERT-FR published its own advisory the following day (CERT-FR, 2026-07-23). To be precise about what is and is not known: there is no confirmed in-the-wild exploitation of any of the new CVEs, no public proof-of-concept code, and no reported scanning specific to them. This is a forward-looking assessment by two national authorities about an exposure class with a long history of rapid weaponisation, not a report of an active campaign.

Triage: with no public exploit detail there is no behavioural signature specific to these CVEs, and inventing one would be guesswork. What is available is exposure telemetry: enumerate which Fusion Middleware listeners answer from outside the perimeter, and in web-server and application logs for those hosts, treat unauthenticated requests to administrative or REST service paths from unfamiliar source ranges as the class worth reviewing while patching proceeds. Note that Coherence's cluster protocol is raw TCP rather than HTTP, so HTTP-layer inspection will not see it — that exposure has to be established from network policy rather than from application logs.

Door het grote aantal en de ernst van deze kwetsbaarheden acht het NCSC het zeer waarschijnlijk dat grootschalig misbruik op korte termijn plaats gaat vinden.

NCSC-NL (NCSC-2026-0252)

Fusion Middleware was particularly hard hit, with new security patches for 355 security vulnerabilities, 219 of them remotely exploitable without authentication, meaning they can be exploited over a network without requiring user credentials.

CSOonline 2026-07-22
vulnerability26 Jul 14:11Zmulti-sourceOpen finding ↗
NOTABLECVE-2026-61425 +5NATOB2

The Joomla third-party-extension disclosure wave this pipeline has been tracking has been a file-upload story: unauthenticated uploads reaching code execution, several of which were weaponised and CISA-KEV-listed within days of disclosure. The batch mySites.guru published between 2026-07-20 and 2026-07-23 adds a different and more direct failure. In Balbooa's Gridbox page builder, "A critical unauthenticated authentication bypass in Gridbox let anyone become a Super User on a Joomla site by setting a single browser cookie" (mySites.guru, 2026-07-20). The extension treats a client-supplied cookie value as proof of identity rather than as an assertion to be validated against server-side session state, so an anonymous requester who places an administrator's username in that cookie is served the site as that administrator — no password, no login form, no pre-existing session. Because a Joomla Super User can edit templates, and templates are PHP, the practical outcome is code execution on the web server from a single unauthenticated request. Gridbox 2.20.1 fixes it; the vulnerable code had shipped since the previous release in October 2025, roughly nine months of exposure.

The rest of the week's batch is the same research campaign continuing on its original axis, with two flaws that matter beyond the site itself. EasyStore for Joomla carried an unauthenticated SQL injection able to read the whole site database (CVE-2026-65761, scored 9.3 by the Joomla CNA) plus an order-forgery flaw (CVE-2026-65759, 8.7) where "An anonymous request to the order-repayment endpoint could mark any order paid with no login, no token, and no contact with any payment gateway" (mySites.guru, 2026-07-23), fixed in 2.0.2. Events Booking exposed invoices containing personal and financial data to anonymous requests that simply walked sequential identifiers, fixed in 5.8.2 (mySites.guru, 2026-07-21). Membership Pro's unauthenticated upload was initially disputed by the vendor — the researcher records that "The vendor called it 'not a critical security issue.' The Joomla CNA disagreed" and it was assigned CVE-2026-62415 at 9.1 critical, fixed in Membership Pro 4.6.2 (mySites.guru, 2026-07-21).

There is no public exploitation signal for any of these: the researcher withholds the exact cookie name, endpoints and proof-of-concept code under a fix-first policy. The reason to act ahead of the routine extension-update cycle is the wave's own track record rather than current telemetry — earlier members of this same disclosure series moved from publication to confirmed in-the-wild exploitation within days once the mechanism became public, and a cookie-forgery bypass is trivially rediscovered by anyone who diffs the 2.20.1 release against its predecessor.

Triage: a cookie-forgery bypass leaves little at the network layer to distinguish it — the request is well-formed and returns HTTP 200. The observable is the mismatch between authentication and privilege: administrative actions in Joomla's action log attributed to a Super User account with no preceding successful login event for that account, and no session-establishment record. Legitimate administrator activity is preceded by an authentication event from a consistent source; forged-cookie access produces privileged actions that appear without one. On sites running affected Gridbox versions, template-file modification timestamps postdating the October 2025 release, with no corresponding administrator login, are the artefacts worth reviewing.

A critical unauthenticated authentication bypass in Gridbox let anyone become a Super User on a Joomla site by setting a single browser cookie

An anonymous request to the order-repayment endpoint could mark any order paid with no login, no token, and no contact with any payment gateway.

mySites.guru 2026-07-20
vulnerability26 Jul 14:08Zsingle-sourceOpen finding ↗
Sources: mySites.guru
NOTABLENATOC2

GitLab CE/EE RCE via the Jupyter-notebook diff renderer and two ~5-year-old Oj Ruby-parser memory-corruption bugs — public PoC, silent patch, no CVE

depthfirst disclosed (2026-07-24) a remote-code-execution chain against default self-managed GitLab CE/EE, reached through GitLab's in-tree ipynbdiff gem, which calls Oj::Parser.usual.parse — the native-C implementation of the Oj Ruby JSON parser — whenever a commit diff contains a .ipynb (Jupyter notebook) file (depthfirst, 2026-07-24). Two Oj memory-safety bugs that had survived in the parser for nearly five years (introduced 2021-08-08, first shipped in Oj 3.13.0, and reachable in GitLab from 15.2.0 once notebook validation switched to Oj in July 2022) are combined: an unchecked 16-bit key-length narrowing truncates an oversized object key and causes GitLab's notebook-diff output to print a live heap pointer (used to defeat ASLR and locate libc/libruby), and an unchecked nesting-stack overflow in Oj::Parser.usual.parse supplies a write primitive that redirects a parser callback to system(). The whole chain needs no elevated access — in depthfirst's words, "A normal authenticated user able to create or push to a project and view the resulting commit diff could commit an .ipynb file" (depthfirst, 2026-07-24) — no admin rights, no CI/runner access, no victim interaction — by committing two crafted notebooks and requesting the commit diff (GET /<project>/-/commit/<sha>/diffs_stream).

The affected range is GitLab CE/EE 15.2.0–18.10.7, 18.11.0–18.11.4 and 19.0.0–19.0.1; GitLab shipped the fixed Oj (3.17.3) in its 10 June 2026 releases 18.10.8, 18.11.5 and 19.0.2 (The Hacker News, 2026-07-25). The operationally important detail is that GitLab did not record the fix in its security-fix table and no CVE was assigned to the GitLab chain, so any operator that tracks GitLab patching against the vendor's security-advisory feed missed it for the 44 days between the silent 10 June bump and the 2026-07-24 PoC publication; GitLab.com and Dedicated instances were already patched, but self-managed operators must act. A separate set of nine Oj advisories (covering the dumper, loader, SAJ callback and document APIs, each with its own CVE) came out of the same depthfirst review and are also fixed in Oj 3.17.3. No in-the-wild exploitation is reported; this is a disclosed researcher PoC.

The resulting chain affected GitLab CE and EE versions 15.2.0 through 18.10.7, 18.11.0 through 18.11.4, and 19.0.0 through 19.0.1.

A normal authenticated user able to create or push to a project and view the resulting commit diff could commit an .ipynb file

depthfirst 2026-07-24
vulnerability26 Jul 04:25Zsingle-sourceOpen finding ↗
03Research & investigative reporting2 items
NOTABLENATOB2

TELESHIM / MIXEDKEY / BINDCLOAK — DLL side-loading under a legitimate vendor binary, Telegram-API C2 and volume-serial environmental keying against government networks

The victims here are government entities in the Middle East, not Europe, and the actor is assessed as East-Asian — so the reason this matters to a Swiss or European government defender is the tradecraft, which is aimed at exactly their target class and combines three techniques that each defeat a different common control. Zscaler ThreatLabz "observed new activity by a threat actor with links to East Asia targeting government entities in the Middle East", assessing attribution "with moderate-to-high confidence" on the basis of "the geolocation of the IP address, the configured system locale, and active operational hours matching regional working timeframes" (Zscaler ThreatLabz, 2026-07-20) — a hedge worth carrying as stated rather than hardening into a country attribution.

Initial execution comes from an ISO containing a legitimate ASUSTek executable, RegSchdTask.exe, which side-loads a malicious library named AsTaskSched.dll; at the staging step the legitimate executable is copied to its working path under the name shimgen.exe (Zscaler ThreatLabz, 2026-07-20). The first code to run therefore executes under a legitimate vendor binary rather than an attacker-authored one, so controls that key on the executable's identity or reputation see a known-good file. The first-stage TELESHIM backdoor persists through scheduled tasks and, rather than contacting dedicated infrastructure, "abuses the Telegram API for C2 communication, a technique used to blend in with legitimate internet traffic" — which means the egress destination is a mainstream service that many organisations either allow outright or cannot block without business friction, and domain- or reputation-based egress control gives no signal. TELESHIM and the MIXEDKEY reflective loader carry heavy obfuscation (control-flow flattening, mixed boolean arithmetic, opaque predicates), and the final BINDCLOAK implant is decrypted only with a key derived from the victim machine's volume serial number, so the payload cannot be detonated on any machine other than the intended one.

Triage: the ASUSTek executable is a legitimate vendor file, and DLL side-loading of this kind produces process telemetry that looks legitimate — so the discriminators are location and provenance rather than the executable's identity. Look for that vendor executable running from a mounted-image path or a user-writable directory instead of its installed application tree, loading a same-directory DLL, on a host with no corresponding ASUS software installed; a scheduled task created shortly afterwards under that lineage raises it further. For the C2 leg, traffic to the Telegram Bot API from a server or from a workstation whose user has no Telegram client installed is the reviewable case — Telegram traffic from staff endpoints that legitimately run the app is noise, and the discriminator is the absence of the client, or a non-browser, non-Telegram process making the connection.

ThreatLabz observed new activity by a threat actor with links to East Asia targeting government entities in the Middle East.

TELESHIM abuses the Telegram API for C2 communication, a technique used to blend in with legitimate internet traffic.

Based on the geolocation of the IP address, the configured system locale, and active operational hours matching regional working timeframes, ThreatLabz assesses with moderate-to-high confidence that the threat actor is operating out of East Asia.

Zscaler ThreatLabz 2026-07-20
research26 Jul 14:15Zsingle-sourceOpen finding ↗
NOTABLECVE-2025-33053exploitedNATOB1

An exposed WebDAV delivery lab shows industrialised .url/.lnk lure testing against CVE-2025-33053, with LLM-written tooling and ClickFix pages

Rapid7's managed-detection practice started from one alert — WebDAV-sourced execution via rundll32 — and pivoted to the operator's staging infrastructure, which was exposed to the internet. "It was functioning as a fully operational malware delivery lab", holding over a thousand artifacts arranged the way an engineering team arranges a test suite: 453 shortcut-based delivery launchers, 236 filename-spoofing tests, 146 tests of execution through trusted Windows tooling, 89 encrypted droppers, ClickFix pages impersonating Cloudflare, Adobe and Discord, and internal operator documentation (Rapid7, 2026-07-20). Rapid7's characterisation of the working method is the finding — "the attacker used LLMs to operate more like a modern software product team" — a line The Hacker News quotes in its own coverage (The Hacker News, 2026-07-20). The specifics behind it — generated README documentation, and bulk-produced lure variants on invoice and salary-statement themes rather than hand-crafted one-offs — are Rapid7's (Rapid7, 2026-07-20).

The technique under test is CVE-2025-33053, a flaw in how Windows resolves the working directory of a shortcut file: a legitimate, signed binary invoked through the shortcut resolves a companion file from the attacker-controlled remote WebDAV path rather than the local filesystem, so the attacker's code executes under the trusted binary's identity. The delivery side pairs WebDAV over HTTP and HTTPS with search-ms: URIs, which render a remote share as a familiar local search-results window, to invoke remote .scr executables disguised as documents. The operator's own embedded notes on the technique read "NO SmartScreen, NO MoTW warnings!" (Rapid7, 2026-07-20) — the claim being that content fetched this way never acquires the Mark-of-the-Web that would otherwise trigger the reputation and protected-view prompts users are trained on. One theme was already live rather than in testing: a national-ID-themed phishing campaign recorded 2,384 launches of a disguised .scr file delivering PureRAT to victims in Mexico.

Triage: WebDAV mounts and rundll32 executions both occur legitimately, so neither alone is the signal. The discriminating pattern is a Windows binary executing with its working directory resolved to a remote UNC or WebDAV path, particularly when the immediate parent is a shortcut invocation from a mail or browser download directory, and when the process subsequently makes outbound connections to the same remote host it loaded from. In process telemetry, correlate the remote working directory with the trusted-binary image path — an administrative script legitimately run from a file share will normally come from an internal, known server, and the discriminator is an external destination combined with a user-initiated document-open lineage.

the attacker used LLMs to operate more like a modern software product team

Rapid7 2026-07-20

NO SmartScreen, NO MoTW warnings!

Rapid7, quoting the operator's own embedded documentation
research26 Jul 14:05Zmulti-sourceOpen finding ↗
04Updates to prior coverage4 items
NOTABLEupdateNATOC2

IFAGE Geneva — DragonForce publishes the stolen data, exposing student exam results the institute had said were unaffected

UPDATE · originally covered DragonForce lists Geneva's IFAGE adult-education foundation on its leak site, claiming 850 GB — an attribution and volume IFAGE has not confirmed (2026-07-14)

the DragonForce listing against IFAGE — the Fondation pour la formation des adultes à Genève — is no longer an unverified leak-site claim. The group carried out its threat and published the data, which Le Temps reported had been done as of Thursday 2026-07-23: "Des photos de pièces d'identité, des adresses e-mail et postales, ainsi que des numéros de téléphone ou encore des résultats d'examens ont été publiés." — identity-document photographs, e-mail and postal addresses, telephone numbers and examination results (20 minutes, 2026-07-24). The same report states that their disclosure by the cybercriminals "concerne tant des employés de l'institut que des bénéficiaires (étudiants, entreprises, etc.)" — it covers both the institute's employees and its beneficiaries, meaning students and companies. It also cites an expert consulted by Le Temps who put the exposure at thousands of documents spanning several years and running to 2026. ICTjournal had reported the extortion threat a week earlier (ICTjournal, 2026-07-17).

The operationally interesting part is the gap between the victim's scoping and the published set. IFAGE's earlier public account of its incident placed the impact on employee data rather than student or pedagogical records; the leak contains multi-year examination results for students. First coverage flagged that the group's claimed volume already exceeded the institute's own disclosure, and publication has now settled that discrepancy in the attackers' favour. Nothing in the reporting identifies the initial-access vector, so no access-path lesson is available from this incident.

Contradiction: the sources and the victim do not agree on whether a ransom was ever demanded, and this entry does not resolve it. 20 minutes frames the publication as the consequence of an unpaid demand — "Si la rançon demandée n'était pas payée, les pirates informatiques qui s'en sont pris en avril à l'Ifage (Fondation pour la formation des adultes à Genève) promettaient de mettre en ligne les données dérobées" — while also reporting the foundation's own position that "La fondation avait aussi affirmé qu'elle n'avait pas reçu de demande de rançon, mais que, le cas échéant, elle refuserait de payer": it had received no ransom demand, but would refuse to pay if one came (20 minutes, 2026-07-24). ICTjournal is more definite on the demand's existence, reporting a week earlier that a ransom was now being demanded and that the group threatened to publish at the expiry of the ultimatum posted on its leak site (ICTjournal, 2026-07-17). A leak-site ultimatum naming a ransom the victim says never reached it is a common pattern and not necessarily either party misspeaking — demands are frequently posted publicly rather than delivered.

Des photos de pièces d'identité, des adresses e-mail et postales, ainsi que des numéros de téléphone ou encore des résultats d'examens ont été publiés.

Leur divulgation par les cybercriminels concerne tant des employés de l'institut que des bénéficiaires (étudiants, entreprises, etc.).

20 minutes
incident26 Jul 13:58ZcontradictedOpen finding ↗
NOTABLEupdateNATOB1

ANCPI Romania — DNSC interim report confirms vCenter-to-ESXi ransomware and exfiltration of ~2 million ePayment user records

UPDATE · originally covered ANCPI (Romania cadastre): agency says core databases were NOT compromised, contradicting ByteToBreach's destruction claim; Gov Cloud migration to complete 22 July (2026-07-21)

the picture of the attack on ANCPI, Romania's national cadastre and land-registration agency, has changed substantially. Earlier coverage recorded the agency's own position that its databases were not affected. Romania's national cybersecurity directorate DNSC has since published an interim technical report, relayed with direct quotation by Romanian technology press, that supersedes that framing on the point that matters most: the attackers extracted approximately two million records concerning users of the payment platform, containing names, e-mail addresses, identifiers and password hashes — in the report's Romanian, "atacatorii au extras aproximativ două milioane de înregistrări privind utilizatori ai platformei de plăți, care conțineau: nume; e-mailuri; identificatori; hash-uri ale parolelor" (PS News, 2026-07-24). The "databases not affected" assurance survives only in a much narrower form — DNSC states there is no indication the main Oracle Exadata database was compromised (go4it.ro, 2026-07-24) — which is a different claim from "no data was taken", since a separate payment-platform datastore demonstrably was.

The intrusion path DNSC describes is the one that makes a virtualized government estate fail all at once. Per the report the attackers compromised the authentication servers, penetrated VMware vCenter — the system administering the entire virtual infrastructure — enumerated all 1,083 virtual machines, executed lateral movement, deleted approximately 100 virtual machines and encrypted ESXi servers with ransomware (PS News, 2026-07-24). Identity compromise first, then the virtualization control plane, then destruction at the hypervisor layer beneath every guest operating system — the per-VM security stack never gets a vote. Source code for the eTerra, GIS, ePayment and security modules was taken from the agency's GitLab as well. DNSC's account of why it worked is unusually blunt for a national authority — the ANCPI infrastructure had no antivirus installed on the servers running its main applications (go4it.ro, 2026-07-24), alongside known unpatched vulnerabilities and a web-application firewall retaining connection logs for only seven minutes — which is also why the forensic picture is partial. DNSC's director had already assessed on 2026-07-18 that the attack exploited already-known vulnerabilities and could have been prevented (go4it.ro, 2026-07-18).

Triage: in vCenter and ESXi audit telemetry, the discriminating sequence is not any single administrative action but the ordering — an authentication from an unusual source or service account, followed by a full inventory enumeration of virtual machines, followed by power-off or delete operations across guests that share no application grouping. Routine administration enumerates inventory constantly and backup tooling touches many VMs, so volume alone is noise; the signal is enumeration by a principal that does not normally perform it, immediately followed by destructive operations spanning unrelated workloads.

atacatorii au extras aproximativ două milioane de înregistrări privind utilizatori ai platformei de plăți, care conțineau: nume; e-mailuri; identificatori; hash-uri ale parolelor

au compromis serverele de autentificare; au pătruns în VMware vCenter, adică sistemul care administrează întreaga infrastructură virtuală; au enumerat toate cele 1.083 de mașini virtuale; au executat mișcare laterală în rețea; au șters aproximativ 100 de mașini virtuale; au criptat servere ESXi cu ransomware

PS News (relaying the same DNSC report) 2026-07-24

infrastructura ANCPI nu beneficia de un antivirus instalat pe serverele care rulau aplicațiile principale

nu există indicii că baza de date principală Oracle Exadata ar fi fost compromisă

go4it.ro (relaying the DNSC interim technical report) 2026-07-24
incident26 Jul 13:55Zmulti-sourceOpen finding ↗
HIGHCVE-2026-63030 +1exploitedupdateNATOB1

CVE-2026-63030 / CVE-2026-60137 (WP2Shell) — WordPress Core pre-auth RCE chain moves to confirmed in-the-wild exploitation and CISA KEV

UPDATE · originally covered WP2Shell: pre-auth RCE chain in stock WordPress core (CVE-2026-63030 + CVE-2026-60137) — out-of-band 7.0.2 patch, exploitation expected short-term (2026-07-18)

the exploitation status of the WP2Shell chain has flipped. First coverage recorded a public checker, public proof-of-concept code and an NCSC-NL assessment that exploitation was expected shortly, but no confirmed in-the-wild activity. That is no longer the case: "both CVEs were added to CISA's Known Exploited Vulnerabilities (KEV) catalog on July 21" (Rapid7, 2026-07-22). Rapid7 updated its analysis the same day to state that "Given confirmed exploitation in the wild, Rapid7 strongly recommends investigating for signs of compromise" (Rapid7, 2026-07-22). Exploitation was observable earlier than the KEV date: Hexastrike "started seeing exploitation attempts in its honeypots over the weekend, and on Sunday the company said it had already assisted with incident response in several attacks", and watchTowr independently reported in-the-wild attempts (SecurityWeek, 2026-07-20).

Nothing about the vulnerable component, the prerequisites or the patched versions has changed — the affected branches remain 6.9.0–6.9.4 and 7.0.0–7.0.1, fixed in 6.9.5 and 7.0.2 respectively (Rapid7, 2026-07-22). What changes is the defender's posture. A chain that reaches pre-authentication code execution on a stock installation, against a platform this widely deployed across public-sector web estates, and that was being exploited within roughly 48 hours of the out-of-band release, leaves a real window in which an internet-reachable instance could have been taken over before its administrator patched. Patching closes the entry route; it does not remove a webshell, an attacker-created administrator account, or a scheduled task planted beforehand.

Triage: requests to the REST batch endpoint are a legitimate WordPress feature, so their presence alone is not the signal; what distinguishes exploitation from normal use is unauthenticated batch requests arriving from unfamiliar source ranges in tight bursts, immediately followed by a PHP file appearing under the webroot, a new administrator-role user, or an outbound connection from the web-server process. In web-server access telemetry, correlate on the sequence rather than the endpoint. Post-compromise, the higher-signal artefacts are administrator accounts created after 2026-07-17, unexpected entries in the scheduled-event table, and PHP files whose modification time postdates the release but which are not part of the shipped core distribution.

Given confirmed exploitation in the wild, Rapid7 strongly recommends investigating for signs of compromise

Rapid7 2026-07-22

Hexastrike started seeing exploitation attempts in its honeypots over the weekend, and on Sunday the company said it had already assisted with incident response in several attacks.

SecurityWeek 2026-07-20
vulnerability26 Jul 13:52Zmulti-sourceOpen finding ↗
Sources: Rapid7 · SecurityWeek
NOTABLECVE-2026-14499exploitedupdateNATOA1

Langflow correction — 1.10.1 is not the endpoint: CVE-2026-14499 needs 1.10.2, and CVE-2026-0770 has no AUTO_LOGIN precondition

UPDATE · originally covered CVE-2026-0770 — Langflow: CISA confirms active exploitation of an unauthenticated exec_globals RCE the same day a 15-CVE batch (incl. unauthenticated account creation) is patched in 1.10.1 (2026-07-22)

two corrections to that entry, both of which change what a defender does. This entry supersedes its guidance on the points below; the rest of it stands.

The fix line is 1.10.2, not 1.10.1. The earlier entry described the July batch as fixed in Langflow OSS 1.10.1 and its action item advised upgrading to that release. At least one CVE in the same batch is not covered by it: CVE-2026-14499 "could allow an authenticated user to execute arbitrary commands with elevated privileges on the system due to improper validation of user supplied input in the Python Interpreter component", affects "Langflow OSS 1.0.0-1.10.1" at CVSS 8.8, and IBM "strongly recommends addressing the vulnerability now by upgrading Langflow OSS to version 1.10.2" (IBM Security Bulletin, 2026-07-14). Because 1.10.1 is inside the affected range rather than outside it, an estate that acted on the earlier guidance is patched against the rest of the batch and still exposed to this one. The component is the Python Interpreter node, so the exposure is largest wherever Langflow flows are authored or run by more than a small set of trusted operators — an authenticated user is the only prerequisite.

CVE-2026-0770 does not depend on AUTO_LOGIN. The earlier entry recorded that CVE's affected condition as Langflow running with AUTO_LOGIN=true and unchanged default credentials, and recorded no version patch, framing the remediation as disabling AUTO_LOGIN and rotating credentials. The discloser's own per-vulnerability advisory contradicts the precondition: "Authentication is not required to exploit this vulnerability", with the flaw located in the handling of the exec_globals parameter passed to the validate endpoint, scored CVSS 9.8, and no configuration prerequisite stated anywhere in the advisory (Zero Day Initiative, 2026-01-09). ZDI's advisory does say that, at its January publication, "Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the product" (Zero Day Initiative, 2026-01-09) — which is where the "no version patch" line came from, and which reflects the position in January rather than today. So the practical correction is narrower than "the status was wrong": the entry carried a six-month-old mitigation posture as current, when the operative remediation now is the version upgrade that this entry's other correction already requires.

Triage: for CVE-2026-14499 the observable is command execution parented by the Langflow application process — a Python interpreter or shell child spawned from the Langflow server rather than from an operator's terminal. Legitimate use of the Python Interpreter component produces the same shape, which is why the discriminator is the account and the content rather than the lineage alone: executions attributed to a user who does not normally author flows, or occurring outside the hours when flows are edited, are the reviewable set. Version inventory is the higher-signal check here — an instance on 1.10.1 or earlier is affected regardless of what its telemetry shows.

Langflow could allow an authenticated user to execute arbitrary commands with elevated privileges on the system due to improper validation of user supplied input in the Python Interpreter component.

IBM Security Bulletin 2026-07-14

Authentication is not required to exploit this vulnerability.

Zero Day Initiative (Trend Micro) 2026-01-09
vulnerability26 Jul 14:06Zmulti-sourceOpen finding ↗
05Action items5 items
Verification & coverage notes2 runs

2026-07-26T1308Z-audit · audit · Opus 5 · window 193 h · 9 entries published

Audit run — 2026-07-26

Full report: docs/audits/2026-07-26-weekly-quality-audit.md.

Scope and method

Window 2026-07-18T12:08Z → 2026-07-26T13:08Z (~193 h), anchored at the last audit that actually audited — the 2026-07-19 audit record stood down as a duplicate at a 25 h gap and covered nothing. Audited 57 published entries (43 operational, 14 W29 weekly strategic), carrying 10 distinct run ids, across the 11 run records whose start timestamp falls inside the window. Four retrospective truth passes fetched ~181 primary and authority URLs; three coverage re-sweeps re-researched the window independently. July's monthly priority-calibration duty was already discharged by the 2026-07-18 report, so no calibration section appears in this one.

Soundness

32 of 57 entries fully clean. No machine-surface defect survived review. Stating the artifact accurately: three of the four batches recorded machine_surface: false on all 43 of their records, including their 20 non-clean ones; the fourth wrote the field with inverted polarity and is unusable as reported, so the audit reviewed its one non-clean record directly and rejected it, because the entry concerned carries no CVE records at all. Every CVE id and CVSS matched its owning authority, every ATT&CK id checked is active in the pinned v19.1 dataset, every registry key resolves, no indicators leaked. Zero hallucinated facts and zero broken URLs.

Three factual errors. One is defender-consequential and is corrected by a published update this run: the 2026-07-22 Langflow entry advised upgrading to 1.10.1, which leaves CVE-2026-14499 (CVSS 8.8, authenticated command injection) open — the vendor bulletin names 1.10.2 — and it attached an AUTO_LOGIN precondition and a "no version patch" status to CVE-2026-0770 that the discloser's own advisory contradicts. The audit re-verified both legs directly against the vendor bulletin and the discloser's advisory before correcting. The other two are attribution errors in W29 strategic entries where the underlying facts are true.

The other 22 findings are precision defects. The largest single group — 9 of those imprecisions plus 2 of the 3 factual errors, 11 in all — is one class: a true fact cited to a co-cited source that does not carry it. That class is now the dominant residual defect in the pipeline, present in operational entries and the weekly alike, and it survived verification loops of three to eight iterations because those loops confirmed the fact was true rather than that the cited page said it. The remaining 10 split between version-boundary and scope precision (six) and novelty or quote-fidelity precision (four).

The clean rate is lower than the previous audit's, and part of that is measurement rather than regression: three of four passes ran on Opus 5 at maximum scrutiny against a 2:2 split last time, and the adjacency standard applied is stricter than earlier passes enforced. Every batch independently found the same class, which is evidence about the pipeline rather than about one verifier.

No in-place repairs were warranted — nothing in the window touches the narrow metadata class the immutability exception covers. One verifier proposed a machine-surface repair; the audit checked and rejected it, because the entry in question carries no CVE records at all, so nothing propagated to a machine surface.

Completeness

Nine genuine gaps, all recovered and published here through dedup, the mechanical gate and the verification loop.

The most serious: the WordPress WP2Shell chain moved to confirmed in-the-wild exploitation and was added to the CISA catalog on 2026-07-21, and no entry recorded the change — while the store's existing entry says in its own words that there was no confirmed exploitation. The 2026-07-22 fire saw that catalog batch and correctly published a different vulnerability from it, then dropped the WordPress pair on two compounding errors: it applied a rule about foreign-jurisdiction remediation deadlines to the exploitation-confirmation flag, which the same rule defines as operational signal; and it justified the drop by asserting the vulnerabilities were already reported as exploited, which its own prior entry contradicts — a decision made against a remembered entry rather than a re-read one. That fire's own verifier flagged the gap and the drop reasoning overrode it. Both causes are fixed in this run's prompt changes.

Two more were follow-through failures on stories the pipeline was already tracking rather than discovery failures: Romania's national cybersecurity authority published an interim technical report that supersedes the "databases not affected" position the store carried on the ANCPI land-registry attack, confirming roughly two million exfiltrated payment-platform user records and a virtualization-plane intrusion; and the Geneva adult-education institute's stolen data was actually published, including student examination results the institute had said were unaffected. Both are Swiss- or Europe-relevant public-sector stories with an open clock that nothing re-checked.

The rest: a malvertising campaign that hosted its lure page on a vendor's own trusted domain and hit at least 29 organisations; an exposed delivery lab showing industrialised shortcut-and-WebDAV lure testing; a Joomla extension flaw where one anonymous request becomes full administrator on an internet-facing site; the unauthenticated maximum-severity concentration in Oracle's July middleware release that two national authorities escalated; and a government-espionage toolkit whose final implant decrypts only on the target machine.

Seven further items were examined and correctly dropped, each with its reason recorded in the report — a catalog addition over already-exploited ground, a vulnerability needing a non-default configuration, a municipal ransomware case with no attacker-behaviour content to describe, a vendor naming-taxonomy announcement, a strategic assessment belonging to the weekly rather than an intel run, an uncorroborated wave of criminal claims against French government platforms, and a political doxing assembled from older breaches. Two of those became watch items rather than clean drops.

One judgement was reversed during the audit: the government-espionage toolkit was initially set aside as out-of-nexus, then published, because the previous audit recovered a materially identical case and no principled distinction separated them. The reversal is recorded because it is more useful to the next audit than a tidy verdict.

Machinery

Two fixes shipped last week are measurably working. The verifier iteration-cap raise turned the fail-open from the common path into the exception: seven of ten fires since it landed reached a genuine two-model confirmed agreement, and the single waiver in this window was not a cap problem at all. The weekly citation-date duty eliminated its target defect outright — every one of 52 citation dates in the W29 batch matches its source's own publication metadata, against nearly every entry drifting a week earlier. That same fix had a second half about per-fact attribution which did not move at all, and the contrast between the mechanically-checkable half working completely and the judgement-call half not moving is the clearest evidence in this audit for how to fix the dominant defect class: mechanise it, on both the composing and the verifying side. Both are done in this run's prompt changes.

One rule was found dead on arrival. The source list documents promoting a candidate source to active after three contributing runs, but nothing ever counted, and a single fire cannot remember earlier fires — so eleven candidates sat unpromoted, one of them cited by entries from eleven separate runs. Because candidate records are also absent from the digest list the fires build their slices from, a newly added candidate is effectively unreachable, which is why the previous audit's own new source — added specifically to close the discovery gap behind its WP2Shell miss — was never fetched once in eight runs. Fixed at the root: the state digest now computes the count, acting on it is a preflight duty, candidates rotate explicitly, and all eleven are promoted here.

Source health surfaced a concrete instance of reachability not meaning readability: an essential source probes green because the health tool uses a working feed recipe that exists only inside that tool, while the record points at an HTML listing the CDN refuses — so two fires logged failures against a record that looked healthy. The feed is now on the record, and two other recipe corrections ship with it.

The reader pool of last resort was exhausted for four consecutive days and was refilled by the operator about twenty minutes before this audit fired. That outage is the direct cause of one national-CERT source going unreachable mid-window. It is now healthy, but this is the second refill in nine days and each has lasted about five days, which is an operator decision about funding and monitoring rather than something the audit can fix.

Content-safety classifier trips on sub-agent spawns are now a recurring reality rather than a one-off: they cost one fire its entire model rotation, three of four research spawns and its deep-reads, and they cost this audit two spawns for one batch. The existing handling — retry, then fall back and record the exception — is correct and worked both times, so no rule changes; the mitigation that got the batch through is recorded in memory instead, along with the warning not to misread a uniform-model verifier chain as a rotation failure.

Telemetry is otherwise clean. No runaway runs against the three-hour threshold. Publish follow-through complete across all eleven in-window records. Gap-derived windows self-healed across every fire including two off-cadence gaps, with no coverage hole between them. Discipline held or improved: action items sit at 38 empty of 57 entries with none above two, every entry carries a valid reliability rating, empty technique mappings appear only on the two kinds that legitimately allow it, and the high-priority share continued its deflationary trend. The 26-day gap without a critical-priority entry was checked against the window's real exploitation pressure and reflects the bar rather than under-alerting.

Zero-warning sweep

The store-wide check ends 0 warn · 0 fail · 9 acknowledged and the site build emits no self-check warnings. One acknowledgment was added, for the fire whose confirming verification pair ran on the same model because every alternate-model spawn was blocked by the content classifier after a retry: the run recorded that exception as policy requires, both passes were genuine independent confirmations, and the record is immutable. A code change that auto-passed this shape whenever a waiver is present was considered and deliberately rejected — it would let any future run silence the rotation check by writing its own waiver, which is precisely the self-serve exemption the discipline forbids. No acknowledgments were pruned; all nine still silence a live warning.

Notes

  • Recovered entries and their sourcing posture: seven multi-source, two single-source with the value set and a sourcing note naming the situation (the Joomla extension batch, where the discloser is the only publisher and withholds proof-of-concept detail; and the espionage toolkit, whose originating lab is the sole source and labels the post part one of a series).
  • Single-source carve-outs: none of the nine relies on a national-CERT or victim-own-disclosure carve-out.
  • Reduced-confidence inclusions: two entries carry confidence: medium — the Geneva incident (the publication event rests on one Swiss outlet relaying another) and the Joomla batch (no independent corroboration yet).
  • Out-of-window handling: the Oracle release advisory predates the window; the entry anchors on the two in-window national-CERT advisories and records the earlier vendor date explicitly, so it makes no false freshness claim. The corrected Langflow record likewise carries the vendor bulletin's own mid-July date.
  • Borderline drops are enumerated with reasons in the report's completeness section rather than repeated here.
  • Non-update decision, confirmed deliberate (the gate asks for this confirmation, and it is the only warning this run leaves standing): the Joomla recovery shares the tracked extension-wave entity with a W29-preceding weekly synthesis entry, but it ships as a new entry rather than a delta. It is a distinct technical finding — a cookie-forgery authentication bypass reaching full administrator, not the file-upload pattern the tracked wave describes — on a different extension, with six CVE identifiers none of which appear in prior coverage. The prior operational entries in that series cover individual file-upload flaws that this one neither supersedes nor extends, and an intel-class entry never posts a delta against a strategic synthesis entry in any case. The shared entity key is what groups them for the reader at render time, which is the intended mechanism. The warning cannot be cleared without making a wrong update decision, and a run never self-acknowledges its own fresh warnings, so it stays visible with this explanation.
  • Coverage gaps: three research publishers could not be read this run — one blog is JS-rendered and returned no article content on either the bridge or the reader, one feed transport is broken with nothing found by search either, and two feeds are dead but were recovered via their HTML listings. Two further listings need canonical-path updates. None cost a recovery this window; all are logged in the G3 findings file for the next fire's rotation.

2026-07-26T0409Z-intel · Claude Opus 4.8 · window 26 h · 1 entry published

Run record — 2026-07-26T0409Z-intel

Quiet weekend window (Sunday, 2026-07-26 UTC; 26 h coverage, ~24 h gap to the previous 04:09Z fire). Four research sub-agents (S1–S4) swept the full active source surface; S1/S2/S4 returned zero new in-window signal and S3 returned one genuinely-new item. One entry published.

Verification & coverage notes

  • Published (1): GitLab CE/EE RCE via the Jupyter-notebook diff renderer chaining two ~5-year-old Oj Ruby-parser memory-corruption bugs (depthfirst PoC 2026-07-24, The Hacker News 2026-07-25). notable, single-source (see below). Recency: the depthfirst primary is dated 2026-07-24 (~40 h back, just outside the strict 26 h window) but the public PoC drop and press pickup fell on 2026-07-25 (in-window) and the item sits inside the 72 h developing window; not surfaced by any earlier run (verified against the 14-day coverage index — no gitlab/depthfirst/oj match). Carried as a genuinely-new developing story per the developing-window rule.
  • Single-source: 2026-07-26/gitlab-oj-json-parser-rce-notebook-diff-poc — single-origin primary research (depthfirst); The Hacker News re-reports rather than corroborating independently. Held to single-source + confidence: medium accordingly. The claim is backed by a published PoC (GitHub wupco/gitlab-rce-demo) and by the independently verifiable GitLab fixed releases (18.10.8 / 18.11.5 / 19.0.2, bundling Oj 3.17.3); classification C2 (reliability tracks depthfirst's sources.json C rating).
  • CVE handling: the GitLab RCE chain itself carries no CVE (GitLab shipped the Oj bump in its 10 June 2026 releases without a security-fix-table entry). A separate set of nine Oj advisories (CVE-2026-54502 through CVE-2026-54903) came out of the same depthfirst review and cover other Oj APIs (dumper/loader/SAJ/document); they are referenced in prose but not added to cves[] — they are not the RCE chain and the per-CVE type/vector/auth metadata is not established by the single available source. cves[] is therefore empty; no cves_seen.json additions this run.
  • borderline-drop: Deadlock ransomware leak-site claim against Zurich IP-law firm Schaad, Balass, Menzl & Partner AG (S4) — home-region nexus but no victim statement or independent journalism; held under the fake-news guard (leak-site claim requires victim disclosure or A/B corroboration). Logged for a possible follow-up next run.
  • borderline-drop: SwissCybersecurity.net hospital-cybersecurity feature (S2) — surfaced with a fresh-looking date but resolved on verification to recycled 2025-04-04 content; dropped per the recycled-news recency trap.
  • Coverage gaps: cisa-advisories, cisa-directives (bridge 403 + jina pool exhausted — listing pages not enumerable; KEV api + detail-fetch + co-signed-advisory RSS substituted, no in-window miss); major-lab blog listings on RSS-broken hosts — volexity, group-ib, sekoia, mandiant-gtig, trendmicro-research, dragos, nozomi-networks, claroty-team82 (jina fallback exhausted; WebSearch found no in-window item but cannot fully replace the vendor's own current listing); apple-security, chrome-releases (S1 — no in-window release); heise-sec (S2 — jina-pinned body unreachable, no in-window content lost).
  • Watchlist: not reported — the org profile configures no product or supplier watchlists (both sweeps are no-ops).
  • Essential-coverage: all essential-tier sources attempted; the CISA listing-page enumeration gap above is a transport limitation on a weekend with no new CISA publications, mitigated via KEV api + detail-fetch, not an essential-source miss.
  • Operator signal: the jina reader API-key pool has now reported exhausted (HTTP 402/401) on four consecutive daily runs (2026-07-23/24/25/26). This is the standing repair item — top up or rotate the pool; direct/RSS/bridge transports are carrying the load but RSS-broken major-lab hosts are the exposed edge.