The Night Shift: Overnight Tech News with Jennifer Hudsen • 9:00 p.m. edition • Cutoff September 8, 2026, 9:28:22 p.m. EDT / September 9, 2026, 01:28:22 UTC
Image disclosure: The featured image is original synthetic Jennifer newsroom concept art about reviewing cloud access controls. It is not Microsoft or regulator media, not an incident photograph, and not a real software interface.
California’s Power Pages warning is about exposed permissions—not a new Microsoft flaw
Status at cutoff: California’s financial regulator has told registered investment advisers and broker-dealers to check Microsoft Power Pages and Dataverse access settings after warnings that threat actors are using overly broad anonymous permissions for data extortion.[1] The strict-window trigger for this Night Shift issue is the Google News RSS metadata timestamp 2026-09-08T23:34:21Z attached to the DFPI alert; the underlying ExfilSquad research and reported campaign predate this window.[2][6]
What happened
On September 8, the California Department of Financial Protection and Innovation published “Threat Actors Exploiting Microsoft 365 Power Pages Misconfigurations to Target Financial Services Firms.” The alert says improperly configured Power Pages portals can allow unauthorized access to firm data held in Microsoft Dynamics 365, including customer and employee personally identifiable information, and that extortionists may threaten public disclosure unless demands are met.[1]
The crucial qualifier is in the regulator’s own notice: this is not described as a software vulnerability in Microsoft 365. The reported access comes from how a customer’s Power Pages portal and associated permissions were configured.[1] FINRA separately warns member firms that ExfilSquad has targeted Dataverse table permissions that gave the Anonymous Users web role overly broad read access, while saying available evidence does not indicate exploitation of a Dynamics 365 software vulnerability or classic network-level ransomware activity.[3]
That distinction changes the defensive job. A patch cycle alone will not correct a permission that intentionally tells a public portal to return records to an unauthenticated visitor. Microsoft’s documentation says table permissions are associated with web roles and states plainly that, when the Anonymous Users role is granted access to a table, anyone visiting the site can access that table’s data.[4]
Why it matters
Power Pages is used to create external-facing sites connected to Microsoft Dataverse.[6] That makes it useful for customer, partner, applicant and public-service workflows—but it also means a portal’s authorization choices can sit directly in front of business records. VenariX reported reviewing samples associated with 11 of 15 organizations named by ExfilSquad; all 11 had structures and field formatting consistent with Dataverse exports.[6] The researchers also said those samples appeared to be partial, so the total number of affected records could not be determined from the evidence they had.[6]
The exposed categories VenariX observed included personal identifiers, financial and banking information, employee and organizational data, customer and CRM records, support cases and some medical or public-service details.[6] Those findings do not prove that every Power Pages site is exposed, that every claimed victim was reached through the same route, or that every financial firm received the same data request. They do show why a configuration review is more than housekeeping when a public portal is connected to sensitive records.
Anonymous reads can also produce a quieter signal than a stolen-account intrusion. FINRA tells potentially exposed firms to look for anomalous unauthenticated browser or API requests, bulk or high-volume Dataverse queries and unexpected access to sensitive tables, and to preserve current configuration snapshots and logs before remediation.[3] In other words, identity controls remain important, but they cannot substitute for checking what the application deliberately permits before sign-in.
Who is affected
The immediate audience is narrow and identifiable: DFPI addresses registered investment advisers and broker-dealers, while FINRA addresses member firms that use—or may unknowingly rely on—Microsoft Dynamics 365 or Power Pages.[1][3] The technical exposure, however, is not limited by industry. VenariX’s reviewed claims spanned private companies, municipalities, schools and government bodies.[6]
Within an organization, the responsible group may include the Power Platform administrator, portal maker, Dataverse owner, security team, privacy counsel and any managed service provider that maintains the site. Customers and employees are potentially affected only when their information sits in a table that was actually readable beyond its intended audience; the alerts do not establish that every firm using these products has been compromised.[1][3]
What owners should do now
The following is a defensive, owner-authorized review—not an invitation to probe other organizations’ portals.
- Confirm your inventory and owners. Determine whether your organization or its providers operate Power Pages, legacy Power Apps portals or Dynamics 365 environments that publish Dataverse-backed content. FINRA specifically tells uncertain firms to determine promptly whether they use either platform.[3]
- Preserve before changing. Export or capture current table permissions, web roles, relevant site settings and available audit logs before remediation, following your incident-response process. FINRA says those snapshots and logs may matter for investigation and regulatory purposes.[3]
- Review table permissions one table at a time. In the Power Pages security workspace, identify every permission assigned to the Anonymous Users web role and compare it with an approved business requirement. Microsoft says anonymous assignment makes that table’s data visible to anyone; remove unintended access rather than assuming a public page is harmless.[4]
- Minimize reachable data. Restrict public access and web access to operationally necessary tables and fields. For public intake workflows, assess whether anonymous users need to submit information without being able to read existing records; VenariX recommends limiting anonymous users to create-only behavior where retrieval is not required.[1][6]
- Use governance controls deliberately. Microsoft provides tenant controls that can disable anonymous access for specific sites, all sites except approved exceptions, or all sites. The control blocks unauthenticated viewing of Dataverse data while still permitting unauthenticated writes, which can preserve some feedback or intake use cases.[5] Test the business process before a broad rollout so a protective change does not unnecessarily break a legitimate public service.
- Validate only assets you own or are authorized to test. From a clean, signed-out session, confirm that your own restricted portal no longer returns record data and that intended public submission paths still work. Do not scan, enumerate or test third-party domains. If access still succeeds, stop and escalate to the site owner or incident-response lead rather than extracting records.
- Review evidence and response duties. Enable appropriate Dataverse auditing and activity logging, examine retained records for unusual anonymous or high-volume access, and involve security, legal and privacy teams if exposure is suspected. DFPI urges firms to report cybersecurity incidents through its incident-reporting channel.[3][1]
Upside, cautions and unknowns
Upside: The public evidence points to a remediable authorization problem, not a newly disclosed Microsoft product flaw requiring customers to wait for a patch. Microsoft already exposes per-table controls and tenant-level governance options for anonymous access.[4][5]
Cautions: “Misconfiguration” does not mean low impact. If a sensitive table was publicly readable, removing the permission closes future access but does not determine what was previously collected. Preserve evidence first, investigate historical activity and avoid treating successful remediation as proof that no disclosure occurred.[3]
Unknowns: VenariX found support for at least part of ExfilSquad’s claims, but did not confirm that every named organization was affected through Power Pages or the same configuration issue.[6] Public sources reviewed by the cutoff do not establish a complete victim count, a complete record count, or that every DFPI- or FINRA-regulated firm using these services was breached.
Timeline and evidence
| Time | What the evidence shows | Why it belongs here |
|---|---|---|
| July 26, 2026 | VenariX says ExfilSquad was first observed after naming 15 alleged victims.[6] | The campaign predates tonight’s news window. |
| July 29; updated August 10 | VenariX published and later updated its technical assessment, reviewing samples tied to 11 claimed organizations and warning that one common route was likely, not proven for all.[6] | Research foundation and uncertainty boundary. |
| FINRA alert, publication date not displayed on the live page | FINRA warned member firms about the same configuration-led extortion pattern and issued mitigation guidance.[3] | Financial-sector corroboration; no invented timestamp. |
| September 8, 23:34:21 UTC | Google News RSS attached this metadata timestamp to the DFPI alert.[2] | This is the strict-window trigger, not the campaign’s start time. |
| September 9, 01:28:22 UTC | Reporting cutoff after final source recheck. | No later developments are included. |
Frequently asked questions
Is this a Microsoft zero-day?
No public source reviewed here describes a zero-day. DFPI says the threat stems from configuration choices, not a vulnerability within Microsoft 365, and FINRA says available evidence does not indicate exploitation of a Dynamics 365 software vulnerability.[1][3]
Does a public Power Pages site automatically expose private data?
No. Public visibility can be intentional. The risk arises when table permissions assigned to anonymous users grant access beyond the records and actions the site is meant to expose.[4]
Should every organization disable all anonymous access?
Not blindly. Microsoft’s governance control supports site-specific and exception-based policies, and it can preserve anonymous writes even while blocking anonymous reads.[5] Owners should choose the narrowest safe configuration that meets the approved workflow, then test it.
Can we check another company’s portal to see whether it is exposed?
No. Limit validation to assets you own or have explicit authorization to assess. If you encounter another party’s exposed data unintentionally, do not browse, download or attempt to prove scope; notify the responsible organization through an appropriate channel.
Does removing anonymous read access close the incident?
It can close the configuration path, but it does not answer whether data was previously accessed. Preserve evidence, review logs and follow incident, legal, privacy and regulator-notification procedures appropriate to your organization.[3][1]
Sources
- California DFPI — “Threat Actors Exploiting Microsoft 365 Power Pages Misconfigurations to Target Financial Services Firms”, September 8, 2026.
- Google News RSS exact-title search, metadata timestamp Tue, 08 Sep 2026 23:34:21 GMT.
- FINRA — “Cybersecurity Alert: Threat Actors Actively Targeting Financial Services Firms via Microsoft Power Pages Misconfiguration”, live page checked at cutoff; no publication date displayed.
- Microsoft Learn — “Assign table permissions”, last updated July 25, 2024.
- Microsoft Learn — “Use governance controls to disable anonymous access”, last updated October 7, 2025.
- VenariX — “ExfilSquad Targets Misconfigured Microsoft Power Pages Portals”, July 29, 2026; updated August 10, 2026.
Reporting cutoff: September 8, 2026, 9:28:22 p.m. EDT / September 9, 2026, 01:28:22 UTC. This article covers one subject and does not claim that the ExfilSquad campaign began tonight.