Arizona courts breach puts protected addresses at risk
Attackers copied personal data from Arizona's court system, including confidential addresses of protective order holders. What is known and what to check.
By Yaali. September 28, 2026, 6 min read, Threat intel, Resilience.
On the night of Friday, September 25, 2026, Arizona Supreme Court Chief Justice Ann Scott Timmer announced that the state court system had been attacked by "criminal hackers or their bots." Court IT staff found the intrusion and moved to stop it, and court leaders believe the attackers copied personally identifiable information (PII) about "many Arizonans." Local reporting says that includes names and addresses, and puts the breach within the 36 hours before the announcement.
The sharpest risk falls on a small group. People with a current or past protective order were told that the confidential address they gave the court may be in the copied data, and for someone who left an abusive partner, that address is what the order exists to protect. The court has not said how many people are affected, which courts or databases were hit, or how the attackers got in. Scope is still under investigation, and what this post says about attack methods describes how such breaches usually happen, without any confirmation that it applies here.

How it works
The court is withholding technical detail to protect the FBI investigation, and the entry point is unknown. What can be explained is why a court record system is such a valuable target, and how bulk copying of records usually happens and gets caught.
In Arizona, a petitioner whose address the other party does not know can keep it off the protective order itself. The court holds it on a separate form in its own files so it can contact the petitioner about the order. That design keeps the address away from the respondent, but it also means one court system links a protected person's name, case and current location. Anyone who copies that store gets a lookup table from name to home address.
Bulk theft from a records system usually follows one of three paths. The first is a valid staff or service account, stolen through phishing or reused passwords, used to query the case database directly. The second is a flaw in an internet-facing portal, such as a public case search or e-filing site, that lets an outsider run queries or read files. The third is a broken object-level access check (the server returns any record whose ID you ask for without checking that you may see it), which lets a script walk through record numbers one by one. The court's phrase "hackers or their bots" fits more than one of these, and it has not said which applies.
Each path leaves a different trail, and bulk copying is easy to spot when the right logs are already switched on.

Containment follows from which path was used: disable the account or API key, block the source addresses at the edge, or take the portal offline, then preserve logs before they rotate. Arizona went from breach to public warning in under 36 hours. The Pentagon's DMDC breach, by comparison, went unnoticed for about nine months.
What attackers are doing
The breach happened within the 36 hours before the Friday night announcement. The Administrative Office of the Courts (AOC) began emailing affected people that night, with notices still arriving in the early hours of September 26.
The copied data is PII about many Arizonans, which FOX 10 Phoenix and AZFamily report includes names and addresses. Notices sent to protective order holders said information about them and their location was among the copied data. Both outlets report that the attack swept up a broad range of court records rather than going after specific individuals.
The court says it has no evidence the stolen data has been shared with anyone. Timmer said she personally spoke with the top-ranking FBI official in Arizona and pledged the court's full support to the investigation. No attacker has been publicly named, no count of affected people has been released, and the court says it will not share details that could affect the investigation or the people involved.
Expect phishing emails that copy the court's notice. The court's cybersecurity alert page on AZCourts.gov states "This is not a scam" and lists the one address genuine notices come from. News reports have quoted different sender addresses, so use that page as the reference for any notice you receive.
What to do
If you have or had a protective order in Arizona
Check whether you received a notice, and confirm its sender on the court's alert page before you act on it or open any link. If you think your safety is at risk, contact local law enforcement, as local reporting advises, and talk to a domestic violence advocate about updating your safety plan.
If you move, look at Arizona's Address Confidentiality Program (ACP), run by the Secretary of State. It gives survivors of domestic violence, sexual offenses and stalking a substitute address that becomes their legal address of record, so a new home address does not land in court or agency files. Enrollment goes through an in-person meeting with an Application Assistant at a victim service agency. It cannot recall an address that was already copied.
If your agency holds protected addresses
Keep the confidential address in its own table or system, with its own access role, and never in the general case record. Encrypt it at the field level so a dump of the case database does not include it in clear text. Make sure public search, e-filing and records APIs cannot return that field in any response, and test object-level access by requesting records by ID from an unprivileged account.
Cut down what you keep. The Arizona notices went to people with past orders as well as current ones. Once an order expires and your legal retention period ends, purge the confidential address or move it to offline storage.
Log every read of the protected field with user, record ID and time, and alert on distinct records read per user per hour above a low threshold. In PostgreSQL, use pgaudit object auditing: set pgaudit.role to an audit role and grant that role SELECT on the table. In SQL Server, create a database audit specification with the SELECT action on that object.
If you run government IT
This week, pull the last 30 days of logs for your record systems. Find the accounts that read the most distinct records, the source IPs with the highest request rates on public portals, and any spikes in outbound traffic from database servers. Then check you could answer "which records did this account read, and when?" within hours. If you could not, turn on read auditing before any other change.
Have notification ready before you need it: contact data for affected people, message templates, and one public page that lists the single sending address, as Arizona set up with its alert hub.
Our attack surface management work finds the public portals and APIs that can hand out records, and security operations builds the alerts that catch bulk reads while they are happening. If you hold data like this and want to know whether you would see it leaving, open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Arizona Supreme Court news release, AZCourts.gov cybersecurity alert, AZFamily, AZFamily, victim interview, FOX 10 Phoenix, ABC15, The Arizona Republic via AOL, The Daily Hodl, Cybernews, AZCourtHelp, Arizona Secretary of State ACP.
Read next
- How an Adif breach became a Renfe data leak
- Iran-linked control system attacks widen to telecom
- Pentagon's DMDC breach: 9 months of hidden access
Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.