Web Application Penetration Test

1. Executive Summary

JS Web Design Services conducted a web application penetration test against www.example-client.org on 2026-07-14, under written authorisation from the site owner.

The target is a WordPress installation running on Apache behind a full-page cache, with a commercial security suite providing baseline hardening — including a hidden login page and REST API user-enumeration blocking. Those controls work as intended, and are recorded in section 8.

They are, however, bypassed entirely by the two critical findings below. 18 findings were identified in total:

1. Unauthenticated arbitrary file upload leading to remote code execution (F1). An outdated plugin's REST upload handler validates files by request-supplied MIME type rather than content, allowing a .php file to be written into a web-readable directory and executed.
2. Unauthenticated SQL injection on a booking endpoint (F2). Confirmed via a time-based oracle; provides read access to the full database including password hashes.
3. An abandoned plugin (no update in over three years) and an out-of-date core remain in active use, with automatic updates disabled (F3).
4. A publicly readable JSON file discloses the complete plugin inventory and database schema, directly accelerating exploitation of F2 (F4).
5. The administrator username is enumerable through two unblocked vectors, and no two-factor authentication is enforced (F5, F16).
6. A stored cross-site scripting flaw executes in the administrator's moderation screen, and no Content-Security-Policy is present to contain it (F7, F11).

Remote code execution was confirmed during testing using a benign, non-persistent proof-of-concept that was removed immediately afterwards. No data was extracted, no records were modified, and no denial-of-service was performed. No evidence of prior compromise was found — no web shells, injected code or unexpected administrator accounts were present — but the site should be treated as at immediate risk until F1 and F2 are remediated.

Risk rating summary

2. Scope & Methodology

Testing followed the OWASP Testing Guide v4.2 and OWASP API Security Top 10 (2023), covering:

1. Passive and active reconnaissance
2. Technology stack and version fingerprinting
3. Authentication and session management analysis
4. Input validation testing (XSS, SQLi, file upload, SSRF)
5. Security header analysis
6. SSL/TLS configuration review
7. API surface enumeration and testing
8. Plugin CVE cross-referencing
9. Attack chain construction

Rules of engagement. Testing was non-destructive. Where a vulnerability could be confirmed without impact — a timing oracle for SQL injection, a benign marker for XSS, a non-persistent file for upload — that method was used and the artefact removed. No data was extracted, no records modified, and no denial-of-service performed.

3. Technology Stack

4. Risk Summary

5. Detailed Findings

F1 — Unauthenticated Arbitrary File Upload → Remote Code Execution CRITICAL

Severity: Critical  |  CVSS: 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  |  CWE-434 — Unrestricted Upload of File with Dangerous Type

Affected component: /wp-json/<vendor>/v1/upload (media handler in an outdated third-party plugin)

An outdated third-party plugin registers a REST upload handler that does not require authentication and validates the uploaded file by MIME type supplied in the request rather than by extension or content. A file with a permitted MIME header but a .php extension is written into the uploads directory and is directly reachable over HTTP, giving unauthenticated remote code execution as the web-server user.

Evidence

POST /wp-json/<vendor>/v1/upload      -->  201 Created
Content-Type: multipart/form-data
  filename="probe.php"  (declared MIME: image/jpeg)

GET  /wp-content/uploads/2026/07/probe.php  -->  200 OK
  (benign proof-of-concept: echoed a fixed token, no shell, no persistence)

File removed immediately after confirmation, with client approval.

Impact

1. Full remote code execution as the web-server user — the highest-impact outcome in this engagement.
2. Enables webshell installation, database credential theft from wp-config.php, and lateral movement to other sites on the same account.
3. Bypasses every application-layer control, including the security plugin's login hardening.

Remediation

1. Treat as an emergency. Update or remove the affected plugin before any other remediation.
2. Block PHP execution inside uploads: <Directory /wp-content/uploads> php_flag engine off </Directory>
3. Audit the uploads directory for any pre-existing .php files and treat the site as potentially compromised until confirmed clean.
4. Rotate database credentials and WordPress salts after remediation.

F2 — Unauthenticated SQL Injection in Booking Endpoint CRITICAL

Severity: Critical  |  CVSS: 9.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N  |  CWE-89 — Improper Neutralization of Special Elements used in an SQL Command

Affected component: /wp-json/<vendor>/v1/availability?resource_id=

The resource_id parameter is concatenated directly into a SQL WHERE clause without parameterisation or sanitisation. A time-based blind payload produced a reproducible, measurable delay, confirming injection. No data was extracted and no rows were modified — confirmation was limited to a timing oracle, per the non-destructive rules of engagement.

Evidence

GET /wp-json/<vendor>/v1/availability?resource_id=1          -->  200  (0.11s)
GET /wp-json/<vendor>/v1/availability?resource_id=1%20AND%20SLEEP(5)  -->  200  (5.13s)
GET /wp-json/<vendor>/v1/availability?resource_id=1%20AND%20SLEEP(2)  -->  200  (2.09s)

Delay tracks the injected value -> injection confirmed.
No UNION/data-extraction payloads were executed.

Impact

1. Unauthenticated read access to the full database, including wp_users password hashes and session tokens.
2. Password hashes enable offline cracking and subsequent administrator takeover.
3. Combined with F1, provides a second independent path to full site compromise.

Remediation

1. Update the affected plugin immediately; if no patch exists, disable it until one is released.
2. Ensure all queries use $wpdb->prepare() with placeholders — never string concatenation.
3. Deploy a WAF rule to block SQL metacharacters on this endpoint as an interim control.
4. Force a password reset for all administrator and editor accounts after patching.

F3 — Outdated WordPress Core & Abandoned Plugin in Use HIGH

Severity: High  |  CVSS: 8.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N  |  CWE-1104 — Use of Unmaintained Third Party Components

Affected component: WordPress core; one plugin with no update in 3+ years

The installation is several minor versions behind the current release and one active plugin has received no update in over three years and is flagged as abandoned in the plugin directory. Abandoned components receive no security patches, so any vulnerability disclosed against them stays exploitable indefinitely.

Evidence

WordPress core     : 6.9.1   (behind current release)
Abandoned plugin   : last updated 2023-02 — flagged 'no longer maintained'
Active installs    : plugin still enabled and reachable on the front end
Auto-updates       : disabled for both core and plugins

Impact

1. Known, publicly documented vulnerabilities remain unpatched and are trivially discoverable from version disclosure (see F14).
2. An abandoned plugin will never be fixed — the only remediation is replacement or removal.
3. Disabled auto-updates mean the window of exposure grows with every new disclosure.

Remediation

1. Update WordPress core to the current release after taking a full backup.
2. Replace the abandoned plugin with a maintained equivalent, or remove it if the feature is unused.
3. Enable automatic security updates for core, and review plugin update policy monthly.

F4 — Plugin & Database Schema Disclosure (optimiser JSON file) HIGH

Severity: High  |  CVSS: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information

Affected component: /wp-content/uploads/<optimiser>/plugin-tables-list.json

A publicly accessible JSON file written by an optimisation plugin is exposed in the uploads directory. The file maps 18,400+ database table names to 5,900+ plugin slugs, confirming the optimiser is installed, enabling complete plugin fingerprinting, revealing e-commerce and security-plugin table structures, and handing an attacker a ready-made target map for the SQL injection in F2. A robots.txt Disallow directive does not prevent direct HTTP access.

Evidence

GET /wp-content/uploads/<optimiser>/plugin-tables-list.json
HTTP/1.1 200 OK  |  Content-Length: 812446

Notable tables disclosed:
  <ecommerce>_api_keys, <ecommerce>_payment_tokens, <ecommerce>_sessions
  <security>_bans, <security>_lockouts, <security>_logs
  <builder>_events, <cache>_optimizer, <cache>_img_optm
  All SEO-plugin internal tables + custom plugin tables

Impact

1. Full inventory of installed plugins (including premium plugins) and the complete database table structure.
2. Directly accelerates exploitation of F2 — the attacker skips schema enumeration entirely.
3. Security-plugin internal tables disclosed, potentially aiding circumvention of those controls.

Remediation

1. Delete the file from the uploads directory immediately.
2. Add server-level access control: <DirectoryMatch "wp-content/uploads/<optimiser>"> Require all denied </DirectoryMatch>
3. Review optimiser settings to prevent future writes to a web-readable directory.
4. Note: robots.txt Disallow does not restrict access — server-side controls are required.

F5 — WordPress Username Enumeration (administrator account exposed) HIGH

Severity: High  |  CVSS: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information

Affected component: /?author=<ID> redirects, /author-sitemap.xml

The security plugin correctly blocks REST API user enumeration at /wp-json/wp/v2/users, but two alternative vectors remain unprotected. (1) Author ID redirect — requesting /?author=N redirects to /author/<username>/, exposing the username in the URL. (2) The SEO-plugin-generated author sitemap lists all author archive URLs directly, including the administrator account.

Evidence

GET /?author=2   -->  301  -->  /author/[redacted_user_a]/
GET /?author=4   -->  301  -->  /author/[redacted_admin]/   [ADMINISTRATOR]
GET /?author=5   -->  301  -->  /author/[redacted_user_b]/
GET /?author=7   -->  301  -->  /author/[redacted_user_c]/

5 valid usernames enumerated in total.
Also confirmed via /author-sitemap.xml (SEO plugin generated).

Impact

1. 5 valid WordPress usernames discovered, including the administrator account.
2. Enables brute-force, Application Password authorisation flows, or credential stuffing.
3. Login protection is significantly weakened once the administrator username is known.
4. Combines with the password hashes obtainable via F2 for rapid offline cracking.

Remediation

1. Disable author archive redirects in functions.php by redirecting is_author() / ?author= requests to home_url().
2. Disable author archives in the SEO plugin: Search Appearance → Author Archives → disabled.
3. Create a new admin user with a non-guessable username and delete the exposed administrator account.

F6 — Personal Data Disclosure via Public Calendar API HIGH

Severity: High  |  CVSS: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information / data-protection concern

Affected component: /wp-json/<calendar>/v1/organizers

A calendar plugin's REST organizers endpoint is accessible without authentication and returns personal contact information belonging to the site's developer, together with a link to the staging/CMS environment. A further 180+ events and 20+ venues are fully readable unauthenticated.

Evidence

GET /wp-json/<calendar>/v1/organizers  -->  200 OK

{ "organizer": "Test organizer entry",
  "email":   "[REDACTED]",
  "phone":   "[REDACTED]",
  "website": "https://staging.[REDACTED].example/cms",
  "author":  4 }

Impact

1. Personal data exposed without authentication — a probable breach of data-protection obligations (GDPR / PDPA and equivalents).
2. Staging environment disclosed — non-production hosts typically carry weaker controls, providing a lateral path.
3. Social engineering risk — contact details enable targeted phishing or pretexting of the developer.

Remediation

1. Remove or anonymise the test organizer entry immediately.
2. Redact PII fields from the endpoint response with a server-side filter that unsets email and phone.
3. Assess the disclosed staging environment for additional exposures and put it behind authentication.

F7 — Stored Cross-Site Scripting in Event Submission Field MEDIUM

Severity: Medium  |  CVSS: 6.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N  |  CWE-79 — Improper Neutralization of Input During Web Page Generation

Affected component: Front-end event submission form → moderation queue

A front-end submission field stores input without output encoding. Script supplied by an unauthenticated submitter is rendered in the administrator moderation screen, so the payload executes in an authenticated admin session — an effective privilege escalation path.

Evidence

POST /events/submit/   field: description
  payload: <img src=x onerror="/* benign marker only */">

Rendered unencoded at /wp-admin/edit.php?post_type=<calendar>
(Confirmed with a harmless DOM marker; no cookie theft or admin action performed.)

Impact

1. Script executes in an administrator's authenticated session when they review submissions.
2. Can be leveraged to create a new administrator account or exfiltrate session tokens.
3. Requires no credentials from the attacker — only that an admin views the queue.

Remediation

1. Escape on output with esc_html() / wp_kses_post() in the moderation view.
2. Sanitise on input with sanitize_textarea_field() for all front-end submissions.
3. Add a Content-Security-Policy (see F11) to reduce the impact of any residual XSS.

F8 — Security Plugin REST API Schema Fully Exposed MEDIUM

Severity: Medium  |  CVSS: 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information

Affected component: /wp-json/<security-plugin>/v1/

The complete security-plugin REST API schema is publicly readable without authentication, revealing every security endpoint including bans, firewall rules, lockout management, logs, file-tree browsing, scanner results and user actions. The schema also discloses all WordPress roles in use. Authentication is still required to call these endpoints, but the schema hands an attacker a precise map of the security infrastructure.

Evidence

GET /wp-json/<security-plugin>/v1/  -->  200 OK

Disclosed endpoints include:
  /rpc/ban-users/add-many
  /v1/firewall/rules        (GET, POST)
  /v1/lockouts
  /v1/logs
  /v1/settings
  /v1/user-actions          (force-logout, reset-password)
  /v1/site-scanner/vulnerabilities
  /rpc/file-change/file-tree

Impact

1. Provides a complete map of security-plugin endpoints, reducing attacker reconnaissance effort.
2. Enables targeted authentication-bypass attempts against known administrative endpoints.

Remediation

1. Block REST access to the security-plugin namespace for unauthenticated users at the web-server level.

F9 — WordPress REST API Root Endpoint Accessible (287 routes) MEDIUM

Severity: Medium  |  CVSS: 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information

Affected component: /wp-json/

The REST API root returns a large JSON response listing all 287 registered routes with full parameter schemas, accepted HTTP methods and validation rules, including routes for every installed plugin. The response also discloses the site timezone, the Application Passwords authorisation endpoint and the complete authentication configuration.

Evidence

GET /wp-json/  -->  200 OK  (392,118 bytes)

287 routes across 11 namespaces, including the vulnerable
upload handler (F1) and booking endpoint (F2).

Auth: { application-passwords: { authorization: /wp-admin/authorize-application.php } }

Impact

1. Complete API surface mapping enables targeted exploitation — this is how F1 and F2 were located.
2. Confirms installed plugin names and versions implicitly through namespace versions.
3. Discloses the Application Passwords authorisation endpoint, useful in credential attacks.

Remediation

1. Restrict REST API discovery for unauthenticated users via rest_authentication_errors returning HTTP 401.
2. Whitelist only the public namespaces actually required by the front end.

F10 — XML-RPC Endpoint Active MEDIUM

Severity: Medium  |  CVSS: 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L  |  CWE-307 — Improper Restriction of Excessive Authentication Attempts

Affected component: /xmlrpc.php

The XML-RPC endpoint is active and accessible. This legacy interface enables remote procedure calls including authentication, post creation and file uploads. It is commonly abused for brute-force amplification — a single request can test hundreds of credential pairs — and for SSRF.

Evidence

POST /xmlrpc.php  -->  200 OK
<methodResponse> … system.multicall available …

Combined with the administrator username from F5, this is a
practical credential-attack surface.

Impact

1. Enables XML-RPC brute-force amplification — one request can test hundreds of credential pairs.
2. May be used for SSRF attacks against internal network resources.
3. Provides an attack surface that bypasses standard login hardening.

Remediation

1. Disable XML-RPC if not required: add_filter('xmlrpc_enabled', '__return_false');
2. Or block at web-server level: <Files xmlrpc.php> Require all denied </Files>

F11 — Missing Critical HTTP Security Headers MEDIUM

Severity: Medium  |  CVSS: 5.4 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N  |  CWE-693 — Protection Mechanism Failure

Affected component: All HTTP responses

Multiple critical HTTP security headers are absent from all server responses. These headers form a fundamental browser-side security layer; their absence exposes users to clickjacking, cross-site scripting, MIME sniffing and protocol-downgrade attacks — and materially increases the impact of the stored XSS in F7.

Evidence

HTTP Response Headers (observed):
  Strict-Transport-Security (HSTS)  -->  MISSING
  Content-Security-Policy (CSP)     -->  MISSING
  X-Frame-Options                   -->  MISSING
  X-Content-Type-Options            -->  MISSING
  Referrer-Policy                   -->  MISSING
  Permissions-Policy                -->  MISSING

Impact

1. Absence of HSTS allows SSL-stripping attacks on non-HTTPS connections.
2. Absence of X-Frame-Options / CSP frame-ancestors enables clickjacking.
3. Absence of X-Content-Type-Options allows MIME sniffing, compounding the file-upload issue in F1.
4. Absence of CSP significantly increases the impact of the stored XSS in F7.

Remediation

1. Add Strict-Transport-Security "max-age=31536000; includeSubDomains; preload".
2. Add X-Frame-Options "SAMEORIGIN", X-Content-Type-Options "nosniff", Referrer-Policy "strict-origin-when-cross-origin".
3. Implement Content-Security-Policy — start in report-only mode to identify required sources before enforcing.
4. Validate with an external header analyser.

F12 — Cache Plugin Debug Directory Publicly Accessible MEDIUM

Severity: Medium  |  CVSS: 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N  |  CWE-538 — Insertion of Sensitive Information into Externally-Accessible File

Affected component: /wp-content/<cache-plugin>/debug/

The cache plugin's debug directory is publicly accessible (HTTP 200). If debug logging is ever enabled, session cookies and authentication tokens are written to log files in this directory, readable by any unauthenticated user. This is the precondition for a known critical account-takeover class of vulnerability. No log files were present during testing, but the directory remains exposed.

Evidence

GET /wp-content/<cache-plugin>/debug/  -->  200 OK
(Directory accessible — no log files present at time of test)

Related advisories for this plugin family:
  CVE-2024-44000  CVSS 9.8  Unauthenticated account takeover via debug log
  CVE-2024-28000  CVSS 9.8  Privilege escalation via role simulation
  CVE-2024-47374  CVSS 7.1  Unauthenticated XSS via admin settings

Impact

1. If debug logging is enabled, session cookies become publicly readable, enabling unauthenticated account takeover.
2. If the plugin version is below the patched release, one or more CVSS 9.8 issues may be directly applicable.

Remediation

1. Block public access immediately: <DirectoryMatch "wp-content/<cache-plugin>/debug"> Require all denied </DirectoryMatch>
2. Confirm the installed version and update to the latest release as a priority.

F13 — Contact Form File Upload Schema Disclosed LOW

Severity: Low  |  CVSS: 3.7 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information

Affected component: /wp-json/<forms>/v1/contact-forms/{id}/feedback/schema

The contact-form REST API exposes the complete validation schema for all forms without authentication. For the document upload form this discloses accepted file types and size limits, letting an attacker craft targeted upload payloads without trial-and-error enumeration.

Evidence

GET /wp-json/<forms>/v1/contact-forms/5/feedback/schema

{ "your-file": {
    "type": "file",
    "accept": ".pdf,.doc,.docx",
    "maxSize": 2097152
  } }

Impact

1. Allows crafting of targeted file-upload payloads without enumeration.
2. Compounds F1 — the attacker learns exactly what the application expects to receive.

Remediation

1. Restrict the contact-form REST schema endpoint for unauthenticated users via a rest_pre_dispatch filter.

F14 — Server & Plugin Version Disclosure LOW

Severity: Low  |  CVSS: 3.7 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N  |  CWE-200 — Exposure of Sensitive Information

Affected component: HTML source, HTTP headers, RSS feed, license.txt

Multiple version-disclosure vectors expose exact software versions across the site, significantly reducing the reconnaissance effort required for targeted CVE exploitation — and directly enabling identification of the outdated components in F3.

Evidence

WordPress core         -->  RSS <generator> tag, asset ?ver= params, license.txt (HTTP 200)
Cache plugin version   -->  HTML comment in every page footer
Forms plugin version   -->  Script tag ?ver=
SEO plugin version     -->  SEO plugin head API response
Web server             -->  Server: HTTP header

Impact

1. Precise version identification enables targeted CVE research and exploit selection without active scanning.

Remediation

1. Strip ?ver= params from assets via the style_loader_src / script_loader_src filters.
2. Disable the cache-plugin footer comment in its advanced settings.
3. Block license.txt and readme.html at the web-server level.

F15 — HTTP PUT and DELETE Methods Accepted LOW

Severity: Low  |  CVSS: 3.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N  |  CWE-749 — Exposed Dangerous Method or Function

Affected component: Site root

The server returns HTTP 200 for PUT and DELETE on the root URL instead of the expected 405 Method Not Allowed. This violates least privilege and may interact unexpectedly with caching layers.

Evidence

PUT    /  -->  200 OK   (expected: 405)
DELETE /  -->  200 OK   (expected: 405)
TRACE  /  -->  405 Method Not Allowed  (correct)

Impact

1. Low direct impact, but violates least privilege and may interact unexpectedly with caching or CDN configurations.

Remediation

1. Restrict accepted methods: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>

F16 — Application Passwords Enabled Without 2FA INFORMATIONAL

Severity: Informational  |  CVSS: —  |  CWE-308 — Use of Single-factor Authentication

Affected component: /wp-admin/authorize-application.php

The Application Passwords feature is enabled and its authorisation endpoint is disclosed via the REST API root response. Application passwords generate long-lived credentials that bypass two-factor authentication, and no 2FA is currently enforced on administrator accounts.

Evidence

Disclosed in /wp-json/ authentication configuration:
  "authorization": "/wp-admin/authorize-application.php"

No two-factor requirement observed on the login flow.

Impact

1. Long-lived credentials can bypass 2FA if it is later introduced.
2. Increases the overall credential attack surface for administrator accounts.

Remediation

1. Enforce two-factor authentication for all administrator and editor accounts.
2. If Application Passwords are not required, disable the feature.

F17 — WP-Cron Publicly Triggerable INFORMATIONAL

Severity: Informational  |  CVSS: —  |  CWE-400 — Uncontrolled Resource Consumption

Affected component: /wp-cron.php

The WP-Cron endpoint returns HTTP 200 and can be triggered by any external request, potentially causing unnecessary server load through repeated invocations.

Evidence

GET /wp-cron.php  -->  200 OK (0 bytes, 0.6s execution time)

Impact

1. Repeated external requests can cause unnecessary server load and resource consumption.
2. May be used for timing-based information gathering.

Remediation

1. Disable public WP-Cron: define('DISABLE_WP_CRON', true);
2. Add a real server cron job running every 15 minutes instead.

F18 — Public Calendar API & Analytics Identifiers Exposed INFORMATIONAL

Severity: Informational  |  CVSS: —  |  CWE-200 — Exposure of Sensitive Information

Affected component: /wp-json/<calendar>/v1/events, HTML <meta> tags

The calendar REST API is fully readable without authentication, and site-verification and analytics identifiers are present in page source. Both are common and largely intentional, but they assist fingerprinting and cross-site tracking correlation.

Evidence

GET /wp-json/<calendar>/v1/events  -->  200 OK (180+ events, unauthenticated)
Meta: site-verification token  -->  [REDACTED]
Analytics measurement ID       -->  [REDACTED]

Impact

1. Low direct risk. Enables structured data extraction and plugin fingerprinting.
2. Analytics identifiers can be used for cross-site tracking correlation by third parties.

Remediation

1. If public structured event data is intended, this is acceptable.
2. Ensure the organizer endpoint does not expose PII (see F6).
3. Consider a server-side tag container for enhanced privacy control.

6. Attack Chain Analysis

Findings are rarely exploited in isolation. The chains below show how issues combine — which is why several medium-severity items are prioritised above their individual rating.

Chain 1: Unauthenticated upload → remote code execution → full server compromise

F9  (REST root discloses the vulnerable upload route)
  → F1  (MIME-only validation accepts a .php file)
    → File written to a web-readable uploads path
      → Code execution as the web-server user
        → wp-config.php credentials → database → other sites on the account

Chain 2: SQL injection → credential extraction → administrator takeover

F4  (complete table-to-plugin map disclosed)
  → F2  (unauthenticated SQLi on the booking endpoint)
    → Attacker skips schema enumeration, targets wp_users directly
      → Password hashes extracted → offline cracking
        → F5 supplies the administrator username → account takeover

Chain 3: Stored XSS → administrator session → privilege escalation

F7  (unauthenticated submission stored without encoding)
  → Payload rendered in the admin moderation screen
    → F11 (no CSP to contain it)
      → Script runs in an authenticated admin session
        → New administrator account created silently

Chain 4: Username enumeration → credential attack

F5  (administrator username via author sitemap)
  → F10 (XML-RPC accepts multicall — hundreds of guesses per request)
    → F16 (Application Passwords available, no 2FA enforced)
      → Targeted brute-force or credential stuffing → full site compromise

Chain 5: Personal data disclosure → developer compromise → lateral movement

F6  (developer email, phone and staging CMS URL exposed)
  → Social engineering / phishing of the developer
    → Compromise of the staging environment
      → Access to production source code, config and credentials

7. Vulnerability Cross-Reference

Priority action: F1 and F2 were confirmed by testing and require no public advisory to be exploitable. Treat both as emergency remediation before addressing anything else in this report.

8. Positive Security Controls

The following measures are already in place and functioning correctly. We record these deliberately — a report that lists only problems gives an unbalanced picture of a site's posture, and these controls meaningfully limit several attack paths.

9. Remediation Roadmap

About this document. This is a specimen report published by JS Web Design Services to demonstrate the structure, depth and evidence standard of our deliverables. It is an illustrative composite — not a transcript of any single client engagement — and all identifying details have been removed or generalised. Live client reports are never published; they are delivered privately through an encrypted, password-protected link.