zypher.co / reports / getconnects-cross-tenant-segment-creation signed in · client link
Penetration test report

GetConnects

F-02: Unauthorized segment creation across tenants
April 2026 Delivered 2026-04-23
Risk index
88
/ 100
Severity distribution
Critical
0
High
1
Medium
0
Low
0
Info
0
Executive summary

The /api/segment/create endpoint accepts an organisation field on the create payload and does not verify that the requesting session belongs to that organisation. An authenticated user in any tenant can create segments that live inside another tenant. Because segments are consumed downstream by targeting, notification, and campaign workflows, the write can persist into outbound communications sent under the target tenant's brand.

Finding 2 of 5 from the GetConnects multi-tenant API assessment. Delivered , published .

Engagement
Client
GetConnects
Endpoint
POST /api/segment/create
Class
BOLA (OWASP API1) on a write path
Auth required
Any valid session
CVSS vector
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L
Status
Reported, remediation and retest cycle in progress
Redaction notice. The API host and tenant identifiers have been genericized. Endpoint path, request shape, severity, and technical finding are unmodified.

Findings

1 total
01 High
F-02: Unauthorized segment creation across tenants
BOLA on write path · POST /api/segment/create
8.8 reported +
Description

The pattern is the same as F-01, applied to the write path. The handler trusts the client-supplied organisation identifier and writes the new segment to that tenant without checking that the caller belongs. A valid session cookie is required to reach the endpoint, but the session's own tenant is never compared against the requested one.

Impact

Data integrity across tenants. An attacker in tenant A can create arbitrary segments inside tenant B. Depending on downstream use of those segments (targeting, notifications, campaign inclusion), the impact ranges from noise inside the target tenant's admin UI to unwanted outbound communications sent under the target tenant's brand. In the worst case a maliciously crafted segment forms the addressing side of a phishing campaign that the platform then executes against contacts belonging to the target tenant.

Downstream reputation risk is the more material concern: SMS traffic originated by GetConnects tenants generally flows through the tenant's approved sender identity, so any outbound triggered by a foreign-created segment is attributable to that tenant.

Remediation
  1. Centralise tenant scoping in middleware. Take the target tenant from the authenticated session, not the body. Any endpoint that legitimately writes across tenants becomes an explicit opt-in with its own gate.
  2. Reject client-supplied organisation on write endpoints. Prefer server-derived values.
  3. Log tenant boundary violations at the middleware layer even when the request would otherwise pass. This surfaces attempted probes against any remaining gaps.
  4. Add an integrity gate for downstream campaign or notification systems that verifies the segment's tenant matches the actor's tenant at execution time, so a stray segment cannot cause outbound traffic under a foreign tenant's brand.
Evidence

Proof-of-concept request:

POST /api/segment/create HTTP/2
Host: [REDACTED]
Content-Type: application/json
Cookie: token=<valid_user_in_tenant_A>

{
  "json": {
    "name": "test",
    "organisation": "<target_org_id_in_tenant_B>",
    "criteria": {
      "and": [
        { "field": "firstName", "operator": "contains", "value": "a" }
      ]
    }
  }
}

The segment is created inside tenant B and appears in tenant B's downstream segment list, addressable by users in tenant B who legitimately have segment permissions.

Root cause

  • Authorization is applied per-handler and inconsistently. This handler was written without a tenant-membership check.
  • The tenant identifier is taken from the request body rather than derived from the authenticated session.
  • The write path has no cross-tenant guard even though the read path (F-01) has none either, so the two failures compound.

Timeline

DateEvent
Engagement window; finding delivered on .
Following weeksRemediation and retest cycle.
Public release of redacted writeup.
Remediation in progress Delivered 2026-04-23 Published 2026-07-12
More reports →