City-Forum Campaign Raids Salesforce and ServiceNow Portals via Guest Misconfigurations

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · SaaS security, cloud architecture, enterprise integrations

The short answer

What is City-Forum?

Reco, a SaaS security company, tracked a sustained scraping campaign they named City-Forum after the attacker's infrastructure: the domain city-forum.com, which has pointed to IP 158.220.87.79 on Contabo's German VPS network since March 2025. All observed requests use the default Go-http-client/1.1 user agent, suggesting a single operator running custom Go tooling with no attempt to blend into legitimate traffic.

The campaign's premise is straightforward: if a Salesforce or ServiceNow portal allows guest users — unauthenticated visitors — to read certain records, those records are accessible to anyone who knows the right endpoints. City-Forum systematically discovers and harvests those records at scale. According to Reco researcher Nitay Bachrach, "If the guest can read a record, so can anyone on the internet. That is not a platform vulnerability."

The campaign has been running for at least a year with no public documentation until this month. The low-profile user agent and the absence of a CVE meant it did not appear in typical vulnerability scanners or patch alerts, leaving affected organisations unaware their portals were being harvested.

How the Salesforce attack works

Salesforce Experience Cloud, formerly Community Cloud, lets organisations build customer- and partner-facing portals on top of their org's data. Guest users — people who access the portal without logging in — can be granted access to specific objects and records through sharing rules. When those rules are too broad, a guest user effectively sees what any internet visitor sees: a curated slice of your CRM data.

City-Forum targets two Salesforce portal runtimes. On sites running the legacy Aura framework, the attacker sends high-volume POST requests to the /aura and /s/sfsites/aura endpoints, invoking controllers such as HostConfigController.getConfigData to map the accessible data model and SelectableListDataProviderController.getItems to extract records in bulk. On newer Lightning Web Runtime (LWR) sites, the attacker queries the GraphQL layer at /webruntime/api/services/data/{version}/graphql — a technique Reco describes as absent from previously published research and tooling.

An additional check probes whether the portal allows self-registration via /SiteRegister or /CommunitiesSelfReg. If it does, the attacker could escalate from anonymous guest access to a legitimate external account, significantly broadening what is accessible.

How the ServiceNow attack works

ServiceNow's Service Portal is a common interface for customer support and IT self-service. Its native search endpoint, POST /api/now/sp/search?sysparm_cancelable=true, accepts queries and returns matching records from configured sources. In many default Service Portal deployments, this endpoint does not require authentication — a fact that City-Forum exploits by querying it for any data exposed to anonymous users.

Reco notes that this endpoint "has received little public attention," which partly explains why it remained an active attack surface for over a year. WAF rules and SIEM detections focused on known Salesforce endpoints would not have flagged ServiceNow portal search traffic.

Who is targeted?

Reco observed City-Forum activity across five categories: telecommunications companies, banks and financial services firms, enterprise software vendors, cybersecurity companies, and public-sector portals. The common thread is an internet-facing portal with permissive guest settings — the specific industry is secondary. Any organisation that deployed a Salesforce Experience Cloud site or ServiceNow Service Portal and left default guest-user permissions in place is a potential target.

The volume can be substantial. The busiest single Salesforce target logged over 560,000 events from the attacker's IP. At that scale, data exfiltration is not incidental — it is systematic. For regulated industries, the exposure is not limited to operational inconvenience: if the harvested records contain personal data, a Reco finding is also a data-incident notification obligation under GDPR Article 33 and, for US health data, potentially HIPAA's breach notification rule.

What it means for US & EU software teams

The first implication is that SaaS security posture is not the same as SaaS patch management. City-Forum required no CVE and will receive no CVE. It exploited configuration drift — the slow accumulation of permissive settings that often goes unreviewed after initial portal setup. Teams that track CVEs and run patching cycles on schedule will not catch this class of exposure without a separate guest-permission audit process.

The second is regulatory. Under GDPR, organisations are required to implement appropriate technical and organisational measures to protect personal data (Article 32). Guest sharing rules that expose customer names, contact details, support cases, or financial records to anyone on the internet are unlikely to satisfy that requirement. An audit that closes the City-Forum exposure is also evidence of compliance posture, not just incident response.

The third is operational. City-Forum's tooling enumerates available objects before extracting them. In Salesforce, that means the attacker maps your accessible data model before deciding what to harvest. If your portal exposes records beyond what a guest legitimately needs, that excess is visible to any sufficiently motivated operator. The principle of least privilege, standard in access-control design, applies equally to portal guest accounts.

Configuration checklist

These are the immediate actions Reco recommends, along with operational context for each:

1. Audit guest-user sharing rules in Salesforce. In Setup, review Guest User profile permissions and object-level sharing rules. Apply the principle of least privilege: a guest should read only what they genuinely need as an anonymous visitor. Revoke access to any object that is not required for the portal's public-facing purpose.
2. Disable or restrict Aura and LWR endpoint access. If your portal is Aura-based and does not require unauthenticated Aura API requests, restrict access via Salesforce's guest-user profile. For LWR sites, review GraphQL query exposure in Experience Builder.
3. Disable self-registration if not required. Check whether /SiteRegister or /CommunitiesSelfReg are active. If guest registration is not a feature your portal needs, turn it off — it eliminates the privilege-escalation vector City-Forum probes for.
4. Restrict ServiceNow Service Portal search to authenticated users. Review the search source ACLs for your Service Portal. Ensure that the /api/now/sp/search endpoint requires an authenticated session before returning results.
5. Rate-limit or block 158.220.87.79. The known attacker IP is a short-term mitigation while configuration fixes are applied. Add it to your WAF blocklist and monitor for Go-http-client traffic patterns on portal endpoints.
6. Review portal WAF rules for Aura and LWR patterns. Standard WAF rulesets may not flag legitimate-looking Aura or GraphQL requests at volume. Add rate-limit rules for these endpoints based on guest IP rather than authenticated session.

Frequently asked questions

Sources

BleepingComputer — City-Forum data-theft attacks target Salesforce, ServiceNow portals, 12 August 2026 (primary coverage)
The Register — Mystery attacker spent a year raiding Salesforce and ServiceNow portals, 13 August 2026
Dark Reading — Long-running Data Theft Campaign Targeting Salesforce, ServiceNow, August 2026