Affected product: Domain For Sale – Sell Domains with Landing Pages, Offers & Inquiries
Vendor: ThemeAtelier
Affected version: 3.5.1 – Fixed in 3.5.2
Vulnerability type: Missing Authorization / Broken Access Control
CWE: CWE-862 — Missing Authorization
Suggested CVSS 4.0 vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N
Researcher: Labda
Summary
The Domain For Sale WordPress plugin version 3.5.1 exposes sensitive REST API endpoints without enforcing authentication or authorization.
An unauthenticated remote attacker can:
- retrieve all stored offer records;
- delete arbitrary offer records by numeric identifier; and
- access administrative dashboard and business statistics.
The exposed offer records may contain bidder names, email addresses, phone numbers, proposal text, offer values, verification tokens, IP addresses, browser and device information, and WordPress-related user details.
Affected endpoints
GET /wp-json/domain-for-sale/v1/offers
DELETE /wp-json/domain-for-sale/v1/offers/{id}
GET /wp-json/domain-for-sale/v1/dashboard?period=all_time
Preconditions
The plugin must be installed and active.
To demonstrate disclosure and deletion, at least one domain listing and one submitted offer must exist. No WordPress account, authentication cookie, REST nonce, or application password is required.
Proof of concept
1. Unauthenticated disclosure of offer records
Send the following request without cookies, authorization headers, or a WordPress REST nonce:
curl -i 'https://TARGET/wp-json/domain-for-sale/v1/offers'
The server responds with HTTP 200 and returns stored offer records in JSON format.
The response may contain sensitive information including:
- bidder names;
- email addresses;
- phone numbers;
- proposal text;
- offer amounts;
- verification tokens;
- source IP addresses;
- browser and device metadata;
- WordPress usernames and email addresses; and
- associated domain-listing information.

2. Unauthenticated deletion of offer records
An attacker can delete an offer by supplying its numeric identifier:
curl -i -X DELETE \
'https://TARGET/wp-json/domain-for-sale/v1/offers/2'
The server responds with HTTP 200 and confirms that the record was deleted:
{
"deleted": true,
"id": 2
}
Because offer identifiers are numeric, an attacker may be able to iterate through identifiers and delete multiple records.

3. Unauthenticated dashboard statistics access
The plugin’s dashboard endpoint is also accessible without authentication:
curl -i \
'https://TARGET/wp-json/domain-for-sale/v1/dashboard?period=all_time'
The server responds with HTTP 200 and exposes administrative and business statistics, including information such as:
- total domain count;
- total listing count;
- total offer count;
- impression statistics;
- chart data;
- domain-performance information; and
- associated user or listing metadata.

Impact
Confidentiality
An unauthenticated attacker can retrieve personal and business-sensitive information stored by the plugin.
Depending on the contents of the offers, the disclosed information may include:
- names;
- email addresses;
- phone numbers;
- offer amounts;
- proposal or message contents;
- email-verification tokens;
- IP addresses;
- browser and device fingerprints;
- WordPress-linked user details; and
- internal business statistics.
Verification tokens and personal information should not be exposed through a publicly accessible REST endpoint.
Integrity
An unauthenticated attacker can delete arbitrary offer records by ID.
This allows an attacker to destroy legitimate bids or inquiries, interfere with domain-sale negotiations, and remove evidence of previous offers.
Availability
Repeated deletion of offer records can make legitimate business data unavailable to the site owner and disrupt the plugin’s offer-management functionality.
The demonstrated impact is limited to data managed by the plugin. The issue does not provide WordPress administrator access, arbitrary option modification, code execution, or filesystem access.
Root cause
The affected WordPress REST API routes do not enforce an effective authorization check before performing sensitive read and delete operations.
Administrative and sensitive routes should use a restrictive permission_callback that verifies both:
- that the requester is authenticated; and
- that the authenticated user has an appropriate capability to access or modify the requested resource.
A permission callback that returns true, uses __return_true, or otherwise fails to verify user capabilities leaves the route publicly accessible.
Disclosure timeline
2026-07-23 — Vulnerability reproduced on an authorized test installation.
2026-07-23 — ThemeAtelier privately notified.
2026-07-23 — Vendor acknowledged the report.
2026-07-24 — Fixed version released.
2026-08-03 — Advisory published.
2026-08-03 — CVE requested.