Original OrbTrail analysis expanded with complementary research, practical context and verified references.
A campaign tracked by Reco and disclosed on August 12 changes an important assumption in Salesforce portal defense. The actor named City‑Forum uses custom tooling against Experience Cloud sites built on both Aura and Lightning Web Runtime (LWR), as well as ServiceNow portals. Infrastructure associated with the main indicator has existed since March 2025, and observed activity is still increasing. At one target, researchers recorded more than 560,000 events tied almost entirely to Aura enumeration as a guest user. That figure does not mean 560,000 victims or stolen records; it is an event count from one analyzed environment and should be communicated with that precision.
The central issue is less comfortable than a newly discovered vulnerability. According to Salesforce and the independent research, requests execute as the site's persistent guest user and receive only what object permissions, sharing, field security and public settings allow. Published evidence does not show an authentication bypass or inherent platform defect. The problem is that a page that looks correct can coexist with a larger data surface than an administrator sees in the browser. The operational question is therefore: how can a team prove that every anonymous path—page, Aura, UI API, GraphQL, Apex, files and self-registration—returns only information intentionally made public?
Aura and LWR are separate surfaces
Aura exposes /aura requests; LWR uses UI API and GraphQL. Testing one framework leaves the other without evidence.
The guest user defines the response
Objects, records, fields, files and code running anonymously must be tested as a real external identity.
Logs connect pattern to outcome
AuraRequest and Sites expose IP, user agent, actions and version sweeps; the access inventory shows what could be read.
Close excess without erasing the journey
Remove unnecessary APIs and permissions, preserve only tested public cases and monitor again after each change.
Aura and LWR reach the same data through different paths
In Aura, the observed tool queries /aura or /s/sfsites/aura. Reconnaissance uses getConfigData to identify objects reachable in the guest context; getItems then pages through records for candidate objects. The technique was known from earlier campaigns, but remains relevant because many portals still use Aura. The defensive signal is not one URL: it is the combination of guest identity, volume, action sequence, unexpected objects, source IP and a user agent inconsistent with human browsing.
In LWR, /aura is disabled, but the data layer lives under /webruntime/api/services/data/{version}. Researchers found GraphQL calls to UI API, including a sequence testing versions v56.0 through v66.0. Object, field and record permissions are still enforced; risk arises when they authorize more than the public journey needs. This defeats two false assurances: moving to LWR does not remove anonymous authorization risk, and an Aura scanner finding nothing does not prove the site is secure.
Closed page, open API: three controls that look equivalent but are not
Page visibility in Experience Builder, the guest profile's API Enabled system permission and the Allow guest users to access public APIs preference govern different surfaces. Reco warns that removing API Enabled alone does not close LWR UI API; the public APIs preference specifically controls GraphQL and UI API REST. Salesforce guidance recommends disabling both when they are not required. Requiring login for navigation also does not delete the guest user, its sharing rules or code that may still execute in anonymous context.
Self-registration creates a fourth boundary. The campaign tested paths such as /SiteRegister and /CommunitiesSelfReg to learn whether a visitor could create an external account and reach broader permissions. Disabling the capability where there is no requirement is straightforward. Where it is necessary, the handler should honor sharing, assign the most restrictive profile, verify email and prevent guest-collected data from selecting an improper account or relationship. Testing must cover the state before and after registration, not merely the sign-up screen.
A useful audit starts at zero and rebuilds every public need
Salesforce describes four sequential layers: object access, record access, field-level security and field-value masking. Review should begin with the guest profile for each site because every Experience has its own anonymous identity. For every readable object, record which component or process needs it, which records must be public, which fields are rendered, and whether attachments, activities, users or documents enter through relationships. If there is no journey and accountable owner, remove access before selectively restoring an explicit scope.
Clicking through pages is not enough. Use an unauthenticated session to exercise pages and forms, but also validate public API responses, custom components, Flows and Apex running for the guest. Place synthetic marker data in a sandbox to determine which layer exposed a field. Negative cases are essential: another record's ID, an empty filter, broad pagination, a hidden field, a related file and a validation error. The evidence is easy to state and difficult to fake: the visitor receives the minimum through every path, not only the happy-path interface.
Hunting must combine indicators, behavior and possible access
Reco published an IP, domain, user agent and request signatures associated with the campaign. They enable an initial hunt but do not finish the investigation because infrastructure and tooling can change. In Event Monitoring, AuraRequest and Sites event types help locate getConfigData, getItems, /webruntime/ calls, consecutive version sweeps and self-registration probes. Salesforce recommends looking for query spikes, objects that should not be public, unfamiliar sources and abnormal hours. Request-level Event Monitoring requires Salesforce Shield or the standalone add-on, so a licensing gap belongs in residual risk.
Finding a signature proves activity, not necessarily exfiltration; not finding it proves only that the indicator did not appear in available logs. Investigation should correlate requests with the historical state of guest permissions, sharing rules, FLS, API preferences, files and self-registration. If an object was accessible, estimate which records and fields could have been queried and preserve logs before retention expires. Blocking the IP reduces immediate pressure, but neither repairs the exposure nor detects another address using the same technique.
Conclusion: public access is a data API even when the project is managed as a website
City‑Forum does not change the security principle; it proves attackers have automated paths beyond familiar Aura checks. The safer plan is to inventory every site and framework, disable APIs and self-registration where unnecessary, rebuild guest access by journey, test negative outcomes and retain behavioral detection. Publishing a portal also publishes a technical identity and a set of data contracts. Review needs an owner, cadence and regression suite because a new page, Flow, rule or field can reopen exposure without changing how the portal looks.
