Security · 12 Aug 2026 · Rob Nidschelm

Salesforce and ServiceNow Are Being Probed Through the Guest Door

Reco has linked sustained Salesforce and ServiceNow probing to one IP address, one default Go client fingerprint and a custom multi-platform toolset. The campaign is not a zero-day story; it shows how an anonymous guest identity can become a stable data-extraction interface when permissions outgrow their purpose.

Security company Reco disclosed the City-Forum campaign on 12 August 2026. Its researchers say the same server has been querying public-facing Salesforce Experience Cloud sites and ServiceNow Service Portals across organisations worldwide.

The activity matters because it joins two SaaS platforms that defenders often assess separately. Salesforce administrators look at Experience Cloud sharing and guest profiles. ServiceNow teams review portals, search sources and knowledge access. The attacker appears to have reduced both environments to the same question: what can an unauthenticated identity retrieve at machine speed?

What happened

Reco traces the observed requests to 158.220.87.79, a virtual private server on Contabo infrastructure. The same address resolves to city-forum.com, which gave the campaign its name. Passive DNS shows the domain pointing to that address since 12 March 2025. That establishes the age of the infrastructure, not the start date of the scanning; Reco says it cannot determine when the probing began.

Requests seen across both platforms carry the user agent Go-http-client/1.1. That is the default value in Go’s net/http source code, which is consistent with a compiled scanner rather than an ordinary web browser. A user-agent string is easy to copy and is not attribution on its own. Its value here comes from the repeated combination of the same address, request patterns and target platforms.

Reco says the visible targets include telecommunications companies, financial institutions, enterprise-software and security vendors, data-privacy companies and public-sector portals. The researchers have observed guest-user activity, not authenticated access, although they do not rule out activity they cannot see.

The report does not name an attacker. The infrastructure is generic hosting, the domain does not establish an identity and the techniques do not justify assigning the campaign to ShinyHunters or another known group. The defensible conclusion is narrower: one operator appears to be using a custom toolset against anonymous data paths on Salesforce and ServiceNow.

Why the tooling stands out

Guest-user enumeration through Salesforce’s older Aura framework is well known. Reco saw that activity here, including high-volume calls associated with configuration discovery and record retrieval. The same operator also appears to have moved beyond Aura.

On newer Lightning Web Runtime (LWR) sites, the tool queried Salesforce’s UI API through GraphQL endpoints under /webruntime/api/services/data/. Reco observed consecutive API-version requests from v56.0 through v66.0, a pattern that looks like automated compatibility testing rather than normal portal use. It also saw probes for self-registration pages such as /SiteRegister and /CommunitiesSelfReg.

The ServiceNow side is equally important. The campaign repeatedly posted to /api/now/sp/search?sysparm_cancelable=true, the native endpoint used by Service Portal search. ServiceNow’s own documentation explains that portal search can draw from instance tables, multiple tables or external sites. That makes the endpoint useful, but it also means the security boundary sits behind it in the configured search sources and their access controls.

An anonymous request can receive HTTP 201 whether the result set is empty or contains content. The status code therefore does not prove that a portal is safe. What matters is whether the guest identity can retrieve records from the search sources wired into that portal.

This is an authorisation failure, not a platform zero-day

Reco’s central finding is easy to misread. The campaign uses unusual tooling, but the reported data exposure does not require the attacker to bypass the platforms’ access models. The guest user receives data because it has been allowed to read that data.

Salesforce made the same distinction in a July 2026 support article: unintended access on public Experience sites can occur when permissions are misconfigured and is not an inherent Salesforce vulnerability. Its guest-profile guidance recommends no object access for almost all objects and warns that a guest sharing rule gives anyone immediate, unauthenticated access to every matching record. Salesforce also provides a Guest User Sharing Rule Access Report for reviewing object, record and field exposure on Aura and LWR sites.

ServiceNow exposes similar administrative controls. Its documentation says user criteria can restrict portal pages, widgets and search sources by role, department, group, location or company. ServiceNow also documents that GlideRecordSecure enforces standard read and write access controls, while a plain GlideRecord query requires the developer to perform the relevant checks.

The platforms differ, but the failure mode is the same. A public page, public API route or search function is not automatically a public-data policy. That policy is created by sharing rules, object and field permissions, search-source configuration, user criteria, ACLs and custom code.

Campaign indicators

• Source IP: 158.220.87.79
• Domain: city-forum.com, resolving to the same address when Reco published its report
• User agent: Go-http-client/1.1
• Salesforce LWR: guest requests to /webruntime/api/services/data/vNN.0/graphql, especially a sequence of API versions
• Salesforce Aura: high-volume guest activity on /aura or /s/sfsites/aura
• Salesforce registration probes: repeated requests to /SiteRegister and /CommunitiesSelfReg across community paths
• ServiceNow: guest POST requests to /api/now/sp/search?sysparm_cancelable=true at non-human volume

These are campaign indicators, not timeless signatures. Infrastructure can move and headers can change. Organisations should preserve the known values for retrospective searches, then build detections around anonymous access, automation-like cadence and unusually large responses.

How to respond

Start with evidence, then reduce the guest identity to the minimum access required for the public service.

• Hunt the known address and client fingerprint. Search Salesforce and ServiceNow request logs for 158.220.87.79 and Go-http-client/1.1. Review older retained data as well as current traffic because the infrastructure has existed since March 2025.
• Review Salesforce Event Monitoring. Reco recommends examining AuraRequest and Sites event data for the campaign address, user agent, high-volume Aura actions, LWR /webruntime/ paths and self-registration probes.
• Audit each Salesforce site’s guest profile. Check guest sharing rules, object permissions, field-level security, permission sets, Access Activities, file visibility, member visibility, Apex access and self-registration. Salesforce’s guest-profile best practices provide the vendor baseline.
• Challenge LWR public API access. If a site does not need anonymous UI API access, disable “Allow guest users to access public APIs” in its Administration preferences. Salesforce lists this as a recommended attack-surface reduction in its API access guidance. Test changes in a sandbox because legitimate public components can depend on the setting.
• Filter ServiceNow’s transaction log. Look for the source IP and URLs beginning with /api/now/sp/search. Guest-created REST rows, escalating request counts and larger-than-baseline output lengths deserve priority.
• Map ServiceNow portals to search sources. Remove unnecessary sources from public portals. Apply explicit criteria to the sources that remain; ServiceNow documents how to limit a search source with Can View and Cannot View criteria.
• Inspect custom search logic. Require authentication where anonymous search is unnecessary, use GlideRecordSecure or explicit ACL checks for record access and audit knowledge-base read criteria for grants that unintentionally include the guest user.
• Verify from outside the session. Test with no authentication cookie and with the exact rights of the guest identity. An administrator’s browser is the wrong vantage point for validating anonymous exposure.

Blocking the reported IP can reduce immediate exposure, but it is not remediation. The operator can move to another server. If the guest identity can still retrieve sensitive data, the extraction path remains open.

The practical lesson

City-Forum is a cross-platform campaign, but it is not a cross-platform exploit. Its common denominator is delegated anonymous authority.

That distinction changes the defensive task. The objective is not merely to hide a route, remove one user-agent string or wait for a vendor patch. It is to inventory every unauthenticated identity, trace what records and functions it can reach and prove that each grant exists for a current business reason.

Public SaaS experiences are applications, not brochures. They contain APIs, search services, custom code and identities with persistent permissions. When those permissions are broader than the public purpose, a patient attacker does not need a zero-day. A loop and a guest account are enough.

Official sources and further reading

• Reco: The “City-Forum” Campaign
• Salesforce: Configuration of Salesforce Sites and Experience Site Guest User Access Control Permissions
• Salesforce: Best Practices and Considerations When Configuring the Guest User Profile
• Salesforce: Review Guest User Object, Record, and Field Access for Sites
• ServiceNow: Configuring search in a portal
• ServiceNow: User criteria for Service Portal
• ServiceNow: Glide Server APIs and GlideRecordSecure
• Go source: net/http default user agent

The City-Forum infrastructure and vendor interfaces may change after publication. Recheck the current Reco report and the latest Salesforce and ServiceNow documentation before applying broad production changes.