CVE-2023-6360

What it actually does

CVE-2023-6360 is an unauthenticated SQL injection vulnerability in the My Calendar WordPress plugin before version 3.4.22. The vulnerable REST API route, /my-calendar/v1/events, fails to safely handle the from and to parameters before using them in database queries. Because the endpoint is network-accessible and requires no authentication, an attacker can send crafted HTTP requests that alter the intended SQL query. Successful exploitation can allow extraction of sensitive database contents, modification or deletion of data, and potentially further compromise of the WordPress site depending on database privileges and site configuration.

Why it matters to the business

A public WordPress site using a vulnerable version of the My Calendar plugin can be compromised remotely without a valid login. The likely consequences include theft of user or customer data, unauthorized content changes, website defacement, service disruption, reputational damage, compliance exposure, and potential pivoting into broader WordPress compromise. The risk is high because the vulnerability has a critical CVSS score, a high EPSS probability, and is assessed as weaponized, meaning working exploitation is available or practical in the wild.

How an attack unfolds

An attacker identifies a WordPress site running the My Calendar plugin and probes the unauthenticated REST endpoint at /wp-json/my-calendar/v1/events or equivalent REST route paths. The attacker supplies malicious SQL syntax in the from or to query parameters. If the plugin version is vulnerable, the injected input is incorporated into the backend SQL query, allowing the attacker to manipulate query logic. The attacker may first use boolean, error-based, or time-based payloads to confirm injection, then automate data extraction from the WordPress database, including user records, password hashes, email addresses, plugin data, and configuration values. In more damaging scenarios, the attacker may attempt database writes, create or alter WordPress content, abuse exposed credentials, or chain the database compromise with other weaknesses to gain administrative control or plant persistent malware.

How to fix it

Upgrade the My Calendar WordPress plugin to version 3.4.22 or later. If immediate upgrade is not possible, temporarily disable or remove the plugin until it can be patched. Restrict access to the WordPress REST API endpoint /wp-json/my-calendar/v1/events using a web application firewall, reverse proxy rule, or equivalent control, but treat this only as a temporary mitigation. Review database user privileges used by WordPress and ensure the application account does not have unnecessary administrative privileges. After patching, rotate credentials if evidence suggests database contents may have been accessed, including WordPress administrator passwords, database passwords, API keys, and any secrets stored in the database or configuration files.

How to confirm the fix worked

Confirm that the installed My Calendar plugin version is 3.4.22 or later from the WordPress admin plugin page, filesystem plugin metadata, or WP-CLI. Using WP-CLI, verify with a command such as wp plugin list and check the my-calendar plugin version. Confirm the vulnerable REST route no longer accepts SQL control input in the from or to parameters by testing safely in a non-production environment or through an approved vulnerability scanner. Review WAF, web server, and application logs to ensure requests to /wp-json/my-calendar/v1/events with suspicious from or to values are blocked or no longer produce SQL errors, abnormal responses, or timing differences. If the plugin was exposed before patching, perform compromise assessment rather than assuming patching alone resolves prior data exposure.

Typical attack path

1. Scan public WordPress sites for the My Calendar plugin or exposed My Calendar REST API routes.
2. Send unauthenticated requests to /wp-json/my-calendar/v1/events using the from and/or to parameters.
3. Inject SQL metacharacters or boolean/time-based SQL payloads into the vulnerable parameters.
4. Confirm exploitability through abnormal responses, SQL errors, changed result sets, or response delays.
5. Automate SQL injection to enumerate database metadata and extract sensitive WordPress data.
6. Use stolen data, password hashes, or configuration secrets to escalate access or support follow-on compromise.
7. Optionally modify database content, create persistence, deface the site, or disrupt availability.

How to detect it

Investigate web access logs, WAF/CDN logs, reverse proxy logs, WordPress application logs, database error logs, and endpoint telemetry from the web server. Focus on requests to the My Calendar REST API route, especially /wp-json/my-calendar/v1/events, where the from or to query parameters contain SQL metacharacters, comments, UNION queries, sleep/benchmark functions, information_schema references, or encoded equivalents. Look for repeated requests with small variations, long response times, HTTP 500 errors, database syntax errors, or unusually large responses from the events endpoint. Review database logs for unexpected SELECTs against WordPress user tables, schema enumeration, or error messages generated around the time of suspicious HTTP requests. Also check for post-exploitation artifacts in WordPress: newly created administrator accounts, unexpected plugin or theme modifications, unfamiliar PHP files in writable directories, suspicious wp_options changes, and credential or configuration access following the suspected exploitation window.

• /wp-json/my-calendar/v1/events
• /my-calendar/v1/events
• from=
• to=
• UNION SELECT
• UNION%20SELECT
• UNION+SELECT
• information_schema
• SLEEP(
• SLEEP%28
• BENCHMARK(
• BENCHMARK%28
• WAITFOR DELAY
• --
• %2D%2D
• /*
• %2F%2A
• */
• %2A%2F
• ' OR '1'='1
• %27%20OR%20%271%27%3D%271
• " OR "1"="1
• %22%20OR%20%221%22%3D%221
• extractvalue(
• updatexml(
• SQL syntax
• You have an error in your SQL syntax
• WordPress database error
• wp_users
• wp_options

What your security team should do

• Patch immediately by upgrading My Calendar to version 3.4.22 or later, especially for internet-facing WordPress sites.
• If patching cannot be completed immediately, disable the My Calendar plugin or block unauthenticated access to /wp-json/my-calendar/v1/events at the edge.
• Search historical web server, WAF, CDN, and WordPress logs for suspicious requests containing /my-calendar/v1/events and SQL injection syntax in from or to parameters.
• Prioritize investigation where logs show time-based SQL injection payloads, UNION SELECT attempts, database error responses, or repeated enumeration-style requests.
• Run an inventory for all WordPress installations and identify any use of the joedolson My Calendar plugin below 3.4.22.
• Harden WordPress database privileges and ensure the database account cannot perform unnecessary high-risk operations.
• If exploitation is suspected, rotate WordPress administrator credentials, database credentials, and secrets stored in the WordPress database or configuration files.
• Monitor for follow-on compromise indicators such as newly created administrator users, modified plugin/theme files, unexpected scheduled tasks, malicious PHP files, or outbound connections from the web server.