A single attacker has spent the past seventeen months quietly pulling data out of Salesforce and ServiceNow customer portals. The targets span banks, telecoms firms, software vendors and public sector bodies. No exploit was needed. The attacker simply asked for records that the sites’ own guest user permissions were configured to hand over.
Researchers at Reco, a SaaS security firm, disclosed the campaign on 12 August 2026. They named it “City-Forum” after a domain, city-forum.com, tied to the attacker’s infrastructure. The IP address behind it, 158.220.87.79, has pointed at that domain since 12 March 2025. It hasn’t moved since. One target alone logged more than 560,000 requests from it.
Table of Contents
What the attacker actually did
City-Forum targets two things most Salesforce and ServiceNow customers treat as an afterthought: the permissions handed to unauthenticated guest users on public-facing sites.
On Salesforce, the tool works the Aura framework. It calls internal controllers such as HostConfigController.getConfigData and SelectableListDataProviderController.getItems to find every object the guest profile can see, then walks through them one by one. It also reaches into Salesforce’s newer Lightning Web Runtime sites through an undocumented API path. The tool sweeps API versions v56.0 through v66.0 in order, a technique Reco says has no public write-up anywhere. On ServiceNow, it hits the native /api/now/sp/search endpoint on Service Portals. It varies its search terms to pull back whatever the guest-facing search index exposes. In one environment, daily requests climbed from the tens into the hundreds.
“The same fingerprint appears against both Salesforce and ServiceNow, across multiple organisations worldwide,” Reco’s research team wrote. “It is still running, and the volume is climbing.”
Nitay Bachrach, senior security researcher at Reco, said the attacker “created their own toolset, based on research and techniques which are not well documented online.” That matters. This is not a script kiddie running a known scanner. It’s custom-built, patient reconnaissance against infrastructure most security teams never think to check. Nothing about it looks broken.
No CVE: this is a guest user permissions problem
ServiceNow’s statement on the campaign put it plainly: “We can confirm there is no compromise of the ServiceNow environment.” That is technically true and beside the point. City-Forum doesn’t exploit a flaw in either platform. It exploits guest user permissions that the customer, not the vendor, configured too loosely. Overshared objects, exposed fields and search indexes that answer questions from anyone who asks.
Both Salesforce and ServiceNow enforce guest access exactly as it’s set up. If a guest profile can read a field, the server will return it to anyone who requests it, researcher or attacker alike. Reco confirmed this directly: everything the tool pulled back matched the sharing rules and field-level security already in place. The platforms worked as designed. The design just wasn’t safe.
Why this should worry more than the affected sectors
Telecoms, banks, security vendors and public bodies made Reco’s list, but the underlying weakness has nothing to do with sector. Any organisation running a Salesforce Experience Cloud site or a ServiceNow Service Portal carries the same risk, whether it’s used for customer self-service, partner access or a public knowledge base. The risk exists if guest user permissions were never reviewed after go-live.
That’s the pattern penetration testers see constantly. It’s the same broken access control weakness OWASP has put at the top of its list for years. A portal gets built and guest access gets switched on to make the self-service flow work. Nobody revisits the permission set once the project ships. Two years later it’s still wide open, quietly answering questions from a Go binary running out of a German VPS provider. Nobody notices, because there was never an alert to trigger. No credentials were stolen. No login ever happened. The traffic looks, on paper, exactly like a guest is meant to look.
Reco found no link between City-Forum and known groups such as ShinyHunters. It stressed that only guest, unauthenticated activity has been confirmed so far, and abuse of authenticated sessions on the same portals hasn’t been ruled out. Given the campaign has run undetected for over a year, that caveat is worth taking seriously rather than filing away.
What to check now
On Salesforce: review guest-user sharing rules and strip object and field-level permissions the public site doesn’t need. Disable the “Access Activities” permission for guests. Turn off self-registration unless it’s actually required. Switch off guest file access and member visibility. In Experience Builder, uncheck “Allow guest users to access public APIs” unless something depends on it.
On ServiceNow: map every public Service Portal to the search sources it uses and detach anything unnecessary. Confirm scripted search sources gate on gs.isLoggedIn() and use GlideRecordSecure. Check Knowledge Base read criteria for articles still set to “Any User” that shouldn’t be. Where anonymous search isn’t a business requirement, require login.
None of this needs a maintenance window or a vendor patch. It’s a guest user permissions review, and for most organisations it’s overdue.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
