AI Agent Intrusion Campaign in Asia: 48 Targets, IOCs and Defence

A report from VULONE, dated 18 October 2026, says one China-linked, Chinese-speaking operator used AI agents to run 66 intrusion projects across Asia between 24 September and 14 October, and that 48 reached some level of access. Targets included government bodies in Vietnam, Taiwan, Indonesia and India. Check for the published indicators, change default logins and retire old software now.

This post covers what the report says and what it does not, how the AI agents were used at a high level, every indicator VULONE published, an ATT&CK mapping, step by step detection and remediation commands for each platform involved, and what would have helped. It goes deeper than our earlier pieces on the same trend: CERT-In's advisory on AI agent attack vectors and what AI-found bugs like PHP2Shell and PwnEscape mean for defenders.

One point first, because headlines have blurred it. The figure of 48 is the operator's own tally, recorded by the operator's tooling. VULONE says it checked the strongest cases against exfiltration logs and listener captures where they survived, and that victim side verification is still pending. None of the named organisations had publicly confirmed a compromise in the sources we read.

What the report says

VULONE's Research Team published "China-Linked Hackers Targeted Governments Across Asia. We Hacked Their Infrastructure." The byline is dated 18 October 2026 and the blog listing shows 19 October. SecurityOnline covered it on 22 October under a headline describing 48 government and corporate targets.

The story starts with a tip from the researcher @TheM3gatr0n on X, according to VULONE. A Python web server on 202.61.139.15 was serving the host's /tmp directory on port 9000 with no authentication. VULONE says that server started at 22:13 UTC on 29 September 2026, and the same listing was mirrored on 202.61.139.137. The directory held 339 files and, by VULONE's count, received more than 753,000 requests from 19,307 unique IP addresses while it was exposed. In other words, a lot of people besides the researchers saw it.

VULONE then went further than the open directory. It says it accessed the host and collected evidence under authorization, and it does not disclose how it got in, arguing there is no reason to publish the way in. It preserved logs before further interaction, hashed and timestamped its archives, and handled the material as if it might be used in court. It collected a targeted subset of 16.4 GB rather than a full disk image.

The numbers, as VULONE gives them

The 54 missing project IDs matter. VULONE does not say what they were. They may be deleted tests, or they may be targets whose records are gone. Treat 66 as a floor for the operator's activity, not a ceiling.

Attribution, in VULONE's own terms

VULONE separates two judgements, and it is worth keeping them apart.

• On the infrastructure: VULONE says, "We assess with high confidence" that the command and control infrastructure belonged to a single operator or a very small group.
• On who that operator is: VULONE describes the operator as China-linked, Chinese-speaking and financially motivated. It says the artifacts it examined showed no sign of state sponsorship, while noting that state interest cannot be excluded from the outside.

The language clues, according to SecurityOnline's summary, include Simplified Chinese in script comments, task hints and commit messages, and partial funding through a Tencent-operated AI service. VULONE itself warns that language indicators can be manufactured. The operator's own rules required every payload and file written to a victim to be English or ASCII, with Chinese comments forbidden, so victim side evidence would not carry those clues anyway.

The operator's physical location is unknown. VULONE flags one anomaly: on 5 October a mobile connection in Kenya fetched scripts from the exposed directory.

Countries, sectors and named targets

VULONE names targets in four countries in Asia, plus some companies elsewhere. The table lists the government targets as the report does. Every row is a claim from the operator's records, not a confirmed breach.

On the corporate side, VULONE lists payments and fintech, airlines and travel, retail and ecommerce, hosting, SaaS, telecom and messaging, and security software. VULONE also describes administrator level access to a multi-brand retail estate through an ecommerce platform's REST API, which needed no shell at all, and a cargo system reached through unauthenticated Java deserialization. We are not naming the organisations; the claims come from the operator's own records, are unverified, and the lesson is the same for every one of them.

VULONE says it found no evidence of bulk payment card theft or destructive activity in the artifacts it reviewed, and is careful to say that statement covers only that evidence set.

Timeline

Times are given only where VULONE published them. Everything else is a date.

How the AI agents were used

This section stays at the level of architecture and operating choices. It does not describe how any target was exploited.

The platform: Cairn

VULONE says the operator built the platform on Cairn, an open source framework. Cairn's own README describes it as a general purpose AI state space search engine: give it a starting point and a goal, and its workers search for a path. Penetration testing is the first domain its authors validated. It uses a blackboard design with three shared primitives, which the README calls Facts (confirmed findings), Intents (planned explorations) and Hints (human guidance). Worker agents coordinate only through that board. A dispatcher schedules tasks and manages worker containers, and the supported LLM backends are Claude Code, Codex and Pi. The project is licensed AGPL-3.0 and its README says to use it only where you have explicit authorization.

VULONE is explicit that using a public tool does not identify its author, and says it found nothing connecting Cairn's maintainers to this operator. Cairn has a public container image and several hundred forks, per VULONE.

How this operator ran it

According to VULONE:

1. One dispatcher, many short lived workers. A dispatcher on the VPS scheduled up to 116 Kali Linux based worker containers using host networking, with dozens active at once.
2. One model behind a local gateway. Workers sent their reasoning through a single local LLM gateway to a model identified as global:deepseek-v4.1-flash. Two other identifiers appeared in provider traffic: cline-pass/deepseek-v4.1-flash and deepseek/deepseek-v4.1-flash.
3. State in one database. Project state lived in a single SQLite database, and completed work was archived to disk.
4. A farmed account pool. Six monthly LLM subscription accounts were registered together in late September; at least one was in arrears by $147.48 when collected. A scheduled task signed in 16 Gmail-based CodeBuddy identities every day to collect about 30 free credits each, roughly 480 a day. The operator held fallback credentials for at least two other LLM services. The account pool software was third party open source, adapted by the operator.
5. A human setting goals. VULONE describes the operator directing agents with objectives and constraints while the agents did most of the enumeration, exploitation and post-exploitation collection. It says plainly that this was not fully autonomous.

The operator's rules

VULONE quotes or paraphrases rules the operator gave the agents. Defenders should read them as a list of things the attacker was trying to hide from you.

• A project only counts as complete at a webshell or system command execution.
• Commands go through POST requests only, to reduce what shows in logs.
• Clean up evidence directories.
• Write everything placed on a victim in English or ASCII; no Chinese comments.

The POST-only rule is the most useful for defenders. Many web servers log the request line and status for POST requests but not the body, and many teams only alert on unusual GET parameters. An agent that sends every command in a POST body to a script file is quiet in those logs unless you watch for new script files and unusual POST targets.

Where the access came from

The striking part of the report is how old and ordinary most of the entry points were. VULONE lists, among others:

• Shellshock (CVE-2014-6271) reached through a mail gateway on a RHEL5-era system, giving execution as a mail service user.
• JBoss Seam expression language injection (CVE-2010-1871), a 2010 flaw that was still exploitable on one government site.
• Default admin/admin credentials on a WSO2 API Manager console.
• Anonymous FTP with write access, followed by SQL Server's xp_cmdshell.
• ASP.NET ViewState deserialization leading to a webshell.
• An ecommerce platform chain from file read to root, a PHP logging library object injection, and a Ruby job queue eval injection.
• An unauthenticated role check bypass with arbitrary file write, PL/SQL injection, SSRF chains, and a V8 issue in a Lambda based card renderer.
• Credential reuse on a shared multi-brand platform, where one credential exposed every brand.
• A root reverse shell on a Redis pod, set up by cron.

VULONE adds that against well-patched targets the operator's own notes logged shell-oriented attempts as failures, and that the operator then fell back to credentials. Its line on the volume of attempts is worth remembering: the persistence reflects machine patience, not human persistence.

What this tells us

The agents did not need new vulnerabilities. They needed a list of old ones and the patience to try them everywhere, at the cost of free credits and a cheap model. The AI did the tedious middle of the job; the human chose targets and set rules. Gambit reported a similar pattern in the separate SOUL campaign, where, according to The Next Web, access, when achieved, "usually took less than a day." And the AI raised throughput, not discipline: an open directory with no password exposed the whole platform for over two weeks.

Technical details

All values below are as published by VULONE in its report. IP addresses are defanged with [.] so they do not become links; remove the brackets before loading them into a tool. VULONE says it did not publish hashes for the 339 files in the exposed directory; that manifest is held with its case record. The only hash it published is the TLS certificate fingerprint.

Network infrastructure

Operator-side addresses

VULONE lists these as addresses used on the operator's side. Several are cloud and mobile ranges that also carry legitimate traffic, so treat a hit as a lead to investigate, not proof.

TLS certificate

Operator SSH key

VULONE published the operator's public key. Finding it in any authorized_keys file on your systems would be a strong signal.

Client strings, user agents and banners

The pi user agents line up with Pi, one of the three worker backends Cairn's README lists. The model identifiers are mostly useful to AI providers and to teams that run their own LLM gateways, not to a typical web server log.

File names

VULONE names these scripts and archives from the operator's toolkit. It does not publish hashes for them. A file with one of these names on your server is worth a look; the absence of a match proves nothing, because names are easy to change.

CVEs named in the report

VULONE does not give CVE numbers for the other techniques it lists, such as the ecommerce chain or the PHP logging library injection. We are not guessing them. If you run those platforms, check your vendor's bulletins for your exact version.

ATT&CK mapping

VULONE does not publish ATT&CK technique IDs. SecurityOnline added a short mapping of its own. The table below is our mapping of the behaviours VULONE describes; it is an aid for hunting, not part of the report.

MITRE's page for T1078.001 lists two mitigations that apply directly to the WSO2 case: change default usernames and passwords before production (M1027) and require MFA on default accounts where possible (M1032).

Related but separate campaigns

Three other reports describe AI agents in intrusions in 2026. VULONE asks defenders not to merge them, and we agree.

The Next Web reports that in the Gambit case Cairn ran on DeepSeek V4.1 Flash, the same model family VULONE saw here. That is a tooling overlap. It is not evidence of one actor. Hunt for each set of indicators on its own.

Detection: step by step

Work through these in order. Each step says what to look for and how to check it. Replace example paths with your own. All of these are read-only.

1. Network logs: the two primary addresses

Search firewall, proxy, NetFlow and DNS logs for any traffic to or from 202.61.139.15 and 202.61.139.137 since 24 September 2026, and for the listener ports VULONE lists.

# Linux web or proxy server: search access logs for the two addresses
grep -E '202\.61\.139\.(15|137)' /var/log/nginx/*.log /var/log/httpd/*log* 2>/dev/null

# Zeek: outbound connections to the addresses or exfiltration ports
zcat /opt/zeek/logs/2026-*/conn.*.log.gz | \
  zeek-cut ts id.orig_h id.resp_h id.resp_p | \
  awk '$3 ~ /^202\.61\.139\.(15|137)$/ || $4 ~ /^(4445|4446|8896|8899|8997|9099|9201|9955)$/'

On Windows, the firewall log is a quick first pass if logging is on.

Select-String -Path "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log" `
  -Pattern '202\.61\.139\.(15|137)'

2. Outbound PUT requests to an /ev/ path

VULONE says exfiltration used PUT /ev/ to high ports on the C2 host. If your egress proxy logs method and path, search for that pattern to any destination, not just the known addresses.

grep -E '"PUT [^ ]*/ev/' /var/log/squid/access.log* 2>/dev/null

3. The TLS certificate

If you record TLS certificate details at the edge (Zeek x509.log, a proxy, or an NDR tool), search for the serial or the fingerprint.

zcat /opt/zeek/logs/2026-*/x509.*.log.gz | \
  grep -i '0CE6C93BC4B91DE00956D73B1D3DF1211B2409D3'

4. The operator's SSH key on your hosts

This is the most direct host check. Run it on every Linux host and container base you can reach, including root.

sudo grep -rF 'AAAAC3NzaC1lZDI1NTE5AAAAIKo+sIL3HUlVhjn6PDSGak' \
  /root/.ssh /home/*/.ssh /etc/ssh 2>/dev/null
sudo grep -rF 'us@us-VMware-Virtual-Platform' /root/.ssh /home/*/.ssh 2>/dev/null

5. User agents and client strings in web logs

grep -E 'pi \((win32|linux) |Cairn/1\.0|ccswitch' /var/log/nginx/access.log* /var/log/httpd/access_log* 2>/dev/null

For IIS, the default W3C logs live under %SystemDrive%\inetpub\logs\LogFiles.

Get-ChildItem 'C:\inetpub\logs\LogFiles' -Recurse -Filter *.log |
  Select-String -Pattern 'Cairn/1\.0|ccswitch|pi\+\((win32|linux)'

IIS writes spaces in the user agent field as +, which is why the pattern differs.

6. New script files in web roots

Because commands went through POST to webshells, the file itself is often the best evidence. List script files created or changed since the campaign began.

# Linux: PHP, JSP and similar files changed since 24 September 2026
sudo find /var/www /srv /opt -type f \
  \( -name '*.php' -o -name '*.jsp' -o -name '*.jspx' -o -name '*.aspx' \) \
  -newermt '2026-09-24' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort

# Windows/IIS: .aspx, .ashx and .asmx files written since 24 September 2026
Get-ChildItem 'C:\inetpub' -Recurse -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date '2026-09-24') } |
  Select-Object LastWriteTime, FullName | Sort-Object LastWriteTime

Then look at POST requests to any file that appears in that list. A script that only ever receives POSTs from one or two addresses deserves attention.

7. Volume patterns

VULONE describes machine patience: very large numbers of attempts, sustained over days. Look for a single source, or a small set of cloud addresses, making thousands of requests across many distinct paths and returning mostly errors, then suddenly a run of successful POSTs to one file. That shape fits automated agents better than any single string does.

8. Do not attribute on language

VULONE's advice here is specific. The operator required English and ASCII on victims, so the absence of Chinese strings tells you nothing. Do not rule a host in or out on language.

Remediation: step by step for each platform

These steps follow the entry points VULONE lists. Each is a configuration or patch task, not a response to a specific victim.

Admin consoles with default credentials (WSO2 and others)

1. List every admin console reachable from the internet: API managers, application servers, file managers, database admin tools.
2. For WSO2 products, check the super admin account settings in your configuration (in recent API Manager releases, the [super_admin] block in repository/conf/deployment.toml) and confirm the password is not a default. Follow WSO2's documentation for changing it on your version.
3. Put consoles behind VPN or an allowlist. A console that must be reachable needs MFA.
4. Rotate any API tokens and client secrets issued by that console.

# Find WSO2 config files and show the super admin block for review
sudo find / -name deployment.toml -path '*repository/conf*' 2>/dev/null | \
  xargs -I{} sh -c 'echo "== {}"; grep -A4 "^\[super_admin\]" "{}"'

Bash and old mail gateways

1. Check the installed bash version on every Linux host and image, including appliances you rarely log in to.
2. RHEL5-era systems are long out of support. Plan to retire them; until then, put them behind a filtering relay and limit who can reach them.

bash --version | head -1
rpm -q bash 2>/dev/null || dpkg -l bash 2>/dev/null | tail -1
cat /etc/redhat-release /etc/os-release 2>/dev/null | head -3

For containers, check the image rather than a running shell:

docker run --rm --entrypoint bash my-image:tag --version | head -1

JBoss Seam and other end of life Java stacks

1. Search for Seam and old JBoss jars across servers and build outputs.
2. Upgrade, or retire and isolate. A 2010 flaw that is still exploitable means the whole stack is unmaintained.

sudo find / -type f \( -name 'jboss-seam*.jar' -o -name 'jboss-seam*.ear' \) 2>/dev/null
# Maven projects
mvn -q dependency:tree | grep -i seam

SQL Server: xp_cmdshell

Microsoft's documentation says xp_cmdshell is disabled by default on new installations, that new code should not use it, and that if it must be used it should be enabled only for the task that needs it.

-- Check the current setting (1 = enabled)
SELECT name, value_in_use FROM sys.configurations WHERE name = 'xp_cmdshell';

If it is enabled and you do not need it, disable it with sp_configure and RECONFIGURE as Microsoft's page shows, setting the value to 0. Then check which logins hold sysadmin, because those can turn it back on.

SELECT p.name FROM sys.server_role_members m
JOIN sys.server_principals r ON m.role_principal_id = r.principal_id
JOIN sys.server_principals p ON m.member_principal_id = p.principal_id
WHERE r.name = 'sysadmin';

Anonymous FTP

# vsftpd
grep -Ei '^(anonymous_enable|anon_upload_enable|write_enable)' /etc/vsftpd.conf /etc/vsftpd/vsftpd.conf 2>/dev/null
# ProFTPD
grep -n '<Anonymous' /etc/proftpd/proftpd.conf /etc/proftpd.conf 2>/dev/null

# IIS FTP: show anonymous authentication state per site
Import-Module WebAdministration
Get-ChildItem IIS:\Sites | ForEach-Object {
  $_.Name + ': ' + (Get-ItemProperty "IIS:\Sites\$($_.Name)" -Name ftpServer.security.authentication.anonymousAuthentication.enabled)
}

Turn off anonymous write everywhere. If an FTP share must exist, make it read-only, outside any web root, and on a host with no database or script runtime.

ASP.NET ViewState

VULONE lists ViewState deserialization as the route to a webshell on one site. Microsoft's Threat Intelligence post from February 2025 covers the most common cause: machine keys copied from public documentation or code. Microsoft says it found over 3,000 publicly disclosed keys. Its guidance, in short:

1. Do not copy machine keys from public sources. Generate new ones.
2. For a single server, remove a fixed machineKey element so ASP.NET generates keys; for a web farm, rotate on every server with the same new values.
3. Encrypt the machineKey and connectionStrings sections of web.config.
4. Upgrade to ASP.NET 4.8 so AMSI is available, and use the attack surface reduction rule that blocks webshell creation on servers.
5. If keys were exploited, Microsoft says rotation is not enough: investigate fully and consider rebuilding from offline media.

# Find web.config files that pin a machineKey
Get-ChildItem 'C:\inetpub' -Recurse -Filter web.config -ErrorAction SilentlyContinue |
  Select-String -Pattern '<machineKey' | Select-Object Path, LineNumber

Microsoft also publishes hashes of known disclosed keys and a comparison script (linked from its post as aka.ms/exposed-machine-keys).

Ecommerce platforms and shared multi-brand estates

VULONE describes administrator access across a multi-brand estate through one platform's REST API, and a separate chain from file read to root. It warns that a single shared-platform credential can expose every brand on it.

1. List every integration, API token and admin user on the platform. In Adobe Commerce and Magento 2, review System, Extensions, Integrations in the admin and the admin user list.
2. Rotate admin API tokens and integration secrets. Remove ones nobody can explain.
3. Split credentials per brand where the platform allows it.
4. Apply your vendor's latest security patches for your exact version.

# Magento 2 / Adobe Commerce: show the installed version
php bin/magento --version

Kubernetes pods and Redis

The report mentions root inside a Kubernetes pod at one target and a root reverse shell on a Redis pod set up by cron at another.

# Pods running as root or privileged, all namespaces
kubectl get pods -A -o json | jq -r '.items[] |
  select(any(.spec.containers[]; .securityContext.privileged == true or .securityContext.runAsUser == 0)) |
  .metadata.namespace + "/" + .metadata.name'

# Look for cron entries inside a Redis pod
kubectl exec -n <namespace> <redis-pod> -- sh -c 'ls -la /var/spool/cron /var/spool/cron/crontabs /etc/cron.d 2>/dev/null'

# Is Redis requiring a password, and where is it writing?
kubectl exec -n <namespace> <redis-pod> -- redis-cli CONFIG GET requirepass
kubectl exec -n <namespace> <redis-pod> -- redis-cli CONFIG GET dir

Redis should require authentication, should not be reachable from outside the cluster, and should run as a non-root user. If dir points somewhere other than the data directory you configured, investigate.

Response: if you find a match

1. Preserve before you clean. Copy logs, the suspicious file and a memory image if you can. Note times in UTC.
2. Isolate the host from the internet but keep it running if you need memory evidence.
3. Do not just delete the webshell. VULONE describes credential collection from configuration files. Assume every secret on that host is exposed: database passwords, API tokens, cloud keys, service accounts.
4. Rotate in the right order. Rotate at the source (the database, the cloud provider, the API platform), then redeploy, then revoke the old secret.
5. Look sideways. Check other hosts for the SSH key, the same file names and the same POST targets. The operator reused credentials across shared platforms.
6. Rebuild rather than repair where you cannot rule out persistence. Microsoft's ViewState guidance makes the same point for exploited keys.
7. Report. Contact your national CERT. In India that is CERT-In, which has its own advisory on AI agent attack vectors. VULONE says it delivered technical detail to affected organisations directly; if you think you are one of them and have not heard, your CERT is the right channel.

What changed since first reports

• The number moved into the headline. VULONE's report breaks the 66 projects down carefully. Secondary coverage on 22 October led with 48 targets breached. The accurate version: 48 projects reached some level of access according to the operator's own records, only partially corroborated.
• The method of access to the operator's host stays undisclosed. VULONE's headline says "We Hacked Their Infrastructure"; the body says access was under authorization and does not say how.
• The SOUL link was clarified. Early readers connected this to Gambit's SOUL campaign because both used Cairn. VULONE's own assessment separates tooling overlap from attribution.
• No victim has confirmed. As of 22 October, we found no public statement from any named government body or company confirming or denying the access VULONE describes.

Open questions

• Which of the 48 claimed accesses will victims confirm, and how many were short-lived or already fixed?
• What were the 54 missing project IDs?
• Who are the 19,307 unique IP addresses that pulled from the exposed directory, and did anyone reuse the tooling?
• Will VULONE or a national CERT publish file hashes for the 339 files? Without them, file name matches are weak evidence.
• What will LLM providers do with the account and billing leads VULONE says it referred to provider-side legal processes?
• Is the operator the same person behind SOUL? VULONE says possible, unproven.

What would have helped

Nothing in this report was a zero-day. Every route VULONE describes was an old flaw, a default, or a setting someone had turned on. That is good news, because all of it is fixable with ordinary work done consistently.

Practices any team can use

• An inventory of what is actually running. Every internet-facing host, its operating system release, its runtimes, and the components inside each application. The RHEL5-era gateway and the JBoss Seam site are the kind of systems that fall off lists.
• Retire or fence what you cannot patch. If a system is past end of life, move it behind VPN or a filtering relay, or switch it off.
• No default credentials, ever. Make "default password changed" a deployment gate, not a post-launch task. MITRE's mitigation for T1078.001 says to change defaults before production, and CISA's 2023 Secure by Design alert asks manufacturers to stop shipping static default passwords at all.
• Keep admin consoles off the internet. API managers, app server consoles and database tools belong behind VPN, with MFA.
• Remove dangerous switches. xp_cmdshell off, anonymous FTP write off, Redis authenticated and internal, machine keys generated rather than copied.
• Separate credentials per brand and per environment. One shared credential should never unlock an entire estate.
• Log POST targets and watch for new script files. The operator chose POST-only commands to stay quiet. File integrity monitoring on web roots costs little.
• Assume volume. Agents will try every old route on every host. Rate limits, WAF rules for known old payload shapes, and alerting on bursts of errors followed by a success all help.
• Govern your own agents. If you run AI agents internally, give each run its own short-lived credentials, limit egress, log every action, and require a human to approve changes to production. The architecture in this report is the same one legitimate tools use.

Where Safeguard fits

Safeguard helps with the inventory and the fix work around software components. It would not have prevented this campaign, it does not hunt for intrusions or match IOCs on your hosts, and it does not check admin consoles for default passwords.

• Finding old components. SBOM and dependency scanning of repositories, container images and SBOM files shows where old components live: a bash package in a base image, a Seam jar in a Java build, an outdated PHP logging library in a composer.lock. Commands: safeguard scan --dir ., safeguard scan --image my-app:latest, safeguard scan --sbom sbom.json, with JSON results under ./output. Findings are matched against vulnerability databases, and the platform shows which projects contain a given component and version.
• Deciding what goes first. Reachability analysis separates findings in code paths you use. Policies and gates evaluated in the platform can hold a build that still carries a flagged component.
• Doing the fix with a human approving. Autonomous remediation can open fix pull requests and is off by default. The Safeguard CLI's assistant can edit code and run commands with your approval; /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs it in CI. The desktop and phone apps can send work to a computer running the CLI and approve each command. That approval model is the opposite of the operator's setup in this report, where agents ran with whatever access they won. See our CLI overview.

Where it does not help: hosts and appliances you do not scan (an old mail gateway outside your images is invisible to it), configuration such as default passwords, anonymous FTP or xp_cmdshell, network detection, and incident response on a compromised server. Use your EDR, logs and national CERT for those.

Zero-Day Discovery and Gold

These are about finding and fixing component flaws earlier. They are not the main lever for this campaign, because the flaws here were old and known.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It played no part in this report, and operating system packages on legacy servers are outside its scope.
• Gold Open Source at gold.safeguard.sh is free with no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. It is a quick way to check whether a version you found in step 2 or 3 above is still affected.
• Gold Registry at registry.safeguard.sh is the paid tier: hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

The habit these support is the one this report argues for: build from patched, signed components from a curated source, and be able to rebuild and redeploy fast, so the old flaws an agent will try simply are not there.

Common mistakes

• Reading 48 as 48 confirmed breaches. It is the operator's tally, partly corroborated. Check your own systems; do not wait for a confirmation that may never be public.
• Searching only for the two C2 addresses. The operator used cloud and mobile addresses too, and the next operator will use different ones. Behaviour and file checks last longer.
• Treating a clean GET log as a clean server. Commands came by POST. Look at files and POST targets.
• Deleting the webshell and moving on. Credentials were collected. Rotate them.
• Assuming AI means new bugs. Here it meant old bugs, tried patiently everywhere.
• Running bash --version on the host and forgetting the images. Check container images and appliances too.

FAQ

Who published the report on AI agents breaching 48 targets in Asia?

VULONE's Research Team, in a report bylined 18 October 2026 and listed on its blog on 19 October. SecurityOnline and others covered it from 22 October.

Did the operator really breach 48 government agencies?

No. VULONE says 48 of 66 projects reached session level access in the operator's own records, and the 48 include both government and corporate targets. Six reached root or SYSTEM. Victim side verification is pending, and none of the named organisations had confirmed in the sources we read.

Is this a Chinese state operation?

VULONE describes a China-linked, Chinese-speaking, financially motivated operator, likely one person or a very small group. It found no evidence of state sponsorship but says state interest cannot be excluded from the outside.

Which AI models and tools were involved?

VULONE says the platform was built on the open source Cairn framework, with workers routed through a local gateway to a DeepSeek model identified as global:deepseek-v4.1-flash. The operator used six paid subscriptions and 16 CodeBuddy accounts farmed for free daily credits.

What are the most useful indicators to check first?

The two addresses 202.61.139.15 and 202.61.139.137, the operator's SSH public key in authorized_keys files, the TLS certificate serial, and the pi (...) and Cairn/1.0 client strings in web logs. All are in the Technical details section.

Is this the same campaign as Gambit Security's SOUL report?

VULONE says the tooling ecosystem is the same with high confidence, but there are no shared indicators, so "same campaign" is not supported and "same operator" is possible but unproven.

Did VULONE notify the victims?

VULONE says technical details were delivered to affected organisations directly and thanks responders who engaged. It gives no dates or recipients, and it does not say whether national CERTs were notified.

Would Safeguard have stopped this?

No. Safeguard can show where old components such as outdated bash or Seam jars sit in your repositories and images, and help you fix them with human approval. It does not detect intrusions, check consoles for default passwords, or scan hosts it cannot see.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows this campaign or any of its targets.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval, and pushes nothing. Here, you would run safeguard scan --image against an old base image that still carries a vulnerable bash, or --dir against a Java service still pulling a Seam jar, and ask the assistant to move to a supported base or remove the dependency. It asks before each command.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with the upgrade done and tests passing. The operator in this report gave its agents free rein inside each container. For your own fixes, the pattern is the reverse: pick the repo holding the Dockerfile or composer.lock, ask for the upgrade, and approve each edit yourself.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session sending work to a computer running the CLI and approving a command with Allow once, Allow for turn or Deny. Automated attacks do not keep office hours; this is how an on call engineer could approve a rebuild or a bash --version check on a build machine from a phone without granting open permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation. For the wider month, see October 2026 security incidents and what would have helped, and for edge devices hit the same month, edge device zero-days in October 2026.

Quick check

Sources

• VULONE: China-Linked Hackers Targeted Governments Across Asia. We Hacked Their Infrastructure. (primary)
• SecurityOnline: China-Linked Operator Used AI Agents to Breach 48 Government and Corporate Targets Across Asia
• Cairn on GitHub (oritera/Cairn)
• CVE record: CVE-2014-6271
• CVE record: CVE-2010-1871
• MITRE ATT&CK: T1078.001 Valid Accounts: Default Accounts
• Microsoft Threat Intelligence: Code injection attacks using publicly disclosed ASP.NET machine keys
• Microsoft Learn: xp_cmdshell server configuration option
• CISA: Secure by Design Alert on eliminating default passwords
• Hunt.io: Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia
• The Next Web: AI agents stole 600,000 credit cards for about $25 a target, Gambit says

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.