The Guest User Nobody Was Watching

A single rented server in Germany has been reading records out of Salesforce Experience Cloud sites and ServiceNow Service Portals since March 2025. One Salesforce environment logged more than 560,000 requests from its address. No vulnerability was involved at any point, and every record it collected was one the site owner had already made readable to the guest user.

SaaS security firm Reco published the research on Wednesday and called the campaign City-Forum. Salesforce Ben, BleepingComputer, SecurityWeek and The Register picked it up inside a day.

Seventeen Months From One Address

The name comes from city-forum.com, a domain registered in 2002, abandoned, and now pointed at a generic VPS at a German hosting provider. Everything in the campaign comes from one IP, 158.220.87.79, sitting on Contabo's network with a reverse DNS name that gives away the box it runs on.

There is no rotation. No proxy pool, no residential exit nodes, no attempt to spread requests across ranges. The user agent is Go-http-client/1.1, which is what the Go standard library sends when nobody bothers to change it. The same address has been running the same operation for at least seventeen months.

The targets read like a list nobody would pick at random: telecommunications carriers, banks and financial services firms, enterprise software vendors including security and data-privacy companies, and public-sector portals. Whoever runs this went after organisations whose portals hold something worth reading.

That is the part that should bother you. Seventeen months of steady collection against companies that sell security software, from an address that never once tried to hide.

What It Did to Aura

Most of the volume went at classic Experience Cloud sites built on Aura, and the technique is old enough to have a name in the community.

The requests hit /aura or /s/sfsites/aura and call two controllers. HostConfigController.getConfigData returns the site's configuration, which includes the list of objects the guest user can see. Then SelectableListDataProviderController.getItems pages through the records of those objects. Accounts, Contacts, Cases, whatever the guest profile was granted.

Nothing here is exotic. The first tools that did this shipped years ago. What is different is patience: one target logged over 560,000 of these events from a single address, which is not a scan, it is a harvest.

Alongside that, the same client probed /SiteRegister and /CommunitiesSelfReg on every site it found, checking whether self-registration was switched on. A site that lets anyone create an account is a site where the guest surface is only the first step.

The Part Nobody Had Seen Before

The Aura activity is familiar. The LWR activity is not.

On sites built with Lightning Web Runtime, the client went at the UI API through the runtime proxy: POST /webruntime/api/services/data/{version}/graphql, plus ui-api/object-info and ui-api/records calls, with asGuest=true in the query string. It swept API versions from v56.0 up to v66.0 to find one the site would answer on, then used GraphQL to enumerate entity definitions and pull records.

Reco describes this as the first time anyone has publicly observed the Salesforce UI API guest surface being used this way in the wild. There is no open-source tool for it. Whoever built this read the platform documentation and wrote their own client, a single compiled Go binary that speaks to both Salesforce and ServiceNow from the same machine.

The LWR traffic is thin, a few requests per API version per subsite. That reads like reconnaissance rather than collection, which is worse news than heavy volume would be. It means someone is mapping a surface that most orgs have never audited, on the newer framework Salesforce has been steering everyone toward.

The ServiceNow Half

The ServiceNow side uses POST /api/now/sp/search, the endpoint behind the search box on a Service Portal. It is native, it is undocumented in any meaningful sense, and it accepts anonymous requests whenever the underlying search source permits guest access.

Reco's write-up shows why two sources on the same portal behave differently. The service catalogue source carries an explicit gs.isLoggedIn() check and returns nothing to an anonymous caller. The knowledge base source has no such gate and defers entirely to the "Can Read" user criteria on each article. A criteria record left with empty scoping fields resolves to any user, and any user includes the internet.

On one environment, request volume climbed from tens per day to hundreds. ServiceNow told The Register it is aware of the research, noted there is no allegation of a compromise of the ServiceNow environment itself, and said it is investigating.

Salesforce Is Right, And That Is the Problem

Salesforce's response, given to BleepingComputer, is that the platform remains secure and the issue is not caused by any vulnerability in it. That statement is accurate. The guest user returned exactly what its profile, its permissions and its sharing rules said it could return. The platform did its job.

The uncomfortable part is what follows from that. If nothing is broken, nothing gets patched. There is no CVE, no hotfix, no Trust notification, no forced upgrade weekend. The fix ships as a configuration review that somebody in your org has to schedule and run, and configuration reviews lose to release deadlines every time.

This is the same shape as the Klue OAuth incident in June, where a dormant token belonging to a third party was the whole attack. In both cases the platform behaved correctly and the customer's data still left the building. Shared responsibility is a fair model. It is also a model where the responsibility that gets neglected is the one nobody sends a reminder about.

Why "Require Login" Does Not Close This

The single most common wrong answer to this problem is that the site requires login, so the guest user does not matter.

Every Experience Cloud site has a guest user. You cannot delete it. Turning on a login requirement changes which pages render publicly; it does not remove the profile, the sharing rules attached to it, the field-level security on that profile, or the Apex that runs in guest context. The API endpoints above sit at the site's domain and answer requests based on those settings, not on whether a human visitor would ever reach a page.

The same logic applies to sites you forgot about. A pilot community from 2021 that nobody deactivated still has a domain, a guest profile, and whatever sharing rules were expedient during the pilot. City-Forum found sites by enumeration, not by invitation.

What To Check In Your Org Tonight

Reco's remediation list is specific, and none of it needs a change request.

Start with the guest profile itself. Remove object read on anything the public does not need, then do the same at field level, because a guest with read on Contact and no field trimming hands out phone numbers and email addresses. Turn off the Access Activities permission. Review every guest sharing rule and delete the ones written to make a demo work. Revoke guest access to files and to other members' visibility.

Then handle self-registration. If your site does not need it, switch it off, and confirm the answer rather than assuming it, because the campaign specifically probed for it.

On LWR sites, the one setting most teams have never opened is in Experience Builder under Workspaces, Administration, Preferences: Allow guest users to access public APIs. Unchecking it closes the GraphQL and UI API surface described above. It is a separate control from the API Enabled permission and from page visibility, which is why an org can look hardened and still answer these calls.

If you also run ServiceNow, map each guest-facing portal to its search sources, add a login check to any scripted source that lacks one, swap GlideRecord for GlideRecordSecure so ACLs apply, and hunt for knowledge base user criteria with empty scoping fields. Detach shared criteria records rather than editing them, or you will change behaviour for portals you were not looking at.

Attribution, Or the Lack of It

Reco declined to name anyone, saying only that they do not know who this is and are not ruling anyone in or out. The method resembles the ShinyHunters activity that hit around 100 companies earlier this year, but the operational style does not match. ShinyHunters ran across many systems and rotating ranges. This is one box, one address, seventeen months, no attempt at concealment.

Treat the absence of attribution as the useful signal. The barrier to entry here is a documentation read and a Go binary, and that is available to anyone.

Also This Week

Winter '27 pre-release org signups open today, August 13. Release notes publish August 19, sandbox previews land around August 29, and production upgrade weekends run August 29, October 3 and October 10.

Salesforce Ben also published data from Crustdata on boomerang hiring: roughly one in eighteen new Salesforce hires in 2025 had worked there before, up from one in thirty-six in 2022. About 3,420 current employees are returners, and the median time away before coming back is two years.

Salesforce reports second quarter fiscal 2027 results after the close on Wednesday, August 26.

What To Do Next

Open Setup, list every Experience Cloud site in the org including the deactivated ones, and for each guest user profile export the object and field permissions plus the sharing rules pointed at it. Then open your event log or gateway logs and search for requests to /aura and /webruntime/api/services/data/ from outside your corporate ranges. You are looking for one client hitting the same endpoints on a schedule, not a spike. If the export shows a guest user that can read a record you would not publish on your homepage, fix that today and worry about who has been reading it afterwards.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.