Somebody Read Salesforce and ServiceNow Portals Worldwide for 17 Months From One IP Address. There Is No CVE, No Patch, and Your Scanner Says You Are Fine.
- Patrick Duggan
- 1 hour ago
- 5 min read
Reco published research this week on a campaign they call City-Forum, named for a domain tied to the attacker's IP. A single actor has been systematically reading data out of Salesforce Experience Cloud sites and ServiceNow Service Portals around the world since at least March 2025.
Seventeen months. Telecommunications, financial services, enterprise software, security and data-privacy vendors, public-sector portals. All of it from one IP address: 158.220.87.79, a Contabo VPS in Germany, every request carrying the user agent Go-http-client/1.1 — a compiled Go binary, not a browser.
Here is why we are writing it up rather than letting it pass as another campaign post: nothing was exploited.
There is no vulnerability here
No CVE was assigned because no CVE applies. City-Forum did not break Salesforce and did not break ServiceNow. It used guest access — the feature both platforms ship so that unauthenticated visitors can see a public support portal, a community forum, a knowledge base.
The actor's contribution was research and tooling. They studied how the platforms expose data to guest users, then built custom tools to find what organizations had inadvertently left readable. On Salesforce, they went after newer Lightning Web Runtime sites through the UI-API data layer — a surface with no public exploitation tooling and no documented prior research. On ServiceNow, they used an undocumented native search endpoint inside Service Portals.
Both platforms behaved exactly as designed. Every affected organization was, in a strict sense, correctly configured software running without a known vulnerability.
This is the beat we keep coming back to, and it keeps being the one that costs people the most: the absence of a CVE is not the absence of a problem — it is the absence of a label. Your vulnerability scanner reports clean. Your patch compliance is 100 percent. Your KEV remediation is current. And a stranger read your customer data for seventeen months.
Why this combination is worse than it sounds
Salesforce Experience Cloud and ServiceNow Service Portal are not exotic. They are the default customer-facing layer of the mid-to-large enterprise: Salesforce for the community and partner portal, ServiceNow for the support portal and service catalog.
We happened to run an unrelated external posture scan of a mid-cap manufacturer this morning, before this research crossed our desk. Their support portal was a ServiceNow Service Portal. Their marketing and CRM stack was Salesforce. That is not a coincidence or a finding about that company — it is the point. That pairing is close to a default, which means the exposed population for City-Forum is not a niche. It is most of the enterprise market that has a customer-facing portal at all.
And guest-access exposure has a specific, nasty property: it is cumulative and invisible. Nobody misconfigures a portal on purpose. It happens when someone publishes a knowledge article, extends an object's sharing rules for a legitimate reason, or adds a field to a public form. Each change is small, defensible, and made by someone who is not in the security team. The exposure is the sum of eighteen months of reasonable decisions, and there is no alert for it, because nothing broke.
What we had, and what we did not
We enriched the campaign's IP against our corpus before writing a word. Being precise, because this is exactly where intelligence write-ups cheat:
We did not have [158.220.87.79](https://analytics.dugganusa.com/stix/register?ref=ioc-click&q=158.220.87.79). Our enrichment returns found:false on the exact indicator. We were not ahead of this, we had no prior sighting, and we are not claiming one.
What we do have is the neighbourhood. Contabo's 158.220.0.0/16 is well represented in our corpus, including 158.220.93.201, which we flagged as a command-and-control host through our own Pattern 38 detection — a first-party observation, not an imported feed. Alongside that sit multiple third-party corroborations in the same space: botnet C2s at 158.220.121.73 and 158.220.113.212 from SSLBL, and 158.220.96.15 from ThreatFox and community feeds.
That tells you something real about the hosting provider and nothing at all about this campaign. Per our own rule on this: an indicator's neighbours are corroboration for a hosting-reputation argument, never evidence of detection of the specific thing. If we told you "City-Forum was in our feed," we would be lying by adjacency. It was not.
A caution on searching for it yourself: querying our IOC index for the string "158.220.87" returns an estimated 7,670 hits, and so does querying for "158.220.87.1" or any other address in that block. That is the tokenizer matching fragments, not exact addresses. The exact-match enrichment is the authoritative answer, and it says no. We mention it because that same false-count would let someone claim coverage they do not have.
What to actually do
This is not a patching problem, so the patching muscle will not help. Three things will:
Audit guest access as a standing control, not a project. In Salesforce, review the Guest User profile's object and field permissions, sharing rules, and what your LWR sites expose through UI-API. In ServiceNow, review public pages, the widgets on them, and ACLs on the tables those widgets read — including the search endpoint's reach.
Watch for the shape, not the address. Blocking 158.220.87.79 costs nothing and buys nothing; a VPS is a five-euro consumable. The durable signal is behavioural: sustained unauthenticated portal traffic from a datacentre ASN with a non-browser user agent, enumerating records rather than reading pages. Go-http-client/1.1 against a customer portal has no legitimate explanation in almost any environment.
Assume seventeen months. If you run either platform with guest access enabled, the correct question is not "are we exposed today" but "what has been readable since March 2025, and who read it." Reco's research names the endpoints; your logs will tell you the rest, if you kept them that long. Most organizations did not, and that is its own finding.
Credit
The research is Reco's. We did not find this, we had no prior indicator, and the entire technical account above is theirs. What we added is the corpus check that came back negative and is reported as negative, the tokenizer trap that would let someone fake a positive, and the framing that this belongs to the no-CVE tier — the class of problem where being fully patched and fully compliant tells you nothing.
Ninety-five percent, as always. If you can show us we did have that IP and missed it, we would genuinely like to know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=somebody-read-salesforce-and-servicenow-portals-worldwide-for-17-months-from-one-ip-address-there-i
Comments