When Guest Access Becomes a Looting Path

Introduction

Customer portals are built for convenience: log in less, find answers faster, and expose only what outsiders need to see. That same design goal can become a liability when guest access is broader than intended. A campaign tracked as City-Forum has been linked to custom tooling aimed at data visible to anonymous users across Salesforce Experience Cloud and ServiceNow customer portals.

The available information supports a risk analysis, not a definitive statement about the full scope of compromise. At the time of writing, public information has not fully established the exact root cause, the complete scale of affected users, or whether every targeted portal yielded successful exfiltration.

Fast Facts

• City-Forum is the label used for an ongoing data-theft campaign.
• The activity targets Salesforce Experience Cloud and ServiceNow customer portals.
• Custom tools are reported to be used against data exposed to anonymous users.
• The root cause remains unconfirmed: misconfiguration, overbroad sharing, or another access-control issue are all possible.
• Guest-access features can be legitimate, but they need tight limits and regular review.

Body

The technical story is less about a classic break-in and more about the abuse of trust boundaries. Both Salesforce and ServiceNow support public or guest-facing portal features in some configurations. That is useful for self-service, but it also means the security boundary often sits in permissions, sharing rules, field visibility, page components, and API restrictions rather than in a single hardened login screen.

Netcrook’s read is that the real danger lies in overexposed data paths. If a portal page, widget, search source, object, or API returns information that should not be public, custom automation can turn that mistake into repeatable collection at scale. Depending on configuration, attackers may not need malware or a zero-day exploit - they may only need a route that the platform is already willing to serve to an anonymous visitor.

That is why vendor guidance around least privilege matters so much here. In practice, defenders should review guest-user profiles, reduce public object and field access, keep external sharing private by default, and disable guest access to APIs unless there is a clear business need. For portal-heavy deployments, it is also important to inventory which pages, widgets, and data-list components are public, because one overlooked component can undo careful access design elsewhere.

The broader operational lesson is straightforward: public SaaS surfaces should be treated like internet-facing assets, because they are. When anonymous access is intentional, the risk does not disappear - it changes shape. The challenge becomes ensuring that convenience does not quietly outrun control.

Conclusion

City-Forum is a reminder that modern data theft does not always start with intrusion. Sometimes it starts with a portal doing exactly what it was configured to do, just for too many people. In cloud environments, the smallest permission mistake can become the largest extraction path.

WIKICROOK

• Guest user: An unauthenticated visitor who can access public parts of a portal without signing in.
• Least privilege: A security principle that gives each user or system only the minimum access needed.
• Field-level security: A control that limits which data fields a user can view or edit.
• Access control: The rules that decide who can see, change, or export data in a system.
• Data scraping: Automated collection of information from web pages or portal content at scale.