City-Forum: A Year-Long SaaS Guest-Access Data Theft Campaign

Authors: Cloud Security Alliance AI Safety Initiative
Published: 2026-08-15

Categories: SaaS Security, Identity and Access Management, Threat Intelligence
Download PDF

City-Forum: A Year-Long SaaS Guest-Access Data Theft Campaign

Key Takeaways

  • SaaS security firm Reco has tracked a data-theft operation it calls City-Forum to a single server that has spent more than a year systematically harvesting data from Salesforce Experience Cloud and ServiceNow Service Portal deployments worldwide, with no reported evidence that any platform vulnerability was involved [1][4].
  • Every request in the campaign traces to one IP address, 158.220.87.79, hosted by the German VPS provider Contabo and associated with the domain city-forum.com, which has resolved to that server since at least March 2025 [1][2][3].
  • The attacker built custom tooling against three distinct interfaces — Salesforce’s legacy Aura framework, Salesforce’s newer Lightning Web Runtime (LWR) UI API, and an undocumented ServiceNow Service Portal search endpoint — with the LWR activity marking the first publicly reported in-the-wild abuse of that guest-access surface [1][5].
  • Reported targets span telecommunications carriers, banks and financial services firms, enterprise software vendors (including security and data-privacy companies), and public-sector portals, with industry coverage citing more than 560,000 requests against its most heavily targeted victim alone [6][7].
  • Reco’s researchers — and ServiceNow, in a statement to reporters — have said the activity exploits customer-side guest-user misconfigurations rather than any platform security flaw, distinguishing City-Forum from the OAuth-token supply-chain breaches — such as the Salesloft Drift, Gainsight, and Klue incidents — that dominated SaaS threat reporting over the preceding year [1][3].

Background

Salesforce Experience Cloud and ServiceNow Service Portal both exist to let organizations expose curated slices of their CRM or ITSM data to people who have not logged in: prospective customers browsing a knowledge base, partners submitting a support case, or citizens searching a public-sector service catalog. That design requires a “guest user” or equivalent anonymous identity with just enough access to render the intended pages, and both platforms give administrators granular control over exactly what that identity can see. The City-Forum campaign, first documented publicly by the SaaS security vendor Reco in August 2026, demonstrates what happens when that granularity is configured too loosely at scale: an attacker who never needs a password, a phished credential, or a stolen OAuth token can simply ask the guest identity for whatever it has been left able to see [1][4].

Reco’s researchers traced every request in the campaign to a single IP address, 158.220.87.79, hosted by the German VPS provider Contabo. That IP is tied to the domain city-forum.com, which the researchers found has resolved to the same server since at least March 2025 — meaning the infrastructure behind the campaign has operated continuously for roughly a year and a half without rotating [1][2]. The requests almost always carry the default Go-http-client/1.1 user-agent string, the out-of-the-box signature left by an unmodified Go HTTP client, which suggests the operator either did not bother to disguise the tooling or considered disguise unnecessary given how the traffic otherwise resembles ordinary guest-portal usage [2][3]. Coverage of the campaign describes attacks reaching telecommunications companies, banks and other financial services firms, enterprise software vendors — including firms in the security and data-privacy space — and public-sector portals across multiple regions, with Salesforce Ben and The Register reporting more than 560,000 requests logged against the single most heavily targeted organization [6][7]. No news organization has published a list of confirmed named victims or a verified count of successful data exfiltrations distinct from total request volume, and readers should treat the 560,000 figure as a measure of attack activity against one target rather than a confirmed campaign-wide breach count.

What makes City-Forum notable within the broader wave of 2025–2026 SaaS-focused threat activity is what it does not require. The OAuth-token campaigns associated with ShinyHunters-affiliated actors against Salesloft’s Drift integration, Gainsight’s published Salesforce apps, and the Klue platform all depended on compromising a legitimate, already-authorized credential somewhere in the integration chain [8]. City-Forum requires none of that. It targets the guest-user surface that Salesforce and ServiceNow expose by design, then abuses sharing rules, profile permissions, and search-source configurations that the customer — not the vendor — controls. Security teams accustomed to thinking about SaaS risk in terms of credential theft, phishing, or third-party app compromise may not have guest-access misconfiguration on their radar at all, even though CSA’s own 2022 survey of 340 organizations found that 43 percent had already experienced a security incident traceable to a SaaS misconfiguration, with nearly half of respondents checking their configurations no more than monthly [10].

Security Analysis

One Root Cause, Two Platforms

Salesforce and ServiceNow implement guest access differently under the hood, but City-Forum’s success against both rests on the same underlying failure: an administrator granted an anonymous identity broader read access than the portal’s actual use case required, and no one subsequently noticed. In Salesforce Experience Cloud, every site has its own dedicated guest user, and that user’s effective access is governed by the org-wide sharing defaults, any sharing rules that extend visibility to external users, and the permissions assigned to the guest user’s profile. When an administrator sets org-wide defaults to Public Read/Write for convenience, exposes an Apex controller method without the “with sharing” keyword, or leaves API access enabled for a profile that does not need it, the guest identity can enumerate far more than the portal’s designers intended [3][9]. ServiceNow’s exposure runs through a different mechanism: its Service Portal search functionality queries configured “search sources,” and when those sources are not explicitly restricted to authenticated roles, the same search endpoint that lets a citizen find a public knowledge article can also return records from catalogs or tables never meant for anonymous eyes [1][5].

The following comparison summarizes how City-Forum’s tooling engages each platform.

Dimension Salesforce Experience Cloud ServiceNow Service Portal
Primary endpoint(s) targeted /aura (legacy Aura framework); /webruntime/api/services/data/{version}/graphql (Lightning Web Runtime) [1][5] POST /api/now/sp/search [2][3]
Underlying misconfiguration Overly permissive org-wide sharing defaults, sharing rules, or guest profile permissions [3][9] Search sources not restricted to authenticated roles [1]
Representative methods/techniques observed HostConfigController.getConfigData, SelectableListDataProviderController.getItems (Aura); GraphQL queries via the UI API (LWR) [5] High-volume queries against the native portal search API [1][2]
Data reportedly exposed Accounts, contacts, leads, users, and content-document files [1][2] Knowledge base articles and catalog entries [2]
Detection complexity Traffic resembles ordinary guest-portal browsing; no authentication event to flag [1][3] Endpoint returns HTTP 201 for both authenticated and anonymous requests, so status codes alone cannot distinguish legitimate from abusive traffic [1][3]

A New Surface: The LWR/UI-API Guest Path

The most technically significant element of City-Forum is its targeting of Salesforce sites built on the newer Lightning Web Runtime framework, which Salesforce has increasingly promoted as the successor to the older Aura-based Experience Cloud architecture. Rather than relying solely on Aura’s /aura endpoint — the interface abused in most previously documented Salesforce guest-access incidents — the campaign also issues GraphQL requests through Salesforce’s UI API at /webruntime/api/services/data/{version}/graphql to pull data exposed to guest accounts on LWR sites [1][5]. Public reporting describes this as the first documented in-the-wild exploitation of that specific guest-access surface, which matters because LWR sites are generally newer and their administrators may have had less opportunity to learn the platform’s guest-configuration pitfalls compared with the well-documented risks of legacy Aura deployments [5]. Organizations that migrated Experience Cloud sites to LWR expecting a security-by-modernization benefit should not assume the newer framework is inherently safer from guest-access misconfiguration; City-Forum demonstrates that the same category of sharing-rule and profile error carries over to the new architecture, just reached through a different API.

Distinguishing Configuration Abuse from Credential Compromise

City-Forum’s most consequential characteristic, from a governance standpoint, is what it is not: there is no reported evidence of any credential theft, session hijacking, or token compromise anywhere in the campaign. Every data point Reco and subsequent reporting describe is data the guest identity was already permitted, however inadvertently, to retrieve [1][3]. This places City-Forum in sharp contrast with the OAuth-token supply-chain campaigns that occupied much of the 2025–2026 SaaS threat landscape, where actors compromised Salesloft’s build pipeline, reused tokens across Gainsight’s published applications, and exploited a dormant four-year-old credential at Klue to reach customer Salesforce data through already-authorized connected apps [8]. Those incidents required an intrusion somewhere in the chain — a compromised vendor, a stolen token, a dormant credential nobody deactivated. City-Forum requires none of that; it only requires that the exposure already exist, waiting to be found by anyone willing to send enough requests. This distinction is a reason for security teams to treat guest-user and anonymous-access review as a distinct line item in SaaS risk prioritization, separate from OAuth and connected-app governance — a security program that only audits the latter remains blind to the exposure City-Forum has spent more than a year exploiting.

Recommendations

Immediate Actions

Security teams operating Salesforce Experience Cloud sites should immediately audit every guest user profile for excessive object, field, and API permissions, and confirm that org-wide sharing defaults for externally shared objects are set to Private rather than any public-access option; Salesforce’s own guidance recommends enabling the “Secure guest user record access” setting so that guest users cannot see a record unless an explicit sharing rule grants it [9][11]. Teams running ServiceNow Service Portal instances should inventory every configured search source and verify which ones permit anonymous or unauthenticated queries against the sp/search endpoint, since the platform’s default behavior does not clearly flag this exposure through status codes alone [1][3]. Both Salesforce and ServiceNow customers should search access and API logs for requests originating from 158.220.87.79 or carrying the default Go-http-client/1.1 user agent against guest-facing endpoints, and treat any match as evidence that the campaign has already reconnoitered or scraped their environment [2][3].

Short-Term Mitigations

Organizations should disable API access for the guest user profile in Salesforce unless a specific, documented business need requires it, enable Profile Filtering to prevent guest users from enumerating internal profiles, and ensure every Apex controller method invoked by a guest-accessible Lightning component uses the “with sharing” keyword so that sharing rules are enforced rather than bypassed [9]. On the ServiceNow side, administrators should restrict sensitive search sources to authenticated roles, apply access control lists that require authentication for any catalog or knowledge base not intended for public consumption, and monitor request volumes against the portal search endpoint for the kind of high-frequency, single-source traffic pattern City-Forum’s tooling produces [1][2]. Where either platform supports it, rate-limiting or bot-detection controls on public-facing portal endpoints can blunt large-scale automated harvesting even when a configuration gap has not yet been fully remediated.

Strategic Considerations

Guest-user and anonymous-access configurations should be brought into the same periodic review cycle organizations already apply to privileged accounts and OAuth-connected applications, rather than treated as a one-time setup task completed at site launch and never revisited. CSA’s 2022 survey data showing that 46 percent of organizations relying on manual monitoring check SaaS configurations no more than once a month — and that automated SaaS Security Posture Management tooling meaningfully shortens both detection and remediation timelines compared with manual review — is a reasonable fit here: a year-long campaign against a static misconfiguration is the kind of gap continuous automated monitoring is intended to catch, provided the SSPM tooling’s rule set actually covers guest-user and anonymous-access configuration [10]. Organizations building or maturing a SaaS security program should also adopt the CSA SaaS Security Capability Framework’s Identity and Access Management controls as a baseline for evaluating both their own guest-portal configurations and the security capabilities of any SaaS vendor hosting public-facing portals on their behalf, since anonymous and external-user access governance sits squarely within that framework’s scope [12].

CSA Resource Alignment

The CSA SaaS Security Capability Framework (SSCF) is the most directly applicable CSA artifact for this campaign. SSCF’s Identity and Access Management domain — the framework’s largest, spanning 21 of its 36 total controls — explicitly addresses risks from “anonymous and external unmanaged user access” and calls for customer-facing, configurable controls that let organizations govern exactly the guest-identity permissions City-Forum exploited [12]. Organizations conducting third-party risk assessments of any SaaS vendor that offers public-facing guest portals should use SSCF’s control specifications as an evaluation checklist, since the framework was built to fill precisely the gap that general compliance attestations like SOC 2 leave open around customer-configurable security settings [12].

CSA’s 2022 SaaS Security and Misconfigurations Report supplies the empirical grounding for why a campaign like City-Forum can persist undetected for more than a year: the survey’s finding that 43 percent of organizations had already experienced a misconfiguration-driven security incident, paired with nearly half of respondents reviewing configurations no more frequently than monthly, describes exactly the detection gap that let city-forum.com’s infrastructure operate against the same guest-access weaknesses since March 2025 without interruption [10]. That report’s core recommendation — that automated, continuous configuration monitoring meaningfully outperforms manual periodic review — was framed around identity and data-protection controls, but the same logic reasonably extends to guest-user and search-source settings: both are static configuration surfaces that a year-long, undetected campaign like City-Forum shows benefit from continuous rather than periodic review.

CSA’s recent research note on the ShinyHunters OAuth-token campaign against Salesloft, Gainsight, and Klue provides useful contrast rather than direct overlap: both campaigns targeted Salesforce-adjacent data at scale, but where the OAuth campaign required compromising a legitimate third-party credential somewhere in an integration chain, City-Forum required only an existing configuration gap [8]. Security teams that implemented that note’s recommendations around connected-app governance and OAuth lifecycle review should recognize that those controls do not address the guest-access exposure described here, and should treat the two research notes as complementary rather than redundant coverage of SaaS trust-boundary risk. Finally, CSA’s presentation “Take a Deep Dive Into Common SaaS Data Breaches — And How to Avoid Them” examines earlier real-world SaaS breach scenarios, including customer support portal exposures, and its central recommendation — that organizations gain active visibility into what their SaaS configurations actually expose, rather than assuming initial setup remains correct indefinitely — is the same discipline this note recommends applying to Salesforce and ServiceNow guest portals specifically [13].


References

  1. Reco, “The ‘City-Forum’ Campaign – An Advanced Attacker Is Targeting Salesforce and ServiceNow Instances Worldwide,” August 2026.
  2. Techzine Global, “City-Forum Extracts Data From Salesforce and ServiceNow,” August 2026.
  3. BleepingComputer, “‘City-Forum’ Data-Theft Attacks Target Salesforce, ServiceNow Portals,” August 2026.
  4. Dark Reading, “Long-Running Data Theft Campaign Targeting Salesforce, ServiceNow,” August 2026.
  5. SecurityWeek, “Stealthy ‘City-Forum’ Attacks Target Salesforce and ServiceNow With Custom Toolset,” August 2026.
  6. Salesforce Ben, “Data Theft Campaign Targets Salesforce and ServiceNow With 560K+ Attacks,” August 2026.
  7. The Register, “Mystery Attacker Spent a Year Raiding Salesforce and ServiceNow Portals,” August 13, 2026.
  8. Cloud Security Alliance, “ShinyHunters’ OAuth Pivot: A Year of SaaS Supply-Chain Breaches,” July 2026.
  9. Salesforce, “Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access,” Salesforce Blog.
  10. Cloud Security Alliance, “SaaS Security and Misconfigurations Report,” 2022.
  11. Salesforce Help, “Best Practices and Considerations When Configuring the Guest User Profile.”
  12. Cloud Security Alliance, “SaaS Security Capability Framework (SSCF),” September 2025.
  13. Cloud Security Alliance, “Take a Deep Dive Into Common SaaS Data Breaches — And How to Avoid Them,” 2025.
← Back to Research Index