A single IP address, over a year of scraping
Security firm Reco disclosed a scraping campaign it calls City Forum, named after a domain tied to the attacker's infrastructure. The activity traces back to a single server at IP address 158.220.87.79 and has been running since March 2025, well over a year of sustained data extraction that went undetected for most of that span across a growing list of organizations. Reco says the pace of activity from that same IP has continued climbing rather than slowing, which suggests the operator has faced little friction so far and has no obvious reason to change course.
The campaign targets two of the most widely deployed enterprise SaaS platforms on the market: Salesforce Experience Cloud and ServiceNow's Service Portal. Both products let organizations expose limited, public-facing portals to customers, partners, or the general public without requiring a full login, using what each platform calls a guest user profile. That guest access, meant to serve a narrow public function, is exactly what the attacker has been exploiting at scale.
A permissions problem rather than a software bug
There is no CVE attached to this campaign and no patch coming, because the root cause is configuration rather than code. As Reco's researchers describe it, the underlying issue is a guest identity that was granted more access than the public-facing site actually needed to function. On the Salesforce side, the attacker enumerates data through the Aura framework and the Lightning Web Runtime's UI-API, targeting versions 56.0 through 66.0. On ServiceNow, the target is the Service Portal's search endpoint, reached through a straightforward POST request that requires no special tooling to construct.
The tooling itself is unremarkable: a Go-compiled utility using the language's default net/http user agent string, which should be an immediate red flag inside any web application firewall log but apparently went unnoticed for over a year. That pairing, unglamorous tooling running against a permissions misconfiguration, is precisely why the campaign persisted so long. There was no exploit signature to catch, only elevated guest traffic volume that nobody happened to be watching closely.
The scale at a single target shows how long this can run
One organization in Reco's findings logged more than 560,000 scraping events tied to the same source IP over the life of the campaign. That volume rules out a smash-and-grab scrape; it describes a persistent, low-and-slow data collection operation sustained against a single target over an extended period without ever triggering a rate-limiting response, a manual security review, or an internal alert loud enough to force a fix before the campaign was disclosed publicly by outside researchers.
Reco reports the infrastructure remains active today, with scraping volume continuing to climb rather than tapering off following disclosure, suggesting the operator has not felt any pressure to slow down or shift infrastructure. No attribution to a named threat group has been made public. The victims span telecommunications, banking, financial services, enterprise software vendors including security and data privacy companies, and public sector portals, a target list broad enough to suggest opportunistic scanning for exposed guest configurations rather than a narrowly targeted campaign against a handful of chosen organizations.
Why security vendors themselves show up as victims
Perhaps the most uncomfortable detail in Reco's findings is that the victim list includes security and data privacy vendors, companies whose entire business is helping other organizations avoid exactly this kind of misconfiguration. It underscores that guest portal permissioning is a blind spot cutting across sophistication levels, because it lives in a configuration layer that security teams rarely audit with the same rigor they apply to authentication systems, network perimeters, or endpoint controls.
Salesforce has published guidance for years urging customers to review Experience Cloud guest user profiles and strip unnecessary object and field-level permissions, and ServiceNow offers comparable recommendations for Service Portal access control lists. The awareness has existed for a long time. What is missing is a review cadence: these settings typically get configured once during implementation and rarely get revisited as the underlying data model and object permissions expand over subsequent years.
The audit enterprise teams should run this month
For any organization running Salesforce Experience Cloud or ServiceNow customer-facing portals, treat this as a prompt to run a guest user permission audit now, since no formal advisory or CVE will ever trigger a patch cycle for a pure configuration issue like this one. Pull the guest profile's object permissions, field-level security, and sharing rules, and compare each of them directly against what the public-facing portal actually needs to do its job for a genuine anonymous visitor.
Retail and commerce operators using either platform for customer service or order-status portals should treat this with particular urgency, since guest access there is often configured broadly during initial rollout to minimize support friction and then never revisited afterward as the catalog and order data model grows. Watch specifically for anomalous request volume from single IP addresses against public-facing API endpoints, since sustained, unremarkable traffic from one source is the exact pattern that let City Forum run undetected for more than a year.
Turn the attacker's own mistake into a detection rule
Treat the attacker's operational security failure as a lesson worth acting on immediately, since it points directly at a detection rule most organizations do not yet have in place. Default HTTP user agents on scraping tools are trivially detectable once a defender actually looks for them in logs, and that overlooked gap is what let this campaign run for well over a year without anyone recognizing the pattern hiding inside otherwise routine guest traffic on a public portal.
Retroactively hunting through WAF and CDN logs for that signature, alongside traffic from the disclosed IP address, is a reasonable and low-effort step even for organizations with no specific reason yet to believe they were targeted by this particular campaign. Given how long City Forum operated before this disclosure surfaced it publicly, defenders should assume other unreported instances of the same technique are quietly running against other guest portals right now, undetected for the same structural reasons.
