Stealthy City-Forum: Attacks on Salesforce & ServiceNow

A new wave of City-Forum aanvallen puts the spotlight on a striking type of web application risk: abuse of unauthenticated guest user access. Research describes how a campaign targets Salesforce and ServiceNow using a custom, multi-platform set of tooling—aimed at discovering data and content through portals and search or API endpoints.

Key detail: there’s no indication that the attackers compromised Salesforce or ServiceNow themselves. What they retrieve appears to come from what site owners have already made available to anonymous visitors.

What is City-Forum and why is it so targeted?

The campaign is named ‘City-Forum’. Researchers point to a custom-made multi-platform toolset that targets both Salesforce and ServiceNow. The targets are broad: telecom, banking and financial services providers, enterprise software vendors (including security and privacy companies), and portals in the public sector.

The attacks don’t appear to rely on a “standard” scanner. Instead, the behavior is described as consistent with in-house tooling: a single Go binary could carry out Salesforce attacks across different implementations—and also hit ServiceNow—coming from the same source.

Guest users as the key: why login doesn’t always help

The core of the story is the role of the Guest User. In many configurations, an Experience Cloud (or similar portal) can work with its own guest user account, where an unauthenticated request succeeds. Researchers explain that such guest accounts aren’t simply removable, and that requiring login doesn’t fully eliminate the risk: profile data, permissions, sharing rules, and even code running in that context remain in place.

In other words: if the guest user can read records, then in principle an anonymous internet visitor could do the same—at least as long as the permissions allow it.

Impact on Salesforce Aura and LWR

The campaign is linked to attacks on Salesforce Aura and on LWR (the newer LWR implementations). The research highlights that this is among the first in-the-wild observations of abuse of the Salesforce UI-API guest surface. Since Aura is still far more common than LWR, it’s not surprising that Aura is an integral part of the activity, while LWR is targeted as well.

Additionally, the research indicates that the attacks on Aura and LWR are bundled within the same campaign using the same toolset.

Impact on ServiceNow: a search endpoint with limited documentation

ServiceNow also comes into focus. A notable aspect is that the campaign appears to strongly focus on a ServiceNow Service Portal search endpoint that reportedly has almost no public documentation or widely known open-source tooling. That could explain why it isn’t easy to recognize the behavior early using common checks.

By “detecting” content via search results, attackers can estimate where value is located and then pick the most promising results for further collection.

One machine, long game: less footprint

According to researchers, City-Forum operates with a single constant source machine: the same IP has shown the same domain behavior since March 2025 and continues to scan. The IP associated with the activity is 158.220.87.79 and is linked to city-forum.com.

The advantage of a fixed source is that it can reduce the “footprint” for anomaly detection. That doesn’t mean the activity is untraceable, but it can make it harder to identify the pattern when there’s no rotation.

In the research, it also isn’t concluded that the attackers have a single specific organization behind them; who carries out the campaign remains unknown.

Is it authenticated—or does it stay with guests?

The main observation concerns unauthenticated guest user activity. For Salesforce, there is potentially another route: if self-registration is enabled, a guest user could possibly be promoted to an authenticated account status. In that scenario, additional permissions—and potentially more data—could follow.

For ServiceNow, no similar mechanism is described. The research also suggests that “being an authenticated guest user” doesn’t appear to be necessary for the campaign’s success, though it could provide additional access to sensitive data.

So far, researchers report seeing only guest activity, with no evidence of authenticated users. At the same time, they do not rule out that this could happen in the future.

How much data, and what type of exfiltration?

The campaign is primarily aimed at data collection and retrieving information that is already available to anonymous visitors. There’s no indication of a “platform breach” where Salesforce or ServiceNow themselves were accessed.

For Salesforce, researchers mention large volumes. The busy target produced more than 560,000 events within the campaign window—virtually all traceable to guest Aura enumeration. For LWR sites, data is also pulled via GraphQL.

For ServiceNow, the focus is on the search endpoint: researchers describe that rows with output longer than the baseline with empty results often contain content. With those signals, an attacker can select the most promising results.

When it comes to detection, exfiltration doesn’t appear to be “messy” or generically noisy. It’s high volume, but with protocol-valid behavior. That makes it harder to recognize as an attack and may indicate an intent to stay as stealthy as possible.

What can you do now? Practical security steps

If your organization manages Experience Cloud portals or Service Portals, this research mainly comes down to one thing: verify what anonymous access can reach. The campaign isn’t “magic”; it leverages permissions and surfaces that site owners themselves have exposed.

1) Limit self-registration in Salesforce

A direct recommendation from the research is to not enable self-registration. That makes it harder for an unauthenticated guest to progress into an authenticated state with potentially broader rights.

2) Reassess guest permissions and sharing rules

Go through which records a guest user can read. Don’t focus only on database permissions—also review sharing rules and any configuration that activates code in the guest context. The principle is straightforward: if the guest can read it, anonymous internet traffic can generally access it too in practice.

3) Analyze portal search behavior and UI-API usage

Because City-Forum targets both Salesforce UI-API guest surfaces and ServiceNow portal search activities, it’s worth connecting logs and monitoring to “patterns” rather than treating incidents in isolation. Think about unusually high numbers of queries against search or API endpoints—especially when they appear to consistently come from the same direction.

4) Harden security at the portal configuration level

The attack isn’t tied to a proven platform breach, but to misuse of what was already publicly available. That makes hardening the portal configuration crucial: minimize anonymous datasets, limit visibility, and ensure defaults aren’t set too broadly.

Does your risk decrease if you already have “some” security?

Many organizations already implement measures such as firewalls, web filters, and endpoint detection. Still, this campaign shows that even without a platform compromise, an attack can succeed via the application layer and configuration. It’s therefore smart to broaden your security work to “what is open to anonymous visitors” and “which APIs/search endpoints respond with usable content?”

If you also look at earlier incidents involving app surfaces and misuse of vulnerable access routes, you’ll see the same lesson recurring: limit data exposure from the layer where anonymity enters. A comparable perspective can be found in our article about WhatsApp Scam Alert: warnings on your device—not the same technical domain, but the same focus on preventing abuse of access and activation pathways.

Conclusion

The City-Forum aanvallen show how a combination of guest user access, portal surfaces, and stealthy, protocol-legitimate behavior can lead to large-scale data collection—without needing a Salesforce or ServiceNow platform breach. The campaign targets Salesforce Aura and LWR, plus a ServiceNow Service Portal search endpoint that appears to be relatively unknown.

For teams, the takeaway is clear: check guest permissions, limit self-registration where applicable, and monitor portal and API behavior for signs of enumeration and content discovery. That reduces the chance that anonymous users gain access to information you didn’t intend to expose to everyone.