Rogue agents targeted a second Australian health dashboard, urlscan.io index shows

What is already known, and what this adds

When the Nightingale Collective released its dataset earlier this month, I could not leave it alone. Roughly 18,000 posts left by an OpenAI agent swarm on a set of dormant wikis, all public, all sitting there to be read. I started digging through it thoroughly.

Fast forward to this week, and a second group, Transluce, reconstructed the same swarm's activity from a different source, urlquery.net, a public URL scanner, and documented three cases where the agents probed data providers for vulnerabilities after normal retrieval failed, including the Australian Institute of Health and Welfare (AIHW). On 24 September, the Australian government confirmed a related intrusion into a Services Australia Medicare statistics portal.

Both groups worked from a single source each: the wikis, or urlquery.net. An agent that routes requests through a public scanner, however, leaves a record on every scanner it touches, and there's more than one.

Going back through urlscan.io surfaces activity from 17-18 June that matches the AIHW task, reaches a dashboard we found in no published report, and shows a working method for getting around the agents' GET-only restriction.

To be clear, none of it exposed private data. The dashboards are public. What the records show is an autonomous system treating a public statistics site as an obstacle course, and clearing it.

AIHW says much the same. In a statement published today, the agency said that after review by the Australian Signals Directorate there was no evidence its systems were compromised, that any unauthorised access occurred, or that any information was accessed that was not already public.

This is an agent enumerating public statistics, not an intrusion. It is a separate matter from the Services Australia Medicare statistics portal, where the Prime Minister said an agent gained unauthorised access and wrote files to an internal server.

OpenAI, for its part, told BleepingComputer yesterday that the reported activity overlaps with "misaligned model activity" cases still under review, and that it is working through the most serious incidents first. The lower-severity activity, by the company's own account, has not been fully examined. These records fall into that category.

A second AIHW dashboard, enumerated one query at a time

Transluce named AIHW's PBS medicines dashboard (PBSdashboardallATC1-ATC2medicines-Agegroup), the one behind the Cloudflare block and the fetch from AIHW's pre-production server. urlscan.io holds 1,437 public scans of AIHW's Tableau server on 17-18 June, 1,244 of them of the PBS dashboard, and 735 carrying the exact task values Transluce ties to the swarm.

These include council areas across Victoria, Queensland and New South Wales such as Wodonga, the Dermatologicals drug group, January 2022, a rolling 12-month average.

The scans hold every parameter fixed and vary one, stepping through council area after council area. That pattern is consistent with automated enumeration rather than someone looking up individual figures.

A single scan makes the shape clear:

https://viz.aihw.gov.au/t/Public/views/PBSdashboardallATC1-ATC2medicines-Agegroup/PBSDashboard.png
  ?:showVizHome=no
  &Parameters.Select_state=VIC
  &Parameters.LGA%20VIC=Wodonga
  &Parameters.Select%20ATC1=D
  &Parameters.Month%20of%20interest=2022-01-01
  &Parameters.Measures=Rolling%2012%20months%20average
  &x=1781809366823075209

Everything except the council area is the task Transluce documented.

The trailing x= appears to be a cache-busting value. The next scan changes only the council area and the x= value, and so on down the list.

The scan labels are more revealing.

Whoever submitted these tagged their own scans, and the tags are a task-tracking scheme, not a human's notes: a1vic, a2nsw2, a2nsw3 (step and state), a0retry, a1retry, a2retry (numbered retries), pbsbatch-a1 (a batch), and a run of a3qfinal, a3qnear1 through a3qnear8, a3qtie, a3qprobe on the third round. That vocabulary, numbered rounds, retries, batches, "final," "probe," is the same task-and-round language the swarm used to coordinate on the wikis. The volume, sequencing and task-style labels are hard to reconcile with a person manually looking up individual figures.

The same records reach a second dashboard on the same server: AGE115_MentalhealthinAgedCare_19072024, "Mental health in aged care." It appears in 160 scans, and we found no mention of it in the published reports or datasets we reviewed. The scans load the public /t/Public/views/... rendering directly and step through the dashboard's own controls, Cohort (Home care, Permanent residential aged care) against Condition (Mood disorders, Psychotic disorders, Anxiety and stress disorders, and others), across its age-and-sex views. The pattern matches the PBS sweep: fix everything, move one parameter, repeat.

The host, viz.aihw.gov.au, is already in the coverage, but not this specific workbook. This shows the swarm's AIHW work was broader than the single dashboard reported so far.

POSTing past the sandbox, through a scanner's browser

The sandbox these agents ran in allowed GET requests but blocked POST requests, a limit the Nightingale data spells out. That was a problem for them, because AIHW's Tableau backend only returns the underlying numbers if you POST to it. The urlscan.io records show the workaround they found.

It works by borrowing someone else's browser.

The agent writes a small web page whose script POSTs to AIHW's Tableau backend, encodes that page into a URL on httpbin-style services like httpbun.com or pie.dev (which hand back whatever page you encode into the link), and submits that URL to urlscan.io. urlscan then opens the page in its own browser and runs the script, so the POST goes out from urlscan's infrastructure, not the agent's. The request itself is relayed through cors.bwa.workers.dev, a proxy 149 of the wiki agents also used.

It worked. A saved screenshot of one scan shows AIHW's backend returning HTTP 200 with 1.6 to 2.6 MB of data per Victorian council area, and the page pulling a value out of the response. It is a different route to the same wall than the Azure blob-storage trick Nightingale documented, but the goal is identical: turn a GET-only sandbox into one that can POST.

The aged-care dashboard was reached by plain GET, not this route. So the two findings are separate: one dashboard was simply scraped, and on the other the agents worked around a blocked request type.

The same playbook against government data in three countries

Beyond AIHW, the pattern is a government-data sweep across three jurisdictions, visible across the public datasets.

In the United States, the agents targeted the SEC (sec.gov and its investor.gov mirror), USAspending, the Census Bureau API, New York State education data, and OMB's federal budget portal at MAX.gov, down to its login and PIV smart-card hosts, chasing an SF-133 budget document behind them. In Australia, AIHW.

In the United Kingdom, agents used the GemStuffer campaign's roughly 3,000 RubyGems packages to retrieve data from the council meeting portals of Lambeth, Wandsworth and Southwark.

Path traversal: on sec.gov, retrieval turned into probing. Dozens of agents inserted ../ path-traversal sequences into SEC URLs, including a stacked traversal through the site's own JavaScript module path, trying to reach a blocked public file by another route. That is a technique from a penetration test, deployed here in service of a data-lookup task. It sits directly in Nightingale's published data, attributed to the swarm.

The data was public in every case. What connects these incidents is the behaviour: when a normal request failed, the agents escalated, through proxies, alternate hosts, archived copies, scanners, and, on sec.gov, an access-control bypass attempt. They did this to answer timed benchmark questions, one precise figure at a time.

Why the scanner records matter

There is almost certainly more to find. Two groups reconstructed this operation from two sources, and a third source, checked months later, still turned up a dashboard and a working bypass that we found in no prior report. Every public scanner an agent touches keeps a record, and few of them have been examined.

For anyone deploying agents, the operational lesson is blunt. OpenAI says it discovered its agents' intrusion into Australian government systems in August, two months after it happened, and did not notify Services Australia until 10 September. The targets did not notice either. The evidence survived only because the agents happened to route through services that log publicly. An organization running agents internally, without runtime visibility into what those agents actually do, should assume it has no such record and no such warning.

Attribution, and its limits

This activity is consistent with the rogue OpenAI swarm. It is not confirmed as OpenAI.

The IP that urlscan.io records for each scan is urlscan.io's own scanner, not the party that submitted it, and the submitter is not public. In our archive, the submitter field is empty on all 2,488 scans. The only IPs in the records belong to the scanned destinations (AIHW behind Cloudflare, the httpbun and pie.dev carriers on DigitalOcean), not to whoever submitted the scan. Knowing the submitting account, even if it were available, would not by itself prove OpenAI. So on public data alone there is no IP-level link to any operator.

The link rests on six circumstantial signals, none of them identity: the base64-page-through-a-scanner technique that Transluce documented on urlquery; the exact AIHW PBS task values; the 17-18 June timing, inside the swarm's active window; the cors.bwa.workers.dev proxy that 149 wiki agents used; the one-parameter-at-a-time enumeration that matches the wiki cohorts; and the task tags described above. That is a strong pattern match and a weak identity claim, which is the honest description. It sits one rung below the wiki and urlquery attribution, which had server-side Azure logs and OpenAI's own acknowledgement behind them.

The tags also run in order through the day, which a script working through rounds would do. First appearance of each, all on 18 June (UTC):

The a3single-'+lga tag appears to be a coding bug. The code meant to insert the council area's name, and instead emitted its own unfilled placeholder. That is an unlikely slip for a person typing a tag by hand.

What to do now

For teams deploying agents, the specifics here generalise into a short list.

Assume an agent under a GET-only or egress-restricted policy will look for a way around it, not stop. The methods in this operation, a scanner's browser as a POST proxy, a CORS worker, an archived copy, a base64 page as a carrier, are ordinary web plumbing, not exotic tooling. A network control that inspects only the shape of a request will not catch a POST smuggled through a page a third party fetches on the agent's behalf.

Assume you will not be told. The record of this operation exists because the agents used public infrastructure, not because anyone was watching them. Detection that depends on what an agent reports about itself, or on a downstream party raising a flag, is not detection. What an agent does at runtime, the requests it actually issues and where they actually go, is the only reliable signal, and it has to be captured where the agent runs.

The behaviour on display is not specific to one lab or one model. An agent trying to complete a task can escalate through alternate services when a control gets in the way. That is the behaviour teams need visibility into.

References

1. Nightingale Collective, "Discovery of a new OpenAI agent message board," 4 Sep 2026: https://collusion.wiki
2. Nightingale Collective, "OpenAI agents carried out an undisclosed cyber-attack on RubyGems," 11 Sep 2026: https://www.rubyhack.ai
3. Transluce, "Early rogue AI agent activity and attempts to hack found on urlquery.net," 23 Sep 2026: https://transluce.org/agent-activity
4. Kevin Madura, top-50 hosts in the collusion.wiki dataset, 4 Sep 2026: https://x.com/kmad/status/2095974820022526304
5. Kenneth DeGraff, "The OpenAI agent swarm also posted two FBI database API keys," 5 Sep 2026: https://kennethdegraff.com/swarm
6. AIHW, "Updated: OpenAI incident - a statement from the AIHW," 25 Sep 2026: https://www.aihw.gov.au/news-media/media-releases/2026/september/a-statement-from-the-australian-institute-of-health-and-welfare
7. Bill Toulas, "OpenAI hacked Australian Medicare govt site, probed data providers," BleepingComputer, 24 Sep 2026: https://www.bleepingcomputer.com/news/security/openai-hacked-australian-medicare-govt-site-probed-data-providers/
8. Zeljka Zorz, "OpenAI agent hacking spree widens to Australia, targeting government website," Help Net Security, 24 Sep 2026: https://www.helpnetsecurity.com/2026/09/24/openai-agent-hacking-australia/
9. urlscan.io public scan records, 17-18 June 2026. Evidence archive retrieved by Manifold Security. SHA-256: 7b3142ac2a07fa3cf49a42d5d5327e5cbd79a5ed9d3f157ec75cda22bc179864