City-Forum: 17 months of pulling data from Salesforce and ServiceNow portals without ever touching a credential

The story that starts where everything works as designed

Most security stories begin with something broken. This one begins with everything working exactly as designed. Researchers at Reco have spent months tracking a campaign they call City-Forum, named after a domain registered in 2002, abandoned for decades, and now resolving to a generic rented server from a German hosting provider. From that server, someone has been pulling records out of Salesforce and ServiceNow portals around the world for at least seventeen months.

Help Net Security published the case on August 12, 2026, and Travis Stein covered it on LinkedIn with a complementary analysis. For any DevSecOps team operating SaaS platforms with customer portals, this case is not a traditional technical incident. It is a lesson in how configuration decisions become silent, persistent, massive data leaks that are practically undetectable through conventional security controls.

The campaign is live today. It is not historical. The server remains active. The operator continues extracting data. And the configuration problem that enables it is still present in thousands of organizations in production.

Technical anatomy of City-Forum

City-Forum does not exploit any vulnerability. That is the uncomfortable part. The operator uses three ingredients available to any patient attacker: a persistent IP, a custom HTTP client, and guest-user permissions more generous than anyone intended.

The infrastructure is a single IP address: 158.220.87.79, hosted on a commodity VPS from the German provider Contabo. What distinguishes City-Forum from similar campaigns is that the operator has held that address for the entire activity window without rotating it at any point. Passive DNS shows that the domain has resolved to this address since at least March 2025, confirming the infrastructure has been standing for a year and a half.

The second ingredient is the HTTP client. All City-Forum traffic carries the same User-Agent, which matches the default value of Go's net/http library. That fingerprint is deliberate in the sense that it identifies a custom-compiled client —not a browser, not a standard tool— but it is technically the default string any Go program emits without modification. For analysts, that fingerprint means the attacker has written a purpose-built program for this task, not that they are reusing known tooling.

The third ingredient is where the case becomes instructive. The attacker uses no stolen credentials, exploits no vulnerabilities, and deploys no malware. They use only the permissions that organizations themselves have granted to anonymous guest users on their public portals. In Salesforce Experience Cloud, that means access through the Aura layer and the GraphQL endpoints of the Lightning Web Runtime. In ServiceNow, the operator uses a search endpoint that the product documentation does not prominently feature but that returns results to anonymous users when the portal configuration allows it.

The volume of activity is significant. Reco documents that on a single victim the operator generated more than 560,000 extraction events across the observation window. The activity is high-volume but protocol-legitimate, meaning each individual request looks like normal portal usage.

Sectors and victims

The sectoral reach of City-Forum is not random. Reco identifies victims in telecom operators, banks and financial-services firms, enterprise software vendors —including security and data-privacy companies— and public-sector portals. The selection suggests the operator is hunting for two things: end-customer data stored in support or customer-service portals, and operational data usable as a basis for follow-on attacks.

Telecom data is particularly valuable for SIM swap and customer account compromise. Banking data is useful for fraud and for feeding target lists in spear-phishing campaigns. Security vendor data can be used to map the attack surface of other organizations that are customers of the affected vendor.

That the victims include security and privacy vendors deserves attention. If your organization offers security services to end customers, your exposure surface almost certainly includes the support portals where those customers manage tickets, downloads or configuration. City-Forum documents that those portals are also on the operator's map.

Why this case is a case study for DevSecOps

Three reasons make City-Forum mandatory reference material for any team operating SaaS in production.

Reason one — the attack chain is not technical. There is no exploit, no payload, no stolen credential. There is a guest-user configuration more permissive than the organization believes. That means the failing control is not in the code, it is in operations. Responsibility lies with whoever maintains configuration, not with whoever wrote the software.

Reason two — traditional detection does not work. City-Forum activity looks like legitimate portal use. WAFs do not flag it. IDS do not detect it. Identity management systems see no suspicious activity because each request authenticates correctly as guest. The only controls that could detect it are behavioral analysis over application logs, which requires telemetry most SaaS organizations do not collect.

Reason three — the blast radius is invisible. Unlike a credential compromise, where you can see which account accessed what resources, an extraction by guest user leaves a much fuzzier trail. The question "what data left" cannot be answered with certainty by looking at access logs, because logs may not capture individual responses. Reco is explicit about this: if you go looking for this traffic in your logs, you will learn less than you would like.

DevSecOps playbook for this week

### Phase 1 — Anonymous exposure inventory (days 1 to 3)

The first move is to know what you have exposed to guest users without realizing it. For Salesforce Experience Cloud:

- Audit every published Experience Cloud site and list exactly which objects, fields, lists and files are accessible to the guest-user profile. The path is `Setup → Sites → Builder → Guest User Profile`. - Review the sharing rules that apply to guest users, especially those allowing read access to Account, Contact, Case, Custom Object and any custom object containing customer data. - Check whether public APIs (REST, SOAP, GraphQL via Aura, Bulk API) are enabled for the guest user. The Aura API in particular allows mass data extraction if sharing rules are permissive. - Review the search sources accessible to guest users, including global search and search on specific objects. Search is one of the most powerful mass-extraction vectors. - Audit Flows, Apex and Lightning Web Components accessible without authentication.

For ServiceNow Service Portal:

- List every widget, page and knowledge-base article exposed to the public. - Audit the portal ACLs, especially those allowing read access to unauthenticated users. - Check the undocumented search endpoint City-Forum exploits. ServiceNow has multiple search endpoints and some do not appear in main documentation but are available in production instances. - Review the Include scripts, UI Macros and Widget Server Scripts accessible without authentication. - Verify the auto-registration and self-service configuration. If enabled, an attacker can create accounts with minimum permissions that add to the attack surface.

### Phase 2 — Guest-user permission hardening (days 3 to 7)

For Salesforce:

- Change the Organization-Wide Default of each relevant object to Private or to Public Read Only where strictly necessary. - Replace permissive sharing rules with sharing rules based on criteria that explicitly exclude guest users. - Disable APIs accessible to guest users. If some public API is strictly necessary, limit it to specific objects and fields that do not contain sensitive data. - Remove guest-user access to search sources that return customer data. - Implement strict Field-Level Security on every object accessible to guest users.

For ServiceNow:

- Apply least-privilege to each ACL. Every ACL allowing access to anonymous users must specifically justify why it exists. - Disable the undocumented search endpoint if it is accessible. If official documentation does not cover it, it is reasonable to disable it or restrict it. - Audit public references and remove those that are not necessary. - Implement aggressive rate limiting on the public portal.

### Phase 3 — Telemetry and detection (days 7 to 14)

- Activate Event Monitoring in Salesforce if available. This capability captures field-level access and enables behavioral analysis that would detect patterns similar to City-Forum. Activate at least Report Event, ListView Event and API Event. - In ServiceNow, activate Transaction Logs and audit Service Portal logs to detect scraping patterns. - Implement alerts on abnormal volume of accesses from a single IP. A legitimate guest user does not generate 560,000 events over weeks. - Create a per-guest-user activity dashboard that lets you identify anomalies in usage patterns. - Implement honey tokens or canary data. Place records with fields no legitimate user should see or query. If those records appear in access logs or search results, you have an unauthorized visitor.

### Phase 4 — Retrospective audit (days 14 to 30)

- Search historical logs for patterns compatible with City-Forum: an external IP that has made many guest-authenticated requests over months. - Assess whether you have enough data in logs to answer the question "what data left". If you do not, that is the main finding: the absence of telemetry is the real gap. - Document the historical exposure surface. What was accessible to guest users over the past 17 months, what objects, what fields. - If you determine exposure occurred, evaluate regulatory obligations. In the European context, GDPR imposes notification to supervisory authorities within 72 hours when there is risk to data-subject rights. Data extracted by City-Forum includes names, emails, phones and account data in many cases — that usually qualifies as personal data.

Systematic mistakes teams make

Mistake one — trusting that default configuration is secure. Default SaaS portal configuration is usually more permissive than necessary. The team deploying the portal rarely reviews every sharing rule and every ACL with a least-privilege mindset.

Mistake two — treating guest users as non-human and risk-free. An unauthenticated guest user is still a security principal. They hold permissions that execute against real data. The right attitude is to treat them as a user with all the privileges you have given them, not as an innocuous visitor.

Mistake three — measuring configuration risk by visible incident count. If your SaaS portal has not had a visible security incident, that does not mean configuration is correct. City-Forum has been extracting data for 17 months without any victim organically detecting the activity. Absence of incidents is not evidence of security.

Mistake four — not correlating logs across systems. Detecting City-Forum required Reco to correlate logs from multiple victims to identify the pattern. A single organization looking only at its own logs does not have the aggregated view needed to detect multi-target campaigns like this.

The paragraph for leadership

If you need the paragraph for a security committee: City-Forum is a live data-extraction campaign active since March 2025 affecting public Salesforce Experience Cloud and ServiceNow portals in telecom, banking, enterprise software and public sector. The operator uses only permissions granted to anonymous guest users —no stolen credentials, no exploits, no malware. One documented victim registers more than 560,000 extraction events. Immediate mitigation is to audit and harden guest-user permissions on every public SaaS portal, activate telemetry that detects persistent scraping patterns, and implement rate limiting and canary data. The strategic lesson is that a permissive SaaS configuration is a silent vulnerability no WAF or IDS will detect until it is too late.

Structural changes after this incident

Change one — guest users as first-class security principals. If your organization treats guest users as zero-risk actors, this incident invalidates that assumption. Guest users deserve the same audit level as any other security principal.

Change two — mandatory telemetry over anonymous access. SaaS platforms that publish portals must have field-level telemetry, not just access-level. Without that granularity, campaigns like City-Forum are invisible until a third party reports them.

Change three — honey tokens as a standard control. Including canary data in every public portal is a low-cost, high-value practice. The first time an external attacker queries them, you know you have unauthorized activity.

Change four — threat modeling that includes public SaaS. If your threat model treats SaaS portals as infrastructure without value to attackers, this incident invalidates that. A support portal accessible publicly is a target for persistent scraping exactly like a misconfigured API endpoint.

Verified sources

- Help Net Security, "A stranger has been reading Salesforce and ServiceNow portals worldwide for 17 months", August 12, 2026. https://www.helpnetsecurity.com/2026/08/12/salesforce-servicenow-guest-user-exposure - Travis Stein on LinkedIn, "City-Forum: 17 Month Salesforce and ServiceNow Data Breach via Guest User Account", August 2026. https://www.linkedin.com/posts/twstein86_someone-was-reading-salesforce-and-servicenow-activity-7493789910299234304-MBEQ - xacademia, "City-Forum Campaign Targets Salesforce and ServiceNow Guest Access", August 2026. https://xcademia.com/news/city-forum-campaign-targets-salesforce-and-servicenow-guest-access - daily.dev, "City-Forum Campaign Is Quietly Scraping Salesforce and ServiceNow Guest Portals", August 2026. https://daily.dev/posts/city-forum-campaign-is-quietly-scraping-salesforce-and-servicenow-guest-portals-myzkh41dw - Kevin J. Conlan on LinkedIn, complementary analysis on the City-Forum campaign. https://www.linkedin.com/posts/kevin-j-conlan-604170119_the-city-forum-campaign-an-advanced-attacker-activity-7493477434684502016-77nQ

Closing recommendations

Audit every public Salesforce and ServiceNow portal with the direct question: "what data can an anonymous user see today". Harden every guest-user permission until the answer is "only what is strictly necessary". Activate telemetry that detects persistent scraping patterns. Implement honey tokens on every public portal. And finally, integrate public SaaS into your threat model with the same seriousness as an API endpoint exposed to the internet. The difference between those two frameworks is what separates teams that discover City-Forum in their infrastructure before Reco publishes it, from those who discover it when it is already too late.