Bottom line: The City Forum campaign uses default guest user access to extract data from Salesforce (Aura, LWR) and ServiceNow in a rule-compliant manner via infrastructure that has remained unchanged for 17 months, without compromising the platforms themselves.
The security firm Reco has identified a campaign called City Forum that extracts data from Salesforce (Aura and LWR) as well as ServiceNow via default guest user access. According to the researchers, this is the first publicly observed case of exploitation of the Salesforce UI API guest interface in the wild.
According to Reco, the attackers use a custom binary written in Go that attacks both the older Salesforce Aura interface and the newer LWR implementation, as well as ServiceNow, from the same machine. The central attack vector for both platforms is the default guest user access, through which unauthorized requests are possible. Reco points out that this guest access cannot fundamentally be deleted: permissions, sharing rules, and executable code remain in place even though a login is technically supposed to be required. According to the researchers’ assessment, telecommunications companies, banks, financial service providers, software vendors, and government portals are primarily among the targets.
Compared to the Salesforce Aura campaign by the group ShinyHunters that became known in March 2026, which used only Aura and a modified tool called AuraInspector, City Forum goes significantly further, according to Reco: it additionally attacks a barely documented, native search endpoint of the ServiceNow Service Portal. Reco neither rules out nor confirms involvement of ShinyHunters in City Forum. The infrastructure used is notable: according to the researchers, the same IP address, resolved via the domain city-forum.com, has been in continuous use without change since March 2025 — i.e., for more than 17 months without rotation.
What is relevant for CISOs is that neither City Forum nor the earlier ShinyHunters campaign constitutes an actual breach of Salesforce or ServiceNow itself. Reco emphasizes that every byte extracted was something the respective site operator itself had made available to anonymous users. Moreover, the data extraction is not conspicuous but occurs at high volume via technically regular, protocol-compliant requests, which makes detection more difficult. At the most heavily affected target, the researchers logged more than 560,000 events over the campaign period, practically fully automated enumeration via guest access; on LWR sites, the query language GraphQL was additionally used.
So far, Reco has observed activity exclusively via the unauthenticated guest access. However, a shift to an authenticated account cannot be ruled out, particularly since enabled self-registration on Salesforce would allow such a transition. No comparable mechanism exists for ServiceNow. Together with the analysis, Reco has published indicators of compromise as well as remediation recommendations. Affected organizations are advised, above all, to immediately check whether self-registration for guest users is disabled, in order to prevent the transition of a guest access to an authenticated account.