Executive Takeaway
A server associated with the newly disclosed City-Forum campaign has reportedly been pulling records from Salesforce Experience Cloud sites and ServiceNow Service Portals since at least March 2025. The attacker is not relying on a newly announced vulnerability in either platform. The campaign is exploiting data that customer configurations make available to unauthenticated guest users, according to reporting based on research from SaaS security firm Reco (BleepingComputer, Dark Reading).
That distinction changes the leadership decision. A patch-management team cannot close an exposure created by portal design, sharing rules, search sources, data classification, and unclear application ownership. Organizations operating these platforms should treat the disclosure as a prompt to verify what an anonymous visitor can retrieve, who approved that access, and whether monitoring would reveal systematic extraction.
The immediate action is a bounded review, not a platform-wide shutdown or an automatic purchase of another security product. The longer-term requirement is an operating capability that keeps public SaaS access aligned with changing business processes and data.
What Happened—and What the Evidence Does Not Establish
Reco named the activity City-Forum after a domain associated with the server it observed. Its August 12 disclosure says a single infrastructure cluster has targeted organizations worldwide across telecommunications, financial services, software, security, privacy, and public-sector environments. The same infrastructure reportedly queried both Salesforce and ServiceNow, using custom tooling adapted to each platform (Reco, Dark Reading).
In Salesforce, the reported path involves Experience Cloud guest access. These portals commonly need to expose selected functions to people who have not authenticated, but overly permissive sharing or object access can make additional records retrievable. In ServiceNow, the actor reportedly queried search capabilities exposed through customer-facing Service Portals. Potentially accessible content depends on each customer’s configuration and may include knowledge articles, catalogs, support information, documents, or other records available through configured search sources (BleepingComputer).
Several boundaries matter:
- Reco’s observations do not establish a complete number of targeted or successfully compromised organizations.
- A common server and tool fingerprint support campaign tracking, but do not by themselves prove who operates the infrastructure.
- The presence of probing traffic does not prove that sensitive records were extracted from every target.
- The possible data scope varies substantially because both platforms are highly configurable.
The evidence nevertheless supports a practical conclusion: an organization can be fully patched and still expose business data through an intended public interface.
The Architecture Problem Is Fragmented Ownership
A public SaaS portal sits across several management domains. A business team owns the customer or supplier process. A platform team configures the application. Data owners determine what information is sensitive. Identity teams govern authenticated access. Security may monitor selected logs. Procurement manages the provider relationship.
Anonymous access can fall between those responsibilities. It has no user identity to recertify, may be necessary for the business process, and is often represented by platform-specific settings that few leaders can interpret. A configuration that was reasonable when a portal launched may become unsafe after new objects, fields, knowledge sources, integrations, or business units are added.
This is why a one-time configuration assessment is insufficient. The required capability is to connect four things repeatedly:
- The public business function: what an unauthenticated person must be able to accomplish.
- The accessible data and actions: which records, fields, files, searches, and APIs support that function.
- The accountable decision: who can authorize the exposure and accept the residual risk.
- The operating evidence: how the organization detects drift, bulk retrieval, and access beyond the approved design.
The provider still has important security obligations, but customer accountability cannot stop at the service contract. As discussed in Cloud Security Accountability Cannot Stop at the Contract, assurance depends on evidence that responsibilities are being performed in the deployed environment. City-Forum places the customer-controlled side of that principle in sharp relief.
Business and Industrial Implications
Customer and supplier portals may hold more than contact details. Depending on implementation, they can expose service cases, commercial correspondence, product information, employee details, attachments, asset references, or operational support material. Individually mundane records can become valuable when extracted at scale and combined with other sources.
For industrial organizations, the relevant question is not whether Salesforce or ServiceNow directly controls a plant. It is whether a public portal reveals information that helps someone map the operating environment or exploit trusted relationships. Maintenance cases, facility references, equipment descriptions, supplier identities, outage discussions, remote-support details, or personnel information can improve social engineering and reconnaissance even when no control-system credentials are present.
The same logic applies to API exposure. An interface is not safe merely because it behaves as designed; authorization must reflect the business transaction and its data consequence. CyberEnablement’s earlier analysis, API Security Is Business Security, provides the broader architecture context.
There is also an incident-response implication. SaaS extraction may leave no malware on managed endpoints. If application audit logs are unavailable, retained for too short a period, or disconnected from detection workflows, investigators may struggle to distinguish legitimate public use from automated harvesting. Logging is therefore not just a technical setting. It determines whether leadership can establish exposure and make defensible notification, legal, customer, and recovery decisions.
Prioritized Actions and Leadership Questions
Leaders should ask for a focused response built around known public interfaces, not a generic inventory of every SaaS setting.
| Priority | Accountable owner | Required action | Evidence of progress |
|---|---|---|---|
| Immediate | Salesforce and ServiceNow service owners | Identify every public Experience Cloud site and Service Portal, then test what a new unauthenticated session can search, enumerate, view, and download. | Date-stamped test results mapped to portals, objects, search sources, files, and APIs. |
| Immediate | Security operations with platform administrators | Review available logs for the reported infrastructure and for unusual guest retrieval patterns, sustained enumeration, or bulk downloads. Do not limit the hunt to one IP address. | Documented queries, reviewed time range, findings, limitations, and escalation decisions. |
| Near term | Business process and data owners | Reconfirm which anonymous functions are necessary and remove data paths that do not directly support them. | Approved access statement naming the business owner, data owner, allowed use, and residual risk. |
| Near term | Platform governance owner | Add anonymous-access testing to release, integration, and configuration-change processes. | Change records showing the test occurred before deployment and after material data-model changes. |
| Sustained | CISO, CIO, and application portfolio leadership | Define minimum telemetry and retention requirements for business-critical SaaS platforms. | Coverage reporting that shows which applications can support investigation and which gaps have been accepted. |
The leadership questions are straightforward:
- Who can authorize information to be publicly retrievable?
- Can that person see the actual platform behavior rather than a policy description?
- What event forces revalidation: a release, integration, new data field, acquisition, or business-process change?
- Can the security team investigate historical guest activity without waiting for an emergency provider request?
- Which exposure can be reduced through existing configuration and governance before another tool is considered?
My Perspective
The easy response to City-Forum is to classify it as another SaaS misconfiguration campaign. That description is technically fair but managerially incomplete.
My concern is that “misconfiguration” often obscures the system that produced the condition. A platform administrator may have implemented exactly what a project requested. The project may never have identified a data owner. Security may have reviewed authentication while the portal was intentionally anonymous. Years later, additional data and integrations accumulated behind the same interface.
Calling the result an administrator error encourages another checklist. Treating it as an ownership failure produces a better decision.
Organizations should not try to eliminate every public SaaS capability. Public portals can improve customer service, supplier collaboration, and operating efficiency. The objective is to make anonymous access authorized, classified, monitored, change-managed, and measured. In this context, those attributes mean that a named owner has approved the exposure, accessible data has been deliberately selected, retrieval is observable, changes trigger reassessment, and tests show that the deployed behavior still matches the decision.
A posture-management product may help discover drift across a large application estate, but it cannot decide what the public business process should reveal. That decision belongs to the business and data owners, supported by platform and security expertise.
Conclusion
City-Forum does not establish that every Salesforce or ServiceNow portal is exposed, nor does it prove a defect in the core platforms. It demonstrates something more operationally useful: attackers are willing to study legitimate SaaS features and systematically extract whatever customer configurations permit them to reach.
The proportionate response is to test anonymous access now, investigate available evidence, and close unnecessary paths. The durable response is to assign ownership for the public interface throughout its lifecycle.
If no one can explain what an unauthenticated visitor is allowed to retrieve, who approved it, and how misuse would be detected, the organization does not yet have a controlled portal. It has an undocumented trust boundary exposed to the internet.