City-Forum Campaign Scrapes Salesforce and ServiceNow Guest Portals

SaaS security firm Reco is tracking an ongoing data-theft campaign it named City-Forum, after the city-forum.com domain on the attacker's box. BleepingComputer's August 12, 2026 report, updated August 14 with a ServiceNow statement, is the public account this briefing uses. The campaign steals records that guest users can already see on Salesforce Experience Cloud and ServiceNow Service Portals. It is not a platform zero-day.

The same fingerprint hits both vendors, across telecom, banks, enterprise software, security firms, and public-sector portals. Reco says it is still running and the volume is climbing. ServiceNow told BleepingComputer there is no compromise of the ServiceNow environment itself.

What happened

Every request Reco published traces to one IPv4 address, 158.220.87.79, on a Contabo VPS in Germany (ASN 51167). Almost every request uses the default Go-http-client/1.1 user agent. That IP has resolved from city-forum.com since at least March 2025 — more than a year on the same box. Reco has only seen guest-user activity, never an authenticated session, and says it cannot rule the latter out.

On Salesforce the busiest target logged more than 560,000 events from that IP, nearly all guest Aura enumeration. The actor first calls HostConfigController.getConfigData to list objects the guest can see, then SelectableListDataProviderController.getItems to pull Accounts, Contacts, Cases, and whatever else sharing rules left open. On newer Lightning Web Runtime sites the same actor uses the UI API over GraphQL at /webruntime/api/services/data/{version}/graphql. Reco had not seen public tools (AuraInspector, S-RET, CirrusGo) use that webruntime path.

Who is exposed

Any org that gave Experience Cloud or ServiceNow guest users object, field, file, or search-source access they did not mean to grant. That is a configuration problem, not a Salesforce or ServiceNow CVE. ShinyHunters used similar Aura guest abuse before; Reco says there is no evidence tying City-Forum to that group, and the year-stable single IP is unlike ShinyHunters' rotating infrastructure.

ServiceNow hits go to POST /api/now/sp/search?sysparm_cancelable=true, the Service Portal search endpoint Reco had not previously seen abused. One environment grew from tens to hundreds of those requests per day. Transaction logs record that automated searches happened and how much came back; they do not record the POST body, so defenders cannot recover the exact search terms. The actor also probes Salesforce /SiteRegister and /CommunitiesSelfReg to see if a guest can self-register into a broader external account.

What to do now

Hunt 158.220.87.79 and the Go-http-client/1.1 user agent in Salesforce Event Monitoring and ServiceNow transaction logs. Reco's blog is the IOC sheet. Review guest-user sharing rules, object and field permissions, file access, member visibility, and self-registration. On LWR sites, turn off the Experience Builder option that lets guest users hit public APIs if you do not need it.

On ServiceNow, review which search sources the Service Portal exposes and require authentication on anything that can return customer, HR, or case data. ServiceNow asked customers with configuration questions to open a support case. Do not treat a clean authenticated-user report as a clean guest-user report — Reco has only claimed the latter so far.

How the issue works

Salesforce Experience Cloud and ServiceNow both have guest identities so a portal can render without a login. If those identities can read records, anyone on the internet can retrieve them through documented APIs. City-Forum is a compiled Go client that walks those APIs at scale. On Aura it enumerates, then pages. On LWR it asks GraphQL. On ServiceNow it varies search terms against the portal search endpoint.

Nothing in Reco's public account requires a stolen password or a Salesforce/ServiceNow patch. The write primitive is the customer's sharing rule. That is why ServiceNow's statement and Reco's technical story can both be true: the vendor platform is not owned; the tenant's guest configuration is being read.

What is still unknown

Reco has not published a victim count or a full sector-by-sector list beyond the categories BleepingComputer repeated. Authenticated access has not been observed and has not been ruled out. There is no public attribution beyond the city-forum.com / 158.220.87.79 pair. Whether the actor is selling the data, extorting, or stockpiling is not in the source material.

Watch Reco's follow-ups, Salesforce Event Monitoring for webruntime GraphQL from that IP, and ServiceNow search volume that has no matching human session. If you brief this, lead with the guest-share review and the one IP. That is the decision. The rest is Reco and BleepingComputer.