A long-running threat campaign dubbed “City-Forum” has been systematically extracting data from Salesforce and ServiceNow tenants worldwide since at least March 2025 — without exploiting a single vulnerability. Every record was pulled through legitimate, unauthenticated endpoints that customers left overly permissive. If you manage a client’s Salesforce Experience Cloud site, Lightning Web Runtime portal, or ServiceNow Service Portal, this one lands squarely on the MSP side of the shared-responsibility line.

What’s happening

Researchers tracked the campaign back to a single static IP — 158.220.87.79, a Contabo VPS in Germany — and a domain, city-forum[.]com, that has hosted the attacker’s infrastructure for over a year. Every request uses the same tell: a custom Go-http-client/1.1 User-Agent from a compiled Go tool built specifically for this operation. One targeted organization logged over 560,000 enumeration events. This isn’t spray-and-pray; it’s methodical, automated, and long-term.

The actor is exploiting two things:

• Salesforce guest-user permissions that are too generous. On standard deployments, the tool abuses the Aura framework’s getConfigData and getItems calls to enumerate Accounts, Contacts, and Cases. On Lightning Web Runtime (LWR) sites, it hits the GraphQL-based UI-API data layer — a surface with almost no public tooling or research — and sweeps API versions v56.0 through v66.0 to extract records. It also probes for open self-registration portals where guest accounts can escalate beyond default profiles.

• ServiceNow Service Portal search endpoints that return data to unauthenticated callers. The actor floods POST /api/now/sp/search to test which Knowledge Bases and service catalog items are readable without login. A nasty defender trap: the endpoint returns HTTP 201 Created for both authenticated and unauthenticated requests, so status codes alone won’t tell you who was legitimate.

Why this matters for MSPs and ITSPs

Salesforce and ServiceNow both operate on a shared-responsibility model — the vendor secures the platform, the customer (or their MSP) configures it safely. City-Forum is a textbook case of what that model looks like when it fails at the customer layer:

• The exposure is configuration, not code. No patch is coming. Every affected tenant chose — or inherited from a template — the settings that made this possible. That’s an MSP deliverable.

• Portal buildouts are the failure mode. Experience Cloud sites, LWR community portals, and ServiceNow Service Portals are almost always stood up by an MSP, a Salesforce/ServiceNow consulting partner, or an internal team following a partner playbook. Guest-user sharing rules and Knowledge Base “Can Read” criteria are exactly the kind of detail that gets rushed at launch.

• The blast radius is your entire book. If you built ten client portals from the same template, you likely have ten tenants with the same misconfig. City-Forum’s operators are enumerating globally — assume they’ve already touched anything you exposed.

• Detection is harder than it should be. A static IP and unique User-Agent make hunting straightforward, but ServiceNow’s uniform HTTP 201 response means log-based anomaly detection needs to look at request volume and endpoint patterns, not response codes.

Immediate actions

Salesforce (Experience Cloud, LWR, standard):

• Audit guest user profile permissions — object-level and field-level. Remove anything not strictly required.

• Review guest sharing rules across every Experience Cloud and LWR site you manage.

• Disable self-registration on portals that don’t need it. Where it’s required, verify guest accounts can’t escalate.

• In Experience Builder, turn off guest access to public APIs unless a specific business case demands it.

ServiceNow:

• Audit search sources attached to every public-facing Service Portal.

• Review each Knowledge Base’s “Can Read” criteria and restrict permissive “Any User” grants.

• Check service catalog item ACLs for the same unauthenticated-read pattern.

Threat hunting across all managed tenants:

• Query network and platform logs for traffic from 158.220.87.79.

• Search for the Go-http-client/1.1 User-Agent in web and API logs.

• Review recent volume against Salesforce Aura endpoints (getConfigData, getItems), the LWR UI-API, and POST /api/now/sp/search.

• Do not use HTTP 201 Created as an “everything’s fine” signal on ServiceNow portal traffic.

Bottom line

City-Forum is a reminder that the biggest SaaS breaches of 2026 won’t all come from CVEs — a lot will come from a checkbox someone forgot to uncheck. For MSPs managing Salesforce or ServiceNow environments, guest-user and portal-permission audits belong on the recurring maintenance calendar, not the “if we have time” list. Block the IOCs, purge the guest permissions you don’t need, and treat every portal buildout as a security review, not a launch checklist.

FAQ: The “City-Forum” Salesforce & ServiceNow Data Harvesting Campaign

Q: What is the City-Forum campaign?
A: A long-running, automated data-harvesting operation active since at least March 2025 that extracts records from Salesforce and ServiceNow tenants worldwide. It’s named after city-forum[.]com, the domain tied to the attacker’s infrastructure.

Q: Is this a zero-day or a new vulnerability?
A: No. The campaign exploits customer misconfigurations — overly permissive guest-user settings and public portal permissions — not any flaw in Salesforce or ServiceNow themselves. No patch will fix it; only configuration changes will.

Q: What data is being stolen?
A: On Salesforce: Accounts, Contacts, Cases, and other records exposed through Experience Cloud, Lightning Web Runtime (LWR) portals, and self-registration pages. On ServiceNow: Knowledge Base articles and service catalog items readable without authentication through the Service Portal search endpoint.

Q: How do I know if we’ve been hit?
A: Hunt for three indicators across your managed tenants:

• Traffic from IP 158.220.87.79 (a Contabo VPS in Germany)

• Requests with the User-Agent Go-http-client/1.1

• High-volume calls to Salesforce Aura endpoints (getConfigData, getItems), the LWR UI-API, or POST /api/now/sp/search on ServiceNow

Q: Why can’t I just filter on HTTP error codes?
A: ServiceNow’s /api/now/sp/search endpoint returns HTTP 201 Created for both authenticated and unauthenticated requests, so status codes alone won’t reveal unauthorized access. You need to correlate volume, source IP, and User-Agent instead.

Q: Why does this matter for MSPs specifically?
A: Salesforce and ServiceNow operate on a shared-responsibility model — the vendor secures the platform, the customer (or their MSP) configures it. Portal buildouts, guest-user permissions, and Knowledge Base ACLs are typically an MSP deliverable, which means this exposure lives on your side of the line. If you deployed multiple client portals from the same template, you likely have multiple tenants with the same misconfiguration.

Q: What should we do first?
A: For Salesforce: audit guest-user object and field permissions, review sharing rules on every Experience Cloud and LWR site, disable unneeded self-registration, and turn off guest access to public APIs in Experience Builder. For ServiceNow: audit search sources on public portals, review Knowledge Base “Can Read” criteria, and remove permissive “Any User” grants on catalog items.

Q: Is there ongoing risk after we fix the config?
A: Yes — the campaign is active and global, and the attacker has maintained the same infrastructure for over a year. Block the IOCs at the edge, add guest-permission audits to your recurring maintenance schedule, and treat every new portal launch as a security review.