First American Financial — 885M document exposure

What happened

On 24 May 2019, security journalist Brian Krebs published a report describing a massive exposure of sensitive financial documents at First American Financial Corporation — the largest title insurance and settlement-services provider in the United States. The exposure was not the result of a sophisticated cyberattack. It was the result of a basic web-application design error that had existed in the company’s public-facing document portal for approximately sixteen years.

The affected portal, known internally as EaglePro, was used to share closing documents with buyers and sellers involved in real-estate transactions. When a customer received a link to their documents, the URL contained a sequential numeric identifier. Changing the number in the URL — incrementing it by one, or any other integer — returned a different customer’s document, with no authentication check performed by the server. Anyone in possession of a single valid document link could systematically enumerate the entire document store.

The documents exposed included some of the most financially sensitive materials that exist in the civilian sphere: bank account statements, mortgage and tax records, Social Security numbers, copies of driving licences and other identity documents, and — critically — wire transfer instructions and bank account and routing numbers used to complete real-estate transactions. The exposure covered approximately 885 million documents dating back to 2003. First American disabled the portal within hours of the Krebs report being published.

The SEC subsequently charged First American not for the underlying exposure itself but for failures in its cybersecurity disclosure controls — the process by which the company assessed and reported the materiality of the incident to investors. The charge was settled for $487,616. New York’s Department of Financial Services imposed a separate $1 million fine under New York’s cybersecurity regulation (23 NYCRR 500), one of the first enforcement actions under that regulation.

How it worked

The vulnerability class is formally described as an Insecure Direct Object Reference (IDOR). It is catalogued in the OWASP Top Ten list of critical web-application vulnerabilities — a list that has been published and widely circulated since 2003, the same year the First American portal began accumulating the documents it would eventually expose. An IDOR occurs when a web application uses a user-controllable reference — a number, a filename, a token — to locate a resource, and fails to verify that the requesting user is authorised to access that specific resource.

In the EaglePro implementation, the URL structure was approximately: EaglePro.aspx?Token=[integer]. The integer was assigned sequentially as each document was stored. The server, when a request arrived, retrieved the document identified by the integer and returned it to the requester without performing any check on whether the requesting user had a legitimate relationship to the document in question. There was no authentication requirement at all — the document was returned to any HTTP client that sent a request with a valid integer, whether or not the requester was logged in, whether or not they had ever had any interaction with First American, and whether or not they were a party to the transaction the document related to.

The discovery route is also notable. A real estate agent, Ben Shoval, was reviewing his own documents through the portal when he noticed the structure of the URL. He tested whether incrementing the number returned other documents. It did. He reported the vulnerability to First American’s security team; having not received a substantive response, he contacted Krebs, who investigated and confirmed the exposure before publishing. This is a responsible-disclosure pathway, albeit one where the internal response failed: the vulnerability was reported before it was published, and the organisation did not act.

The scale of the exposure is a function of time multiplied by volume. First American processed millions of real-estate transactions per year. At 885 million documents accumulated over sixteen years, the figure represents a substantial fraction of all US real-estate transactions in that period. The documents included wire transfer instructions — the information needed to redirect the proceeds of a property sale to a fraudulent bank account — which represents one of the highest-value individual documents in the real-estate transaction process.

There is no public confirmation of how extensively the vulnerability was exploited before Krebs’s report. First American’s subsequent investigation assessed the scope of unauthorised access but the findings were not made fully public. The SEC enforcement action focused on the company’s failure to assess and disclose the materiality of the incident to investors in a timely and accurate manner, rather than on the underlying number of records accessed by unauthorised parties.

Timeline

• 2003 — First American’s EaglePro document portal is built and begins accumulating transaction documents. The IDOR vulnerability is present from the outset.
• 2003–2019 — 885 million documents accumulate in the portal across sixteen years of real-estate transaction processing. The vulnerability remains undetected in internal assessments.
• Early 2019 — Ben Shoval, a real estate agent, notices the sequential URL structure while reviewing his own closing documents and tests whether incrementing the integer returns other documents. It does. He reports the vulnerability to First American.
• May 2019 — First American’s initial internal response to Shoval’s report is inadequate. An internal IT assessment of the vulnerability downgrades its severity; remediation is not immediately prioritised.
• 24 May 2019 — Brian Krebs publishes his report. First American takes the EaglePro portal offline within hours of publication.
• May–June 2019 — First American engages external forensic investigators. SEC and state regulators are notified. New York DFS opens investigation under 23 NYCRR 500.
• 2019–2020 — First American conducts remediation and assesses the scope of the exposure. Internal communications reviewed in subsequent regulatory proceedings indicate that senior executives were aware of the vulnerability before Krebs’s report.
• June 2021 — SEC issues cease-and-desist order and charges First American Financial Corporation with violations of Rule 13a-15(a) — failure to maintain adequate disclosure controls — and settles for $487,616. This is the first SEC enforcement action specifically targeting cybersecurity incident disclosure procedures.
• October 2021 — New York DFS imposes $1 million penalty under 23 NYCRR 500 for multiple cybersecurity regulation failures including the inadequate vulnerability assessment and remediation failure.

What defenders should learn

The IDOR vulnerability is not an esoteric or advanced attack class. It is in every web-application security training curriculum. It appears on every version of the OWASP Top Ten. It is taught in every introduction to web security. It is also, clearly, still implemented in production systems at organisations that process hundreds of millions of sensitive documents. The lesson from First American is not that IDOR is a new problem — it is that the gap between awareness of a vulnerability class and elimination of that class from production systems can persist for a very long time, particularly when an application is not subject to consistent security testing.

Application security testing — specifically, penetration testing and code review that includes authorisation-logic testing — would have found this vulnerability in minutes. A request for document A, then a modified request for document A+1, and an inspection of whether the response changes: that is the entirety of the IDOR test. Any penetration test that includes authorisation testing as a scope item would have caught this. The question for organisations assessing their own exposure is whether their security testing programme actually tests whether every resource in every application verifies authorisation, or whether it tests only whether the application has authentication at all. Authentication (are you logged in?) and authorisation (are you allowed to see this specific thing?) are different controls.

The internal response to Shoval’s report is its own lesson. The vulnerability was reported through a legitimate channel before it became public. The organisation’s internal assessment downgraded its severity and did not remediate it promptly. The failure was not in the discovery process — the responsible-disclosure pathway functioned correctly. The failure was in the internal triage and escalation process that received the report and failed to act on it. Organisations need vulnerability-management processes that can correctly assess the severity of an IDOR in a document portal serving 885 million records, and that treat a confirmed authorisation bypass against sensitive financial documents as a critical finding requiring immediate action, regardless of what the application’s internal severity-assessment rubric might produce.

The SEC enforcement action extends the lesson into the investor-relations and governance domain. The charge was not about the breach — it was about how the company assessed and communicated the incident’s materiality to investors. Regulators now expect that when a material cybersecurity incident occurs, the organisation’s disclosure controls are sufficiently mature to assess it accurately and report it appropriately. Cybersecurity incidents are material if a reasonable investor would consider them important in making investment decisions. A sixteen-year exposure of 885 million sensitive financial documents at a major title insurer is, by most reasonable assessments, a material event. Building the governance processes that connect incident response to investor disclosure — and that ensure accurate characterisation rather than systematic understatement — is now a compliance requirement, not an optional addition to the IR programme.