Threat

Taiwan-Based Hacker Used BOSSAI AI Agents to Steal Taipei Emergency Dispatch Records

Page published · Page updated

Dossier

Earliest dated coverage: 9 Nov 2026 · First observed: 9 Nov 2026 · Latest dated coverage: 9 Nov 2026

Coverage timeline

9 Nov 2026thehackernews.com

Single-source incident — one report is available.

Why it matters

The BOSSAI campaign demonstrates how a single attacker can use AI agents to target hundreds of organizations and obtain sensitive emergency-service data.

A Taiwan-based attacker used BOSSAI AI agents to steal emergency dispatch records covering seven Taipei districts, according to Acronis researchers. The agents targeted hundreds of organizations across at least 11 countries and collected data or accessed systems at about 10 organizations in Taiwan, Mexico and Thailand. Researchers based their findings on more than 90,000 files exposed on the attacker's operational server, including agent conversations, credentials and victim data.

campaign

Summary

The Hacker News reports that Acronis researchers uncovered an AI-assisted operation run, in their high-confidence assessment, by a single person based in Hualien City, Taiwan. Researchers reportedly examined more than 90,000 files on the operator's exposed attack server and observed the operation for 12 days. Hundreds of organizations in at least 11 countries were targeted, with data collection or system access reported at about 10 organizations in Taiwan, Mexico, and Thailand. All findings in this dossier rely on that single secondary article; the underlying operational records are not supplied for independent verification.[0]

The clearest reported emergency-services data theft involved 119 dispatch case records covering seven Taipei districts, extracted through a public-facing API. These were incident records with timestamps, response types, status, and street-level locations—not live ambulance tracking. Separately, agents found a Taipei fire-department platform exposing historical patient information, ECG readings, and ambulance video without login. The detailed account establishes exposure of that patient platform, but does not confirm extraction of its records.[0]

BOSSAI comprised 12 agents, with nine used, but was not an independently coordinating agent swarm: the operator manually transferred outputs between agents. Commercial models mainly built and maintained infrastructure; direct attack execution relied almost entirely on locally run models with safety training removed. Successful activity included SQL-injection data extraction from a Taiwanese lender and three Thai universities, and database-panel access using default root credentials at a fire-dispatch vendor. The reported successes largely involved existing exposure, weak credentials, injection flaws, or unpatched systems.[0]

The operation's reach should not be confused with uniformly successful compromise. Mexican phone-record collection drew on public datasets, several emergency-services targets had no confirmed compromise, and a claimed Apache vulnerability did not exist. Agent-generated findings and success reports were demonstrably unreliable. No operator name or confirmed employer is disclosed, financial motivation remains a researcher assessment, and notification and remediation status are unresolved. Although the article references an infrastructure indicator list, it supplies no actionable IP or domain literals.[0]

Attack chain

  1. Target selection — documented Thai branch: The agents selected 489 potential targets across 45 institutions in Thailand before the reported university data collection. This is the explicitly described target-selection stage for that branch; it should not be treated as the sequence followed at every organization.[0]
  2. SQL-injection exploitation and data collection — documented Thai branch: Following target selection, agents collected data from three Thai universities through SQL injection. The article describes university Oracle databases as unpatched but does not identify a specific database release, exploited CVE, or detailed exploit chain.[0]

Disclosure timeline

DateEvent
2026-11-09The Hacker News published its account of the Acronis findings. The article did not establish whether affected organizations or Taiwanese authorities had been notified, or whether the exposed data remained accessible.[0]

How it works

Unauthenticated data access was central to the Taipei findings. Agents retrieved 119 dispatch records from a public-facing API, while a separate fire-department patient platform exposed medical records without login. These are distinct findings: extraction was reported for dispatch records, whereas the detailed patient-platform account establishes accessibility rather than confirmed theft.[0]

SQL injection enabled account-table extraction from a Taiwanese lending firm and data collection from three Thai universities. The article identifies 16 injection points at the lender and describes university Oracle databases as unpatched, but provides no payloads, affected release numbers, or specific vulnerability identifiers. It does not establish that patching Oracle alone would resolve the application-level injection paths.[0]

At a fire-dispatch technology vendor, default root credentials permitted login to a database administration panel and access to at least 18 database tables. The successful credential-based access must be separated from an unsuccessful web-shell attempt involving an unspecified known CVE; the latter is not evidence of achieved code execution.[0]

A hardcoded AES-256 key in an emergency-management application's front-end JavaScript exposed session-cookie contents, including an administrator's identity. The report does not establish that this disclosure enabled session forgery, administrator login, or further compromise, so it should not be presented as a confirmed account takeover.[0]

The purported critical Apache remote-code-execution finding at a national disaster-response center was false. More broadly, the scanning tool invented CVEs and produced substantial false-positive or classification errors. These outputs cannot be used as an affected-product inventory or proof that exploitation succeeded.[0]

Key takeaways

  • The grounded AI capability in this case is increased operational reach against weakly protected targets, not demonstrated defeat of robust authentication. The agents accessed exposed services and exploitable applications, while enforced logins, session checks, and endpoint filtering stopped other attempts.[0]
  • Maintain separate outcome categories for confirmed extraction, exposed data, authenticated access, public-data aggregation, unsuccessful exploitation, and scanning. Combining these would overstate both the number of breaches and the demonstrated capabilities of BOSSAI.[0]
  • BOSSAI was human-coordinated despite its multiple agents. Manual output transfer, dependence on safety-modified local models for attacks, and unreliable agent reporting are material limitations on claims of autonomous operation.[0]
  • The supplied evidence does not support a named-actor profile, a release-specific affected-version table, or a usable indicator list. Attribution to a Hualien-based individual remains the researchers' assessment, and the referenced nine IP addresses and nine domains cannot be reconstructed from the article's counts.[0]

Defensive actions

  • Require authenticated, appropriately restricted access to dispatch APIs and patient-data services, and close unintended public exposure of medical-data ports.: The reported Taipei outcomes depended on a public-facing dispatch API and a patient platform accessible without login. Authentication, valid-session requirements, and endpoint filtering were also specifically identified as controls the agents failed to overcome.[0]
  • Replace default root credentials and restrict exposure of database administration panels; review access to the vendor's accessible tables.: Default credentials, rather than a successful web-shell exploit, provided the documented access at the fire-dispatch vendor. At least 18 tables were accessible, making credential correction and examination of database access directly relevant to this branch.[0]
  • Prioritize remediation of the lender's and universities' SQL-injection paths, and review the unpatched Oracle deployments described in the university environments.: SQL injection produced confirmed data collection at these targets. The report supplies neither fixed software releases nor a specific database CVE, so defenders should verify the application flaws and installed database patch state rather than assume one vendor update addresses every entry point.[0]
  • Remove session-encryption secrets from front-end JavaScript and replace the exposed AES key in the emergency-management application.: The client-delivered key exposed session-cookie contents and an administrator's identity. This is a concrete secret-exposure issue even though administrator access or subsequent compromise was not confirmed.[0]
  • Validate AI-generated vulnerability and compromise claims against actual system behavior and access evidence before assigning incident scope or remediation priority.: The operation's scanner invented CVEs, more than half of its high and critical findings were false positives or misclassified, and the main attack agent claimed results that had not occurred. The nonexistent Apache flaw and failed web-shell attempt illustrate why scanner output and agent assertions are insufficient proof.[0]