Thursday, 20 August 2026

Latvia's vehicle-registration authority lost payment records on two-thirds of the country's population — and the provider contractually watching its infrastructure round the clock did not notice

Latvia's Road Traffic Safety Directorate — CSDD, the state authority for vehicle registration and driver licensing — states that between 8 and 10 August 2026 inclusive an attacker obtained the data held in payment receipts going back to 2008, affecting 1.2 million natural persons and 200,000 legal entities (CERT.LV, 2026-08-18). Latvia's population is a little over 1.8 million, so that is roughly two-thirds of the country (The Record, 2026-08-19). What was taken is the combination that makes downstream fraud convincing rather than generic: personal identity code or company registration number, name, payment amount and date, vehicle licence-plate number, and the address registered at the time of the transaction. CSDD is explicit about what was not taken — customer contact details, meaning phone numbers and email addresses, were unaffected, the recovered address data is incomplete in some cases, and its earlier statement records that customer usernames and passwords were not compromised (CERT.LV, 2026-08-18).

The detection story is the part with a transferable lesson, and it runs the opposite way to the one an outsourcing arrangement is bought to produce. CSDD's own employees found the intrusion and stopped it within several hours; the agency's outsourced IT provider, Tet, did not detect it and did not alert the agency (The Record, 2026-08-19). The agency's chief describes the five-year contract as covering IT infrastructure maintenance and monitoring including some firewall and incident-monitoring functions (The Record, 2026-08-19), and as stipulating round-the-clock monitoring of the infrastructure (inbox.eu, 2026-08-19). Tet's own response is where the gap becomes legible: it says it is too early to draw conclusions about causes, states that its contractual responsibility extends only to certain parts of CSDD's IT infrastructure rather than the agency's whole network, has not disclosed how that scope was drawn, and confirms it engaged two subcontractors to fulfil the contract (inbox.eu, 2026-08-19). Nobody disputes that monitoring was contracted; what nobody had established, before it mattered, was the boundary of what "monitored" covered.

CERT.LV's own assessment is that the attack was targeted and preceded by preparation, and that the attackers showed technical competence; the entry point, per CERT.LV speaking to Latvian public broadcaster LSM, was a vulnerability in a CSDD system exposed to the internet, on which several mandatory cybersecurity requirements had not been met (The Record, 2026-08-19). No CVE, product or vendor has been named. CSDD also disclosed that it faced a further targeted attack the following weekend, which was blocked thanks to the security improvements made in the interim (CERT.LV, 2026-08-18) — a reminder that a disclosed public-sector breach draws follow-on attempts while remediation is still in flight. The institutional consequences have been fast: the supervisory board resigned on the Wednesday morning after calls to do so from the President and a member of parliament, and the agency's chief says he intends to resign once the investigation and its consequences are dealt with (The Record, 2026-08-19).

DOJ's superseding indictment against Iran's Mabna Institute names Switzerland twice — among the countries whose universities were compromised, and among those whose companies had employee mailboxes taken

A 14-count superseding indictment unsealed on 2026-08-18 charges 17 members of the Mabna Institute, an Iran-based company that, in the Department of Justice's words, "since at least 2013, has conducted a coordinated campaign of cyber intrusions into computer systems for 144 U.S.-based universities, 178 foreign universities, at least 42 U.S.-based private sector companies, at least 11 foreign private sector companies, at least five U.S. federal and state government agencies, and at least two non-governmental organizations (NGOs)" (U.S. Department of Justice, 2026-08-18). Nine of the seventeen were previously charged in a seven-count indictment announced in March 2018 (U.S. Department of Justice, 2026-08-18); the new filing adds eight defendants (Nextgov/FCW, 2026-08-19). The institute worked on behalf of the Islamic Revolutionary Guard Corps, and the stolen academic material was resold through operator-run websites.

For a European reader the load-bearing detail is in DOJ's own victim breakdown rather than in the headline. The department names the countries hosting the 178 compromised foreign universities — a list that runs from Australia and Canada through Germany, Ireland, Italy, the Netherlands, Norway, Poland, Spain, Sweden and Switzerland to the United Kingdom — and separately describes "at least approximately 11 foreign companies based in Germany, Italy, Switzerland, Sweden, and the United Kingdom" whose employee email accounts were compromised (U.S. Department of Justice, 2026-08-18). Swiss universities and Swiss companies are, on the government's own account, inside this campaign's victim set. The conduct is historical — the university campaign is dated from around 2013 through at least December 2017 — so this is not notice of a live intrusion; it is a state-directed collection programme against European academic and corporate research being described, with country-level specificity, in a document published this week.

The tradecraft is worth restating precisely because it is so ordinary. Against universities, DOJ describes members of the conspiracy using stolen account credentials to obtain unauthorised access to professor accounts and using that access to steal research and other academic data; one defendant's specific role was tracking the progress of spearphishing campaigns, exchanging credentials for compromised accounts with co-conspirators, building targeting lists, conducting reconnaissance and crafting phishing messages. Against companies and at least two governmental entities, the new charges name a different method: DOJ alleges three defendants "participated in the Mabana Institute's efforts to hack into private sector companies and at least two governmental entities — including through password spray attacks, obtaining unauthorized access to victim systems, and exfiltrating data — causing victims to suffer an excess of $20 million in costs to investigate and remediate the intrusions" (U.S. Department of Justice, 2026-08-18). Nextgov describes the same operating model from the outside: the institute employed or contracted hackers who ran phishing attacks, looked for vulnerable systems and traded credentials for compromised accounts (Nextgov/FCW, 2026-08-19).

Spain's Castilla-La Mancha regional government confirms a cyberattack after the Panzer extortion group lists it — the government confirms the intrusion, not the group's data claims

The regional government of Castilla-La Mancha has confirmed that it suffered a cyberattack, after the extortion group Panzer claimed the intrusion and asserted it had taken around 3 GB of information from the regional administration's systems (Escudo Digital, 2026-08-18). Confirmation came from the region's own directorate-general for telecommunications infrastructure and cybersecurity, and it is carefully bounded: that the attack happened, that all necessary response protocols have been activated, and that the competent authorities and potentially affected individuals have been informed. The administration has not confirmed the volume, the data categories, or anything about how the attackers got in.

That boundary matters, because the claims themselves are unusually sensitive. Panzer says the material includes student and family records, Google Workspace user files, information on pupils with specific educational-support needs, school-census and electoral-process documentation, internal email and administrative documents (Escudo Digital, 2026-08-18). If accurate, that is personal data on minors, including a special-category dataset about children's educational needs. Escudo Digital states the position squarely: what the attackers have circulated must be considered a claim pending verification, and it cannot be taken as established that the data types Panzer names were actually extracted, nor what the definitive compromised volume is. The only date attached to the intrusion comes from the same source and carries its own hedge: Escudo Digital reports that the alleged attack "habría sido observado el 17 de agosto de 2026" — would have been observed on 17 August 2026 — against a target it places in the government and law-enforcement category (Escudo Digital, 2026-08-18). That is a reported observation date, not a confirmed one, and the administration has said nothing about when the intrusion occurred.

Grandoreiro's loader decides it is in a sandbox when it finds seven ordinary desktop shortcuts — an inverted environment check, behind a two-hop DLL sideload

Acronis's Threat Research Unit has published a teardown of a Grandoreiro wave whose loader chain is worth reading even for defenders with no Latin American exposure, because the evasion logic runs opposite to the assumption most sandbox-detection countermeasures are built on. Delivery is an archive carrying a renamed copy of Duplicate Files Finder, a legitimate Windows utility. On execution that binary loads its own genuine dependency, and the genuine dependency in turn attempts to load a further library — and it is that second-hop dependency, carrying the ordinary filename of a MinGW runtime component, which has been replaced with the malicious payload (Acronis TRU, 2026-08-19). The camouflage works because a defender or an endpoint product inspecting loaded modules sees a runtime library name with no obvious reason for suspicion, two hops away from the executable that was actually launched. Acronis notes the compile timestamps disagree — the parent utility carries a 2008 timestamp against the implant's 2026 one — while caveating that PE timestamps are trivially forgeable and are corroboration rather than proof. Because the host utility is a windowed application, the implant's first action is to hide the window it would otherwise show.

The environment gate that follows is staged, and one stage is the interesting one. The loader checks that the machine has been up for at least three minutes, profiles memory, processor count, free disk, screen resolution and recently-opened-document history, looks for virtualization driver files and BIOS registry strings, walks a 49-entry blacklist of debuggers, disassemblers and network-analysis processes, performs an IP-geolocation lookup against a short country blacklist, and compares the username and hostname against known default sandbox identifiers. Sitting inside that sequence is a check that inverts the usual reasoning: the loader looks for desktop shortcuts to seven named mainstream applications — a browser set, a cleanup utility, an FTP client, a PDF reader and a messaging client — and if all seven are present simultaneously, it treats the machine as an analysis environment and stops, on the assessment (Acronis's, at moderate confidence) that this exact software bundle fingerprints a particular automated sandbox image rather than a real user's desktop (Acronis TRU, 2026-08-19). A machine that fails the gate is shown a Spanish-language error dialog instead of the payload. Only a host that passes every stage sees the malware resolve its command-and-control address through a public DNS-over-HTTPS resolver rather than the operating system's own resolver, and fetch its next stage over an HTTP request to TCP port 6432 — behaviour Acronis reconstructed from the binary, because the server was offline when it looked.

The hunting value is in the sequence rather than in any single artefact. Acronis's own leads are a renamed copy of that utility loading the runtime-library name from its own directory, and a graphical process that suppresses its own window and then, within moments of launch, queries a public IP-geolocation service and reads the BIOS description keys out of the registry. Triage: the individual actions are all things ordinary software does — installers read hardware information, updaters check geography, plenty of applications ship MinGW runtimes — so no one of them separates malicious from benign. What does is the ordering and the compression: a windowed application that never draws its window, followed inside a few seconds by hardware profiling, a geolocation call and a BIOS registry read, is not doing what the utility whose name it wears is for. The inverted shortcut check is also a warning about analysis tooling itself: a standard, well-stocked analysis image is exactly the fingerprint this family quits on, so a silent non-execution in a sandbox is a result to interpret rather than a clean verdict.

Builds on: 2026-05-29/watchguard-documents-grandoreiro-s-delphi-dll-side-loading-w

Five US agencies warn of an active threat to Siemens S7 PLCs — AI-written Python tooling built on the standard S7 libraries, dressed as legitimate OT monitoring software

The NSA, CISA, the FBI, the Department of Energy and the Environmental Protection Agency published a joint advisory on 2026-08-19 stating that "This advisory relates to an active threat to Siemens S7 Series programmable logic controllers (PLCs)," and adding a scope caveat that matters more than the headline: "However, ongoing PLC targeting activity is broader than Siemens PLCs. All PLC owners and operators should apply relevant mitigations to reduce the risk to their devices and systems" (BleepingComputer, 2026-08-19). The actively targeted devices are the S7-200, S7-300, S7-400, S7-1200 and S7-1500. The sectors the agencies name as most targeted are critical manufacturing, energy, water and wastewater systems, chemical, food and agriculture, and commercial facilities, and they note S7 controllers are also used in the defence industrial base.

The access path described involves no novel vulnerability. Actors find exposed controllers through internet-scanning services — Censys and ZoomEye are named — and then attack critical and high-severity vulnerabilities, outdated software and weak authentication (BleepingComputer, 2026-08-19). What is new is the tooling and how it presents itself: the advisory reports attackers using artificial intelligence to develop Python exploitation scripts built on the snap7.dll and python-snap7 libraries — the standard open-source means of speaking S7comm to a Siemens controller — and disguising those custom tools as legitimate OT monitoring software. Those tools can provide read and write access to PLC memory, configuration data and ladder-logic programs over S7comm, and the advisory's own behaviour mapping lists conducting read and write operations on data blocks among the actor activity it describes. That combination is the uncomfortable part for a defender: the protocol traffic is the protocol working as designed, the library is the one an integrator would legitimately use, and the process name claims to be a monitoring product.

The agencies' own characterisation of intent is careful and worth carrying precisely: the activity appears focused on persistent reconnaissance, potentially preparing attackers for disruption to critical infrastructure — including data theft, equipment damage, extended downtime or safety incidents (BleepingComputer, 2026-08-19). That is a statement about preparation, not about control-system manipulation having occurred, and an entry that blurred the two would misrepresent what five agencies were willing to say. The recommended actions are correspondingly unglamorous: inventory S7 controllers, install the latest security updates, block internet access to them, strengthen access controls, and monitor for unusual activity targeting these devices.

"Ransom Busters" emails ransomware victims before their incident is public, offering to delete the stolen data for a fee — and the tooling says it is the same affiliate who took it

An entity styling itself Ransom Busters has been emailing organisations in the middle of a ransomware incident, writing to addresses at the victim's own domain and asking to be put in touch with the chief executive or IT leadership (GuidePoint Security, 2026-08-18). It presents itself as a project that assists victims of cyberattacks, claims to have held unauthorised access to criminal groups' servers for more than three years, says it has found the victim's stolen data on one of those servers, and offers to return the files, destroy the attackers' backups and — because it claims access to the operation's key storage — help restore encrypted data. The fee is $20,000 to $60,000 to delete the stolen data from the ransomware group's servers.

The property that separates this from ordinary ambulance-chasing is when it arrives. GuidePoint notes that legitimate recovery-service solicitation generally follows an attack becoming public knowledge; this outreach lands before the incident is publicly known at all, which means the sender knew about an intrusion nobody had disclosed (GuidePoint Security, 2026-08-18). Responding to two of these incidents, GuidePoint's teams found the same set of artefacts in both victim environments: one network-scanning utility used for internal reconnaissance, one cloud-object-storage command-line tool used to move data out to attacker-controlled cloud storage, one remote-monitoring-and-management tool installed through a PowerShell script as a secondary access channel, a locally created backdoor account whose password was identical in both intrusions, and an identical attacker-controlled workstation name appearing in both. GuidePoint weighed and rejected the obvious innocent explanation — a standardised affiliate playbook or a shared virtual-machine image distributed inside one programme — because the same overlap recurred across incidents belonging to different ransomware operations, which makes it a fingerprint of an operator rather than of a programme. On that basis it assesses with moderate confidence that Ransom Busters is a single affiliate employed across several operations, using affiliate-level access to divert ransom negotiations away from the operation it is working for, and states it observed the behaviour while responding to incidents involving DragonForce, Settra and Anubis (GuidePoint Security, 2026-08-18).

A second incident-response firm has seen the same thing independently. Coveware confirmed to BleepingComputer that it responded to at least one incident involving contact from the same group or individual, and its senior director of incident response drew the same distinction — that what makes this different from a routine recovery-service pitch is the approach to a victim whose incident was not yet public (BleepingComputer, 2026-08-19). No victim is reported to have paid Ransom Busters; in one incident the victim paid the underlying ransomware operator instead.

Oracle's August 2026 Critical Security Patch Update carries three unauthenticated CVSS 10.0 flaws — one of them in the LDAP server of Oracle Internet Directory

Oracle published its August 2026 Critical Security Patch Update on 2026-08-18, stating that it "contains 943 new security patches across the product families listed below" (Oracle, 2026-08-18); Switzerland's NCSC put it in front of its own constituency the next day (NCSC-CH, 2026-08-19). This is worth naming precisely, because the release type sets the patch window: a Critical Security Patch Update is Oracle's monthly release — the page states that security patches ship on the third Tuesday of each month and lists 15 September 2026 as the next one — and it is a distinct thing from the quarterly cumulative Critical Patch Update it complements, the next of which is 20 October 2026 (Oracle, 2026-08-18). An estate that treats this as the quarterly cycle will both misjudge how soon the next batch lands and, more importantly, wait a quarter for fixes that are already out. Most of a release this size is still routine maintenance; what takes a handful of items past routine is their own mechanics, and those are not in the families with the largest counts.

Three CVEs in the release carry a CVSS 3.1 base score of 10.0, and in Oracle's own risk matrices all three record Privileges Required as None, User Interaction as None, and Scope as Changed — an anonymous, single-request path to full compromise of the component and beyond it. CVE-2026-61241 is in the OID LDAP Server component of Oracle Internet Directory, reachable over LDAP, affecting versions 12.2.1.4.0 and 14.1.2.1.0. The other two, CVE-2026-70880 and CVE-2026-70921, are in the Access and security component of Hyperion Data Relationship Management (reachable over TCP) and the Security component of Hyperion Financial Management (reachable over TLS), both at 11.2.25.0.000 (Oracle, 2026-08-18). The Internet Directory flaw is the one that should move first in a public-sector estate: an LDAP directory server is identity infrastructure, it is normally reachable from every application that authenticates against it, and a scope-changed compromise of it is not contained to the directory.

The concentration behind those three is what makes the sequencing work non-trivial. Oracle records 262 new patches for Fusion Middleware, of which it states 182 "may be remotely exploitable without authentication", and 120 for E-Business Suite, of which 27 may be; Hyperion carries 262 patches with 107 in that category (Oracle, 2026-08-18). Within E-Business Suite the two highest-scored unauthenticated flaws sit on inbound processing paths that an internet-facing deployment exposes by design — CVE-2026-60782 in the File Transmission component of Oracle Payments over HTTP, and CVE-2026-70926 in the Workflow Notification Mailer over SMTP, both 9.8. In Fusion Middleware, CVE-2026-60672 is an unauthenticated 9.8 in the WebLogic Server core reachable over T3 and IIOP, a protocol pair with a long history of public exploit work following Oracle releases.

No source fetched this run reports exploitation of any individual flaw in this cycle, and NCSC-CH's relay records exploitation status as unknown for the batch as a whole (NCSC-CH, 2026-08-19). Oracle's own advisory makes the point that matters more than any single score: it "continues to periodically receive reports of attempts to maliciously exploit vulnerabilities for which Oracle has already released security patches. In some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches" (Oracle, 2026-08-18). For estates that cannot patch 943 items at once, the useful hardening step in the meantime is network placement rather than version: T3, IIOP, RMI, CORBA and LDAP listeners on middleware and directory hosts have no business being reachable from a general-purpose user network, and restricting them removes the reachability half of every unauthenticated flaw in this release regardless of which one is patched first.

CVE-2026-73570 — Zimbra Collaboration: a pre-auth command injection patched without a CVE in July is now recorded as actively exploited, four weeks after the fix shipped

Zimbra's own security-advisory table records the fix for CVE-2026-73570 as "Fixed a command injection vulnerability in the SNMP monitoring component when SNMP notifications are enabled", shipped in release 10.1.20 (Zimbra, 2026-08-13). That release went out on 21 July 2026 carrying nine fixes, and at the time none of them had been flagged as actively exploited; the vendor's stated position was that "in line with industry best practices, information disclosure is limited for security vulnerability fixes" (The Hacker News, 2026-07-21). The identifier arrived nearly four weeks later, on 13 August, and the ENISA record describes the mechanism in full: because untrusted input is not properly sanitised during SNMP notification processing, "an unauthenticated attacker can send specially crafted SMTP requests that may result in execution of arbitrary operating system commands as the Zimbra user" (ENISA EU Vulnerability Database, 2026-08-13). ENISA scores it 8.9 with high attack complexity (ENISA EU Vulnerability Database, 2026-08-13), and the flaw applies only to deployments where the optional zimbra-snmp package is installed and SNMP notifications are enabled.

On 19 August CERT-FR issued its own advisory for the Zimbra bulletin and stated plainly that ENISA records CVE-2026-73570 as actively exploited (CERT-FR, 2026-08-19). ENISA's record dates that exploitation from 18 August (ENISA EU Vulnerability Database, 2026-08-13). What makes this worth an out-of-band look rather than a place in the next patch window is the sequence rather than the score: the code was fixed in July with no identifier attached, so an estate that drives its patching from CVE feeds, scanner signatures or an SBOM pipeline had nothing to match against for four weeks, and the flaw only became visible to those processes five days before it was recorded as exploited. Anyone who upgraded to 10.1.20 in July for unrelated reasons is already covered and does not know it; anyone who deferred is now unpatched against a flaw with a published exploitation status.

The behaviour to look for follows from the mechanism. Command injection at the point where a notification is formatted means the observable is a mail-server process tree spawning something it has no business spawning: an interpreter or utility process whose parent is the Zimbra mail or notification component, running under the zimbra service account rather than under a scheduled administrative task. In process-execution telemetry with parent lineage, that lineage is the signal — SNMP notification handling legitimately produces notification traffic, not shells. On the network side, an outbound connection initiated by the zimbra account immediately after inbound SMTP is the same event viewed from the other end. Triage: Zimbra hosts do legitimately run monitoring integrations under the same account, so process identity alone will not separate them; the discriminators are the parent process being the notification path rather than a cron or monitoring agent, and the absence of a matching operator change record for a host that has no history of spawning interpreters at all.

CVE-2026-19490 — Citrix NetScaler: an authentication bypass on Gateway and AAA virtual servers (CVSS 9.3), and on older builds no SAML configuration is needed to be exposed

Citrix published a security bulletin on 2026-08-19 covering two vulnerabilities in NetScaler ADC and NetScaler Gateway, and CERT-EU issued its own advisory for its constituency the same day, recommending that affected devices be updated as soon as possible (CERT-EU, 2026-08-19). The more serious of the two, CVE-2026-19490, is described as an authentication bypass using an alternate path and scored 9.3 (CERT-EU, 2026-08-19) — a CVSS v4.0 base score, per Rapid7's analysis of the same advisory (Rapid7, 2026-08-19). It applies where the appliance is configured as a Gateway — SSL VPN, ICA Proxy, CVPN or RDP Proxy — or as an AAA virtual server, which is the configuration that fronts remote access and authentication brokering for the network behind it.

The part that decides how much of an estate is exposed is version-dependent, and it cuts the wrong way for anyone behind on builds: on 14.1-43.56 or later and 13.1-61.28 or later the flaw applies only when a SAML action is configured, but on earlier builds and on 13.1 FIPS, a Gateway or AAA virtual server configuration is sufficient on its own (CERT-EU, 2026-08-19). An operator who checks only for SAML and concludes they are unaffected will be wrong on exactly the appliances that are furthest behind. The second flaw, CVE-2026-19489, is a memory overflow that can lead to unpredictable behaviour or denial of service, and it is reachable only where SIP ALG is enabled inside a Large Scale NAT group configuration (CERT-EU, 2026-08-19).

Detection here is thin by nature — an authentication bypass on an appliance leaves no failed-credential trail, because the point of it is that the credential step does not happen. The telemetry class that carries signal is the authentication and session record on the Gateway or AAA virtual server itself: a session established for a user identity with no preceding credential-validation or SAML assertion-processing event for that same session, and session establishment from addresses or client profiles that do not match the population that normally reaches the appliance. Because CVE-2026-19489 manifests as unpredictable behaviour or a service failure rather than as a login, an unexplained NetScaler restart or packet-engine fault on an appliance carrying an LSN group with SIP ALG belongs in the same review rather than in capacity triage. Fixed builds are 14.1-73.32, 13.1-63.21, 14.1-73.32 FIPS and 13.1-37.277 (Rapid7, 2026-08-19); where CVE-2026-19489 cannot be patched immediately, SIP ALG on LSN groups that do not need it is a configuration that can simply be turned off.

Builds on: 2026-08-15/netscaler-saml-signedinfo-overflow-preauth-root-rce-not-dos

CVE-2026-64849 — MLflow: the SSRF guard resolves the webhook host and then throws the answer away, so one redirect turns an unauthenticated tracking server into a reader of its own cloud credentials

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog on 2026-08-19, with a remediation date of 2026-09-02, describing a server-side request forgery in MLflow "that can allow attackers to reach internal or cloud metadata services and receive response_status and response_body" (CISA Known Exploited Vulnerabilities catalog, version 2026.08.19). The remediation date is a US federal compliance clock and carries no weight here; the listing itself is what matters, because it is a government determination that this is being used against real deployments rather than a theoretical severity rating.

The mechanism is a guard that does its work and then discards the result. On a default MLflow tracking server — started with mlflow server, no authentication, the default SQLite backend — the model-registry webhooks API is reachable without credentials, and it includes a synchronous test endpoint that returns the upstream response status and body to whoever called it; the only webhook authorisation MLflow ships lives in an optional auth plugin that is not loaded by default (GitHub Security Advisory GHSA-7gwp-5pfp-969j, 2026-08-17). When a webhook is registered, the URL validator resolves the hostname and rejects any address that is not globally routable, which blocks the naive attempt to point a webhook at loopback or a metadata address. But, as the advisory puts it, "The resolved IP is never carried into the connection" (GHSA-7gwp-5pfp-969j, 2026-08-17) — delivery re-resolves the hostname independently and follows HTTP redirects without re-validating the redirect target. An attacker registers a webhook pointing at a public HTTPS host they control, which passes validation, and then fires the unauthenticated test endpoint; the host answers with a redirect to an internal or instance-metadata address, MLflow follows it, and the response body comes back in the test result. The same missing re-validation yields a second primitive: redirect status codes that preserve the method and body turn the same path into a blind write against internal management endpoints that act on POST. Neither requires authentication on a default open-source server, and the researcher confirmed the read primitive live against MLflow 3.13.0.

Detection sits in egress rather than on the application. The observable is the tracking-server host making outbound connections to link-local or private-range destinations — above all the cloud instance-metadata address — with the request originating from the MLflow process itself, and in web-access telemetry the preceding pair of unauthenticated requests that create a webhook and then call its test endpoint. Triage: a legitimate webhook target is operator-configured, stable, and resolves to the same external service every time; the discriminators are a webhook registered and tested within seconds of each other by an unauthenticated caller, and a delivery attempt whose final destination is inside the network the server sits in rather than the host that was registered. Neither is a normal shape for a notification integration.