In This Article
Most security news arrives with a number attached. A CVE, a severity score, a patch to deploy on a Tuesday. You route it to whoever owns patching, they close the ticket, and the risk register gets a tidy line item.
This one arrives with none of that. Two separate financial regulators have warned that attackers are reading customer and employee data straight out of Microsoft Dataverse through public-facing Power Pages portals, then demanding a ransom to keep it quiet. There is no CVE to look up. There is no patch to deploy. The door was opened by a configuration choice inside the tenant, and it stays open until somebody goes and closes it. If your institution runs a borrower document portal, a member self-service site, or a broker submission form on the Microsoft stack, that is the same technology.
That distinction matters more than it sounds. Every process your institution has for handling security news assumes a vendor will eventually ship a fix. This class of exposure has no vendor fix, because both regulators describe it as a configuration problem inside the customer's own environment rather than a flaw in the product.
ABT manages Microsoft 365 tenants for more than 750 financial institutions, primarily credit unions, community banks, and mortgage companies. What follows is what each regulator actually said, who each one was addressing, why there is nothing to patch, and the four things worth checking in your own tenant this week.
What Two Regulators Actually Said
On September 8, 2026, the California Department of Financial Protection and Innovation published a security alert about threat actors exploiting Microsoft 365 Power Pages misconfigurations. The language is unusually direct for a regulator.
By taking advantage of improper permissions, perpetrators can gain unauthorized access to databases containing customers' and employees' personally identifiable information (PII).
They then threaten to publicly disclose the compromised data unless customers and employees meet their ransom demands.
FINRA issued its own cybersecurity alert to member firms covering the same campaign. Read together, the two alerts describe one problem from two regulatory angles, and they agree on the mechanism.
Before going further, it is worth being precise about who each regulator was talking to, because the answer is narrower than the headlines suggest.
Who Each Alert Was Addressed To
The DFPI alert is directed at registered investment advisers and broker-dealers, with broader reference to financial services firms. The FINRA alert is directed at member firms using Microsoft Dynamics 365 or Power Pages. Neither regulator addressed banks, credit unions, or mortgage companies.
We are raising it with those institutions anyway, because the exposure has nothing to do with what kind of firm you are. It is a property of how a Power Pages portal was configured. The portals named at the top of this article run on the same technology as the ones the regulators described.
FINRA's alert names the threat actor and spells out the mechanism in terms an administrator can act on immediately.
ExfilSquad targets Dataverse table permissions that have granted the Anonymous Users web role overly broad read access to sensitive entities via the Power Pages web API.
Strip out the product names and the sentence says something simple. A table holding real records was given a permission. That permission was attached to the role that represents a visitor who has not signed in. The portal exposes a web interface over that table. So anyone who finds the address can read the records.
As for how much data this has produced, that number belongs to a research firm rather than to either regulator. Fortra's Intelligence and Research Experts assessed roughly 27 million records across 13 organizations that the extortion group published, spanning government, education, financial services, and manufacturing. The group emerged on July 26, 2026 and published that data on August 7, 2026, according to reporting in Infosecurity Magazine. That is an assessment of what was published, not a confirmed accounting of every victim's full breach scope.
Why There Is Nothing to Patch
The instinct on reading an alert like this is to ask which update closes it. FINRA answers that question before anyone asks, and the answer is that there is nothing to update.
FINRA states that available evidence does not indicate exploitation of a software vulnerability within Dynamics 365 itself. No CVE has been assigned to this campaign, and the DFPI alert names no vulnerability either. What both describe is a permissions problem inside the customer's own environment.
Microsoft's documentation supports the same reading, and it is worth quoting because it inverts the usual story about insecure defaults.
Microsoft's position is that Power Pages starts closed. Its documentation states that access to Dataverse records is automatically restricted in Power Pages when using forms, lists, Liquid, the Portals Web API, and other components accessing Dataverse tables. To open that access, the documentation continues, you need to configure table permissions and associate the table permissions to web roles.
Read that carefully and the shape of the incident changes. Access to a Dataverse table through a portal does not exist until it is granted, and granting it takes someone holding the rights to do so. So the question in front of a portal owner is not what went wrong in the product. It is what was switched on, when, and whether anyone has read it since. FINRA makes the same point from the other direction, noting that Microsoft's own documentation advises against assigning the Anonymous Users web role to table permissions on publicly exposed sites.
The practical consequence for a managed tenant is that this is a review problem rather than a monitoring problem. A permission that was granted deliberately, by someone entitled to grant it, to make a real page work, is not an anomaly that announces itself. Somebody has to go and read it. Running under delegated administration is what gives a Tier-1 Cloud Solution Provider the standing to do that, which is why a tenant configuration review walks the Power Platform surface alongside identity, mail flow, and data protection rather than treating it as a separate system.
That reframing is the whole reason this one is worth a morning of somebody's time. A product flaw has an owner, a bulletin, and a queue. A permission somebody granted on a Tuesday to make a page work has none of those things, and it will sit there until a person goes looking for it.
Key Takeaway
A secure default protects you only until someone changes it. The gap between a safe out-of-box configuration and a dangerous live one is a normal workday, a deadline, and an administrator trying to make a portal work.
How a Portal Ends Up Readable by Anyone
No one sets out to publish a customer table. The path there is mundane, which is exactly why it keeps happening and why it survives so long once it does.
A portal page needs to show loan status to a borrower before sign-in, so the person building it grants read on the relevant table to the Anonymous Users web role. The page works. The project moves on. Eighteen months later the portal has grown to a dozen pages, the original builder has changed roles, and nobody has re-read that permission since the afternoon it was created.
The permission is not scoped to the one field the page needed. It covers the table, and the portal's web interface will serve that table to any unauthenticated request that asks correctly. The records are readable without an exploit, without a credential, and without generating anything that resembles an intrusion.
Which raises a question worth asking out loud at your own institution before the next board packet: who here can stand up a Power Pages site, and who can attach a table permission to the Anonymous Users role? At most institutions this size the honest answer is that nobody has checked, because a portal can be created by a business unit or an implementation partner without ever passing the group that manages the tenant. That is a question about who holds administrative rights in your Microsoft 365 environment and who reviews what they do with them, which is the same governance question sitting behind every other permission in the tenant.
Three properties of this failure make it unusually durable inside an institution that otherwise runs a careful security program.
It produces no alert, because nothing abnormal happens. A request arrives at a public web address and receives the response the configuration says it should receive. There is no failed sign-in, no unusual token, no malware.
It sits outside the surfaces most institutions review. A tenant review scoped to identity, endpoint, mail flow, and data loss prevention can pass cleanly while a Power Pages portal quietly serves a table, because portal permissions live in the Power Platform configuration rather than in any of those places. This is the same structural blind spot we wrote about in the Conditional Access exclusion list nobody reviews: a setting that was reasonable the day it was made and was never revisited.
It also survives a good score. An institution can hold a strong Microsoft Secure Score while this is live, because the score measures the recommended actions Microsoft evaluates, and portal table permissions are not among them. We have made that argument at length in why a high security score does not mean the business is safe, and this campaign is a clean illustration of it.
What to Check This Week
The remediation both regulators describe is short enough to run as a focused exercise rather than a project. If your institution operates any Power Pages portal, these four checks answer the question directly.
Include portals built for a single campaign, a single partner, or a pilot that was never formally retired. A forgotten portal is still a live portal, and it is the most likely one to hold a permission nobody remembers granting.
This is the specific relationship both regulators named. For each one, ask what the portal page actually needs to display before anyone signs in, and whether the permission is scoped to that or to the whole table.
DFPI names disabling anonymous access and removing the anonymous users web role from table permissions as direct remediation steps. Where a page genuinely must serve unauthenticated visitors, restrict web access to only the tables that page needs.
FINRA recommends enabling Dataverse auditing and monitoring access logs. Note what that does and does not buy you. Auditing you switch on today records what happens from today, so it is the instrument for catching the next exposure rather than for reconstructing the last one. Whatever logging was already running is the only record you have of the period before, which is a good reason to find out now what that covers. Our guide to Microsoft 365 audit log retention covers how long that evidence needs to survive.
FINRA's alert goes further than the portal itself. It also recommends disabling device code flow, requiring multi-factor authentication, and reviewing vendor risk management programs. That last item is the one most likely to be skipped and the one most likely to matter, because a portal built by an outside implementation partner is still your portal and still your data. If that review is overdue, our note on what belongs in a Microsoft 365 vendor due diligence file is a reasonable starting point.
Find out whether any portal in your tenant is serving data it should not
ABT has been securing and managing Microsoft environments for financial institutions since 1999, and manages Microsoft 365 tenants for more than 750 of them today. A tenant configuration review walks the surfaces a vulnerability scan does not reach, Power Platform portals among them, and produces a list of what is actually exposed rather than a score.
The Risk Your Vulnerability Scanner Cannot See
Step back from Power Pages and the broader lesson is about how institutions decide what counts as a security problem worth attention.
Most security programs are organized around identifiers. A CVE arrives, it gets a score, it enters a queue, it gets patched, the queue shortens. That machinery works, and it has made institutions meaningfully safer against the class of problem it was built for. Its blind spot is that it only sees what somebody assigned a number to.
Nobody assigns a number to a permission you granted on purpose. There is no advisory feed for the read access your own administrator attached to an anonymous role some years ago. A scanner pointed at that portal returns a clean result, because the software is current and behaving exactly as configured. The configuration is the finding, and the configuration is invisible to the instrument.
The most expensive misconfigurations are the ones that work. A broken setting gets fixed the day it breaks something. A permissive one just quietly answers every request it receives.
This is the argument for reviewing configuration as its own discipline, on a schedule, separately from patching. California's financial regulator reached for a rare public alert to make that point to the firms it supervises. For credit unions, banks, and mortgage companies, the supervisory letter may never arrive, and the exposure is identical.
Closing the gap on a portal you already know about takes minutes. Someone with the right access opens its security settings, reads what is attached to the anonymous role, and decides whether it belongs there. The work sits on either side of that step: building a complete inventory of the portals in your tenant, including the one a business unit stood up for a campaign three years ago, and reconstructing what each anonymous permission was granted for before you remove it and break a page somebody still uses. That inventory is the piece institutions rarely have on hand, and it is where we usually start with a customer. If your institution also holds California obligations, it pairs naturally with the questions in meeting California's information security requirements.
If you would rather not learn from an extortion note which of your portals answers questions it should not, that is the review to book this quarter. Talk to an expert and we will start with the inventory.
Frequently Asked Questions
No. FINRA states that available evidence does not indicate exploitation of a software vulnerability within Dynamics 365 itself. Separately, no CVE has been assigned to this campaign, and the DFPI alert names no vulnerability either. Both alerts describe a customer configuration and permissions problem, which means no Microsoft update resolves it. The remediation is a change to your own portal settings.
No. The California DFPI alert is addressed to registered investment advisers and broker-dealers, and the FINRA alert is addressed to member firms using Microsoft Dynamics 365 or Power Pages. Neither names banks, credit unions, or mortgage companies. The reason the alerts still matter to those institutions is that the exposure is a property of Power Pages portal configuration rather than of firm type, so any borrower, member, or broker portal built on the same technology can carry the same permission.
In Power Pages, a web role represents a category of visitor, and the Anonymous Users role represents a visitor who has not signed in. Table permissions grant access to Dataverse data and take effect only when they are associated with a web role. When a table permission is attached to the Anonymous Users role, the data that permission covers can be read by an unauthenticated visitor through the portal's web interface. FINRA describes this as the specific relationship the attackers targeted.
The opposite. Microsoft's documentation states that access to Dataverse records is automatically restricted in Power Pages, and that to allow access you need to configure table permissions and associate them to web roles. Access is denied until someone grants it. That makes this a governance question about who can change portal permissions and who reviews those changes, rather than a question about product defaults.
Fortra's Intelligence and Research Experts assessed approximately 27 million records across 13 organizations published by the extortion group, spanning government, education, financial services, and manufacturing, as reported by Infosecurity Magazine in August 2026. That figure belongs to Fortra's research rather than to either regulator, and it describes data that was published rather than a confirmed accounting of every victim's full breach scope. Separately, FINRA cites more than 10,000 potentially vulnerable public-facing Power Pages instances, which is a measure of exposed surface and not a count of firms that were compromised.
Two things. First, verify the assumption rather than accepting it, because Power Pages sites are often created by a business unit or an implementation partner rather than by the group that manages the tenant, and a portal from a retired project can outlive the project. Second, the underlying pattern is not specific to Power Pages. Any permission that was granted once to make something work, and never reviewed afterward, carries the same risk of quietly outliving its purpose.