CVEasy Weekly

This Week in Exposure

Week 35 · 2026-W35 · August 18 to August 24, 2026

This week's four exposures share one shape. Each lived in a piece of machinery the system was built to trust. GitLab trusted a compatibility hint on its own GraphQL fields, MLflow trusted its own SSRF allowlist, vCenter trusted a path inside a syslog write, and one victim trusted the code that validates its MFA codes.

In every case the trusted component was the attack surface, and the base score graded the bug in the abstract while the real risk sat on the internet-facing instance, the exposed tracking server, or the portal an operator had already edited. Here is the week, ranked by exposure against your inventory rather than by the base score.

Top Exposures This Week

1. A GitLab compatibility hint that hands over any public repo

CVE-2026-19478 · GitLab self-managed, Community and Enterprise through 19.2.3 · CWE-94, CVSS 9.4

GitLab ships the @gl_introduced directive as a rolling-upgrade compatibility hint, telling an out-of-date instance to resolve a newer GraphQL field to null instead of failing the whole query. The fallback that does this stopped consulting the schema whitelist. A single unauthenticated POST to /api/graphql, carrying an ordinary document with one field marked @gl_introduced(version: "99.0"), makes the executor call that field name as a method directly on the server-side Ruby object behind the node. Point it at a real method on the Project model and the executor runs it. No login, no session.

Risk read: Confirmed in the wild. GitLab shipped an out-of-band patch on Sunday, August 17, off its normal twice-monthly cadence. watchTowr reproduced the bug from the advisory and patch diff within minutes, and by August 20 Help Net Security and The Hacker News were tracking active exploitation against internet-facing self-managed instances. Exposure splits the fleet: an internet-facing instance still on 19.2.3 hosting public projects sits at ACT, the top TRIS band, while a segmented, proxy-fronted, patched instance sits far lower at the same CVSS. The blast radius is the repository itself, because the synthesized field reaches model methods, so the payload runs past the authorization the resolver would normally enforce and into project deletion and data disclosure.

Read how one directive removes the whitelist →

2. An MLflow test endpoint that reads back your cloud credentials

CVE-2026-64849 · MLflow before 3.15.0, /api/2.0/mlflow/webhooks/{id}/test · CVSS 9.3 · CISA KEV since August 19

Every MLflow before 3.15.0 ships the webhook test endpoint with no auth. The SSRF guard added in 3.10.0 validates the URL you send, but delivery runs on a fresh session that resolves DNS again and follows redirects, and the redirect handler only re-checks the original URL. A 302 to http://169.254.169.254 rides straight through: MLflow follows it into the cloud metadata service, reads the attached IAM role, and hands the credential blob back in the /test response. A 307 preserves the POST and turns the same primitive into a blind write against internal HTTP APIs, and DNS rebinding gets the read case with no redirect at all.

Risk read: Confirmed in the wild. watchTowr's Attacker Eye honeypots watched an unauthenticated POST, a redirect chain, and a plain-text IAM credential blob arrive within hours of the August 17 assignment, and CISA added it to KEV on August 19. Exposure is the whole finding: a tracking server on a public IP with a cloud role and IMDSv1 sits at ACT, while a stack with IMDSv2 enforced, no cross-account trust, and MLflow behind an access proxy sits far lower. The blast radius is every credential the stolen role can reach across AWS, GCP, or Azure, which is why the fix is an upgrade plus a rotation, because a credential read before you patched outlives the patch.

Read the redirect chain into the metadata service →

3. A vCenter syslog write that turns into root on 361 appliances

CVE-2026-59310 · VMware vCenter Server Appliance, Syslog Server · CVSS 9.8 · fixed July 29 in VMSA-2026-0006

The Syslog Server inside the vCenter appliance accepts a payload with a path element and never checks that it stays inside its working directory. An unauthenticated attacker sends a crafted HTTP request with ../../ sequences and writes a small ELF payload into a directory the appliance cron scheduler watches. Minutes later cron runs it as root. The implant is the Go build of reverse_ssh, which dials outbound to attacker infrastructure over 443, clearing egress rules that block inbound 22 but let 443 out.

Risk read: Confirmed in the wild, and at scale. Broadcom shipped the fix on July 29, and between August 3 and August 5 Quirso watched roughly 343 appliances start speaking to the same reverse SSH relay, a count Infosecurity Magazine and Bleeping Computer put at 361 victims across 47 countries, with Germany, the United States, Turkey, Iran, and France carrying most of the load. On a subset of hosts the actor renamed ESXi log files with a .babyk extension, which The Hacker News reads as a smokescreen to burn timeline evidence rather than a genuine ransomware payout. Exposure caught the appliances reachable from a segment nobody had modeled as internet adjacent. The write runs under the vCenter service account, which on the appliance can plant persistence in a dozen directories, so patching after August 3 is a hunt job, because cron entries, planted keys, and reverse SSH binaries do not remove themselves when you install the update.

Read the write-to-root chain and hunt notes →

4. Gunra edited an MFA validator so one code always works

CVE-2024-55591 and CVE-2025-24472 · Fortinet FortiOS and FortiProxy · joint advisory AA26-222A, August 10

Gunra affiliates took the Fortinet appliance in front of a corporate VDI portal with an authentication bypass, or in one case with default credentials on an exposed SSL-VPN box, then edited the files that validate one-time passwords. Real time-based codes still work, and beside them the validator now accepts one constant the operators chose. MFA stayed switched on and kept reporting itself enforced. The identity provider logs a successful second factor because one was returned, the authenticator app never fires because no push was requested, and no event shows MFA disabled, because nothing was.

Risk read: Confirmed in the wild, per CISA advisory AA26-222A, published August 10. This is MITRE ATT&CK T1556.006, but aimed at application code on an on-premises portal rather than the identity provider configuration that documented cases usually target, so a SOC watching for MFA fatigue sees a clean quarter while an operator signs in nightly. Exposure ranks the internet-facing FortiGate fronting a VDI portal at ACT this week, while the same version on a segmented appliance sits several bands lower. One upgrade closes both flaws, FortiOS to 7.0.17 or later and FortiProxy to 7.0.20 or 7.2.13 or later, but the patch does not revert an already-edited validator, so a compromised portal needs its authentication files restored from a known-good build and its secrets rotated.

Read the validator backdoor and hunting queries →

Threat Actor Spotlight

Gunra ties directly to this week's Fortinet finding. CISA and partners published joint advisory AA26-222A on August 10 describing Gunra as a financially motivated ransomware-as-a-service crew built on the leaked Conti source, first observed in April 2025, running double extortion against healthcare, financial services, government, and utilities across four continents. The FBI has observed a rebrand under the alias Golden Community, and no MITRE ATT&CK group ID has been assigned yet, so track the crew by technique. The technique that matters here turns on an assumption almost nobody monitors: every MFA deployment has one place where a server recomputes the expected code and returns a boolean, and that comparison is trusted absolutely because it runs on hardware you own. Hardening takeaway: put file integrity monitoring on the authentication code paths of your VPN, VDI, and portal appliances, alert on any change to them outside a vendor update, and read a clean MFA log on an appliance you cannot verify as unproven rather than safe.

Signed CVEasy threat-intel IOC bundle current as of 2026-08-24. The desktop app verifies the ED25519 signature before import.

The pattern repeats because trusted machinery is where nobody looks. A compatibility hint, an SSRF allowlist, a syslog path, an MFA validator, each was audited once, shipped, and then treated as settled. The work is to keep scoring every finding against your own inventory, which internet-facing instance runs the flaw, which role the stolen credential can assume, which portal an operator may already have edited. That is the gap TRIS closes inside our CTEM platform, the gap I want this letter to close for you every Monday.

Patch well,
Chris Boker
Founder, CVEasy AI