One VPS, Seventeen Months, No Rotation: The City-Forum Portal Harvest

A single virtual private server has spent at least seventeen months reading whatever Salesforce Experience Cloud and ServiceNow portals hand out to anonymous visitors, and SaaS security firm Reco says the volume is still climbing ^[1][4][7]. Nothing was exploited: according to Reco, every byte the attacker retrieved was something a site owner had exposed to unauthenticated users through overly permissive sharing rules, permissions, or portal configuration ^[8][26].

The infrastructure discipline is the first thing worth noting, because there is none in the usual sense. Reco reports that all of the activity comes from 158.220.87.79, hosted by German VPS provider Contabo, almost always with the default Go-http-client/1.1 user agent ^[2]. That address has carried the city-forum.com domain since at least March 2025 and has never rotated ^[3][4]. Seventeen months from March 2025 puts the observed activity into roughly August 2026 ^[5]. SecurityWeek notes the trade-off Reco itself declines to draw: one box is trivial to block once known, and quieter than a rotating fleet until then ^[24].

The mechanism is configuration, not a bug. Both platforms use guest accounts to handle unauthenticated visitors, and if those accounts can read records, so can anyone on the internet via the API ^[27]. Reco's phrasing is blunt: you cannot delete those guest users, and requiring login does not remove them, because the profile, its permissions, its sharing rules, and any code running in its context all still exist ^[9].

On Salesforce Aura sites, the attacker calls HostConfigController.getConfigData against /aura or /s/sfsites/aura to enumerate which objects the guest can see, then pulls records with SelectableListDataProviderController.getItems ^[10]. The busiest single target logged more than 560,000 events from that IP, essentially all guest Aura enumeration ^[11]. The newer part is Lightning Web Runtime: Reco describes GraphQL requests to /webruntime/api/services/data/{version}/graphql as the first observed in-the-wild abuse of Salesforce's UI API guest surface, and says no public tool, including AuraInspector, S-RET or CirrusGo, touches the webruntime interface ^[12][13]. The same operator probes /SiteRegister and /CommunitiesSelfReg to see whether self-registration is on, which would let a guest promote itself to an authenticated external account with broader access ^[14]. ServiceNow has no equivalent path ^[15].

On ServiceNow, the target is POST /api/now/sp/search?sysparm_cancelable=true, the portal search endpoint, which accepts anonymous requests and returns data where search sources permit guest access ^[16]. Reco says it had not previously seen this abused, and that in one environment request volume grew from tens to hundreds per day ^[16][17]. There is a forensic hole here: ServiceNow transaction logs do not record the POST body, so defenders can see that automated searches ran and how much data came back, but not what was searched for ^[18].

Reco says one Go binary hit Salesforce over both Aura and LWR and hit ServiceNow from the same box, consistent with a custom toolset rather than off-the-shelf tooling ^[20]. Targets span telecoms, banks and financial services, enterprise software vendors, security and privacy firms, and public-sector portals ^[6]. ShinyHunters ran comparable Aura abuse with a modified AuraInspector, per both reports, but Reco says there is no evidence tying City-Forum to that group and is ruling nobody in or out ^[21][22].

Watch three things: whether authenticated activity ever appears alongside the guest traffic, which Reco has not yet seen but will not exclude ^[19]; whether the webruntime GraphQL technique shows up in public tooling now that it is documented ^[13]; and whether ServiceNow starts logging POST bodies for that search endpoint ^[18].