Summary

• Severity: Low (CVSS 5.3 — Broken Access Control)
• Affected software: Pretty Google Calendar WordPress plugin — versions ≤ 2.0.0
• Vulnerability class: Broken access control / missing authorization
• CVE: CVE‑2025‑12898
• Disclosure date: 19 Dec 2025
• Impact: Leakage of Google API key to unauthenticated visitors via a plugin endpoint; potential abuse of API key until the key is rotated or restricted.
• Immediate recommended actions: deactivate or remove the plugin, rotate/lock the Google API key, apply server rules to block the vulnerable endpoint, audit Google API usage and site logs.

From a Hong Kong security expert perspective: this advisory provides practical, prioritised steps to assess, mitigate and recover from the issue. It explains how the vulnerability works, how exploitation might happen, indicators to look for, immediate mitigations (including server/WAF examples), developer fixes, and an incident response checklist.

What happened (plain language)

Certain versions (≤ 2.0.0) of the Pretty Google Calendar WordPress plugin expose a Google API key through a plugin endpoint without proper authorization or nonce/capability checks. Unauthenticated users can call the endpoint and receive configuration that contains the API key. An attacker with that key can make API requests to Google services (subject to the key’s permissions and restrictions), which can consume quotas, incur charges, or perform allowed operations.

This is a broken access control issue (CVSS 5.3). Real-world risk depends on how the site owner configured the API key (referrer/IP restrictions, API restrictions, billing). A restricted key has much lower practical risk than an unrestricted one.

Technical summary

• Vulnerability type: Broken access control (missing authorization) causing sensitive configuration disclosure.
• What’s leaked: Google API key (format commonly begins with “AIza…”).
• How it’s exposed: An unauthenticated plugin endpoint (REST route or AJAX endpoint) returns plugin settings/config that include the Google API key. The endpoint lacks permission checks (capabilities, nonces or rest permission callbacks).
• Affected plugin versions: Pretty Google Calendar ≤ 2.0.0
• CVE: CVE‑2025‑12898
• Exploitation: trivial to low complexity — a simple HTTP request to the endpoint returns the API key in JSON.

Note: precise exploit payloads are intentionally withheld to reduce automated abuse; the goal is to enable rapid protection by site owners.

Why this matters

API keys can authenticate access to Google services. If leaked and unrestricted, an attacker can:

• Consume API quota (leading to service disruption).
• Cause unexpected billing if the project has billing enabled.
• Read or write data where the API key grants access (subject to API permission model).
• Map or enumerate internal usage if the key is reused across services.

Broken access control is a common class of CMS flaws. Keys are sensitive secrets and must never be returned to unauthenticated visitors.

Indicators of compromise (IoCs) and detection tips

Inspect your site and Google Cloud console for these signs:

1. HTTP requests to plugin endpoints from unknown IPs — look for “pretty-google-calendar”, “pgc” or similar in request URIs.
2. Unexpected GET/POST requests for configuration endpoints — calls to admin-ajax.php or /wp-json/ routes returning JSON containing strings like “AIza”.
3. Google API console anomalies — sudden spikes in usage for Calendar, Maps or related services linked to the key; requests from unexpected referrers/IP ranges.
4. Billing / quota alerts — quota exhaustion or unexpected billing charges.
5. Web server logs showing repeated reads of the same configuration endpoint from many IPs or scanning infrastructure.

Search examples (logs): grep for “pretty-google-calendar” or for “AIza” in response bodies (if you capture responses). Check access logs for frequent calls to /wp-admin/admin-ajax.php or /wp-json with parameters indicating plugin usage.

Immediate remediation (prioritised)

If you manage a site using Pretty Google Calendar (≤ 2.0.0), follow these practical steps now:

1. Deactivate or remove the plugin — highest priority. If you cannot take the site offline, deactivate the plugin until a vendor fix is available. This removes the vulnerable endpoint.
2. Rotate the Google API key — in Google Cloud Console, delete or regenerate exposed API key(s). Create a new key and apply strict restrictions.
3. Restrict the new API key immediately — restrict by HTTP referrer (website domain), IP address (for server keys), and by specific APIs; set quotas and alerts.
4. Apply temporary server or WAF blocking for the vulnerable endpoint(s) — block the plugin path via server configuration (.htaccess, Nginx) or with a WAF rule to return 403 for requests to the offending endpoint.
5. Audit Google API usage and server logs — look for suspicious calls using the exposed key and for unexpected calendar changes.
6. Monitor and enforce limits — add alerts in Google Cloud Console for spikes or unusual usage.
7. When a patch is released — update the plugin to the fixed version, test in staging, and only re-enable after keys are rotated and confirmed secure.

How to harden your site immediately with server/WAF rules

Below are example rules to block or mitigate calls against the vulnerable plugin endpoints. Treat them as temporary virtual patches until the plugin is fixed. Test before deploying to production.

A) Generic ModSecurity rule to block URIs containing the plugin slug

SecRuleEngine On
SecRule REQUEST_URI "@rx /wp-(content|admin).*pretty-google-calendar" "id:100001,phase:1,deny,status:403,log,msg:'Blocked request to Pretty Google Calendar plugin path'"

B) Block suspicious admin-ajax actions or REST routes (ModSecurity example)

# Block AJAX action or REST path that returns configuration
SecRule ARGS_NAMES|ARGS "@rx (pretty[-_]?google[-_]?calendar|pgc|prettygooglecalendar)" "id:100002,phase:2,deny,status:403,log,msg:'Blocked plugin action parameter'"

C) Nginx location deny for plugin folder

# Return 403 for any access to plugin's public API files (temporary mitigation)
location ~* /wp-content/plugins/pretty-google-calendar/ {
    return 403;
}

D) Apache .htaccess to deny direct access

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/plugins/pretty-google-calendar/ - [F,L]
</IfModule>

E) Response content filter (detect Google API key pattern) — caution

Response body scanning can be resource heavy. Use with care.

# ModSecurity example to detect Google API key pattern in response and block or sanitize
SecRule RESPONSE_BODY "@rx AIza[0-9A-Za-z-_]{35,}" "id:100010,phase:4,deny,status:403,log,msg:'Response contains Google API key - blocked'"

Notes: blocking the entire plugin folder is blunt but effective; ensure you won’t break required functionality. Response-body inspection helps stop leaks but may affect performance.

Detection signatures (logging / SIEM)

Add these to detection lists or SIEM searches:

• Access log entries: GET /wp-json/*pretty-google-calendar* OR /wp-content/plugins/pretty-google-calendar/* (many IPs or high frequency)
• POST or GET to /wp-admin/admin-ajax.php with ARGS containing plugin slug, action names, or parameters producing settings (e.g., “action=pgc_get_settings”)
• Response body pattern: “AIza” followed by alphanumeric + – _ characters
• Google Console: API key usage from unknown referers or regions, sudden spikes in requests to Calendar, Maps, or other enabled APIs

Search examples (bash/grep):

grep -i "pretty-google-calendar" /var/log/nginx/access.log
grep -i "admin-ajax.php" /var/log/apache2/access.log | grep -i "pretty"
# look for 'AIza' in saved response captures (if you log response bodies):
grep -i "AIza" /var/log/httpd/response_bodies/*.log

Developer guidance — how to fix properly

If you maintain the plugin codebase, implement these fixes:

1. Do not expose API keys in endpoints reachable by unauthenticated visitors. Never return raw API keys in JSON responses to public endpoints. If client-side access is required, use a restricted key or a server-side proxy that performs limited operations.
2. Enforce permission checks for all endpoints:
   • For admin-only/config endpoints, require appropriate capabilities (e.g., current_user_can(‘manage_options’)).
   • For AJAX handlers, use check_ajax_referer() and capability checks.
   • For REST routes, set permission_callback to validate authentication and user capabilities — never use __return_true for endpoints that reveal secrets.
3. Sanitize outputs and avoid storing secrets in plugin options that are exported to front-end JS. Keep API keys server-only; when creating client-facing JS, only send strictly necessary values.
4. Consider environment variables or WP config constants for production keys and document how administrators should configure restricted keys.
5. Add unit and integration tests that verify sensitive endpoints are not accessible by unauthenticated users; include security reviews in release processes.
6. Provide clear disclosure and patching guidance to users, including whether key rotation is required.

Example REST registration with permission callback:

register_rest_route( 'pretty-google-calendar/v1', '/settings', array(
    'methods'  => 'GET',
    'callback' => 'pgc_get_settings',
    'permission_callback' => function () {
        return current_user_can( 'manage_options' );
    },
) );

Incident response checklist for site owners

If the plugin on your site is affected, follow this plan:

Immediate

• Deactivate plugin.
• Rotate the exposed Google API key(s) in Google Cloud Console (delete old key, create new one).
• Restrict the new key to specific referrers and allowed APIs.
• Block vulnerable plugin endpoints via server rules or WAF.
• Take a snapshot/backup of the current site for forensics.

Triage

• Review access logs for suspicious requests to the endpoint.
• Examine Google Cloud monitoring for unusual usage.
• Search the site for other exposed secrets.

Contain & eradicate

• Rotate all related credentials if suspicious use is found.
• Remove malicious artifacts and run a full malware scan as needed.
• Update or replace the plugin when a vendor patch is available; test in staging before re-enabling.

Recover

• Re-enable services only after keys are rotated and the plugin is patched.
• Monitor logs and Google Console quotas closely for 7–14 days.

Post-incident

• Document timeline and remediation steps.
• Review hardening posture: WAF/server rules, least privilege for keys, monitoring and alerting.
• Consider virtual patching in WAF for future rapid mitigation.

How to minimise the risk of API key leaks in future (best practices)

• Use API key restrictions: referrer restrictions for browser keys; IP restrictions or API restrictions for server keys.
• Prefer OAuth or server-to-server authentication when sensitive operations are required.
• Never embed production keys in client-side JavaScript unless strictly necessary and restricted by referrer/domain.
• Limit keys to the smallest necessary scope (least privilege).
• Set quotas and alerts on APIs to detect spikes quickly.
• Maintain a key-rotation schedule and automate where possible.
• Scan code and plugin settings for secrets regularly with secret scanning tools.
• Include security reviews and automated tests in your release pipeline.

Example timeline and what to expect

• Immediate mitigation window: hours — rotate keys, apply server rule, deactivate plugin.
• Patch by plugin vendor: days to weeks — vendors typically release a fixed version; test before upgrading.
• Monitoring after remediation: 7–30 days — watch for abuse or related activity.

FAQ (short answers)

Is my site definitely compromised if it uses Pretty Google Calendar?

Not necessarily. The vulnerability allows retrieval of a key if an attacker calls the endpoint. Exploitation requires someone to call the endpoint and use the key. That is why rotating keys and blocking the endpoint are critical.

If I rotate the key and apply restrictions, do I still need to update the plugin?

Yes. Rotating keys and restricting them reduces risk but does not remove the coding flaw. Update to a patched plugin as soon as it is available.

Can I rely solely on referrer restrictions for safety?

Referrer restrictions are helpful but not a substitute for secure coding. Combine server-side authorization checks with key restrictions and perimeter controls.

Closing thoughts

Broken access control that exposes secrets is a recurring problem across CMS ecosystems. A single misconfigured endpoint leaking an API key can scale into quota abuse, unexpected charges, and secondary attacks. The mitigation steps are straightforward and should be executed quickly:

1. Remove access to the endpoint (deactivate or remove the plugin).
2. Rotate and restrict keys immediately.
3. Apply server/WAF rules to prevent further leakage.
4. Patch the plugin and harden configuration.

Adopt a layered approach: secure coding on the plugin side, strict key management on the cloud/provider side, and perimeter controls to apply rapid mitigations while the root cause is fixed.

— Hong Kong Security Expert