Improper Access Control on www.target.example through /services/formcampaign via header "option" leads to unauthenticated read/write on the production marketing-campaign database
An unauthenticated AEM Sling servlet exposes four CRUD operations (getData / getDataById / setData / updateData) on the internal marketing-campaign database via a single option request header. The only access control is a Referer string check that any HTTP client trivially bypasses. Anonymous attackers can read the full 79-campaign dataset (including internal segmentation logic and the names of internal prospect databases), create arbitrary new campaigns in the production backoffice, and overwrite existing real production campaigns.
Summary
A vulnerability was identified where an unauthenticated, internet-facing servlet exposed full CRUD access to the bank's internal marketing-campaign database. The endpoint accepted POST requests with no session, no CSRF token and no authentication — its only "protection" was a check on the Referer header that any HTTP client can set in one line. Four operations were reachable through a single option request header, allowing any anonymous attacker to read the entire campaign dataset, create new campaigns in the production backoffice and overwrite existing production campaigns.
Vulnerability Details
The endpoint POST /services/formcampaign is an AEM Sling servlet that proxies four different operations against an internal Spring Boot backend (com.target.backend.campaigns):
POST /v1/martech/api/campaigns ← create