CVE-2021-24472

What it actually does

This vulnerability exposes proxy functionality in the OnAir2 WordPress theme before 3.9.9.2 and the QT KenthaRadio WordPress plugin before 2.0.2 to unauthenticated users. An attacker can cause the WordPress web server to fetch attacker-supplied URIs and return the fetched content in the HTTP response. Technically, this enables server-side request forgery against internal-only services, cloud metadata endpoints, loopback services, and network resources reachable from the web server. Depending on how the fetched content is handled, it can also enable remote file inclusion-style abuse, sensitive data disclosure, internal service probing, and potential follow-on compromise through exposed admin panels or credentials.

Why it matters to the business

A public WordPress site running an affected theme or plugin can be abused as a network pivot without requiring login. Attackers may use the site to read cloud instance metadata, discover internal systems, access services that are not supposed to be internet-facing, or retrieve sensitive files or responses through the vulnerable server. Because exploit maturity is weaponized and EPSS is high at approximately 56.6%, exposed instances should be treated as high-priority even though this CVE is not currently listed in CISA KEV and is not specifically marked as ransomware-associated. The provided package metadata referencing Ubuntu MySQL does not align with the described vulnerable WordPress components, so remediation should focus on confirming whether the OnAir2 theme or QT KenthaRadio plugin is installed while separately validating any operating-system package advisories through normal patch management.

How an attack unfolds

An attacker first identifies a WordPress site using the vulnerable OnAir2 theme or QT KenthaRadio plugin, often by fingerprinting theme or plugin paths, static assets, or WordPress metadata. The attacker then sends an unauthenticated request to the exposed proxy functionality with a target URI under their control. To confirm exploitability, they may point the proxy to an attacker-controlled callback server and verify that the request originates from the victim web server. After confirmation, the attacker changes the requested URI to internal or sensitive targets such as loopback addresses, RFC1918 network ranges, cloud metadata services, local admin interfaces, or other services reachable from the WordPress host. The vulnerable site fetches the target content server-side and returns it to the attacker, allowing internal reconnaissance and possible disclosure of credentials, tokens, configuration data, or service responses. If useful secrets or internal access are obtained, the attacker may use them for lateral movement, cloud account access, administrative login attempts, or additional exploitation.

How to fix it

Upgrade the affected WordPress components to fixed versions: OnAir2 WordPress theme version 3.9.9.2 or later, and QT KenthaRadio WordPress plugin version 2.0.2 or later. If either component is not required, remove it entirely rather than leaving it disabled but present. After upgrading, clear WordPress, CDN, reverse-proxy, and application caches. Restrict outbound network access from web servers so they cannot reach cloud metadata endpoints, internal administrative interfaces, databases, or arbitrary private network ranges unless explicitly required. Where available, require IMDSv2 or equivalent hardened metadata access controls for cloud workloads. Add web application firewall or reverse-proxy rules to block unauthenticated proxy requests containing suspicious schemes or internal destinations such as file://, php://, gopher://, dict://, localhost, 127.0.0.1, 169.254.169.254, and RFC1918 address ranges. The fixed-version entries in the input referencing Ubuntu MySQL packages do not correspond to the described WordPress theme/plugin vulnerability; confirm applicability through WordPress inventory and vendor advisories rather than treating MySQL package upgrades as the primary fix for this CVE.

How to confirm the fix worked

Confirm the installed WordPress theme and plugin versions through the WordPress admin interface, filesystem inspection, or WP-CLI. For WP-CLI, review installed themes and plugins and verify that OnAir2 is at least 3.9.9.2 and QT KenthaRadio is at least 2.0.2. Confirm that vulnerable component files are not still present in wp-content/themes/onair2 or wp-content/plugins/qt-kentharadio after remediation. Perform an authorized negative test against the formerly exposed proxy functionality using a benign attacker-controlled callback URL; the server should not perform unauthenticated arbitrary fetches. Also test that requests targeting localhost, 127.0.0.1, private IP ranges, link-local metadata IPs, and dangerous URI schemes are blocked. Review outbound firewall, proxy, and cloud metadata controls to ensure the WordPress host cannot reach sensitive internal resources unnecessarily.

Typical attack path

1. Fingerprint a public WordPress site for the OnAir2 theme or QT KenthaRadio plugin using page source, static asset paths, or known WordPress discovery techniques.
2. Locate the unauthenticated proxy functionality exposed by the vulnerable component.
3. Submit a proxy request for an attacker-controlled URL to verify that the victim server performs outbound fetching.
4. Use the proxy to request internal targets such as 127.0.0.1, localhost, private IP ranges, or cloud metadata endpoints.
5. Analyze returned responses for credentials, metadata, internal service banners, configuration details, or administrative interfaces.
6. Use any recovered secrets or internal knowledge to attempt follow-on access, privilege escalation, or lateral movement.
7. Optionally automate requests to enumerate reachable internal hosts and services from the WordPress server's network position.

How to detect it

Investigate whether the vulnerable WordPress site was already abused by correlating inbound web requests with outbound network activity from the web server. Start with web server, CDN, reverse-proxy, and WAF logs and search for unauthenticated requests to WordPress AJAX, theme, or plugin paths that include full URLs, internal IP addresses, loopback addresses, cloud metadata hostnames, or uncommon URI schemes. Pay particular attention to requests containing 169.254.169.254, latest/meta-data, metadata.google.internal, localhost, 127.0.0.1, 10., 172.16-31., 192.168., file://, php://filter, gopher://, dict://, or URLs embedded as query-string values. Correlate timestamps with outbound firewall, EDR network telemetry, DNS resolver logs, and proxy logs showing the WordPress process, PHP-FPM, Apache, or Nginx connecting to unexpected internal destinations or attacker-controlled domains. For cloud-hosted systems, review metadata service access logs or equivalent control-plane telemetry for unusual token or credential retrieval from the web server. Also inspect WordPress files for post-exploitation changes, including new PHP files under wp-content, modified theme/plugin files, newly created administrator accounts, suspicious scheduled tasks, and unexpected outbound connections by web-server processes. Because SSRF exploitation may not leave a dropped file, absence of filesystem artifacts does not rule out compromise; network and access-log correlation are the highest-value evidence sources.

• /wp-content/themes/onair2/
• /wp-content/plugins/qt-kentharadio/
• admin-ajax.php
• 169.254.169.254
• 169.254.169.254/latest/meta-data
• latest/meta-data/iam/security-credentials
• metadata.google.internal
• metadata/instance
• 127.0.0.1
• localhost
• 0.0.0.0
• [::1]
• 10.
• 172.16.
• 172.17.
• 172.18.
• 172.19.
• 172.20.
• 172.21.
• 172.22.
• 172.23.
• 172.24.
• 172.25.
• 172.26.
• 172.27.
• 172.28.
• 172.29.
• 172.30.
• 172.31.
• 192.168.
• file://
• php://filter
• gopher://
• dict://
• ftp://
• sftp://
• http://localhost
• http://127.0.0.1
• http://169.254.169.254
• url=http
• uri=http
• src=http
• source=http
• proxy=http

What your security team should do

• Immediately inventory WordPress sites for the OnAir2 theme and QT KenthaRadio plugin, including inactive themes and plugins left on disk.
• Patch or remove affected components, prioritizing internet-facing WordPress sites because exploitation is unauthenticated, network-accessible, and weaponized.
• Do not rely on the Ubuntu MySQL package mapping as proof of remediation for this issue; validate the WordPress theme/plugin versions directly.
• Review web access logs, reverse-proxy logs, WAF logs, DNS logs, outbound proxy logs, and cloud metadata access logs for evidence of SSRF probing or successful data retrieval.
• Block outbound web-server access to 169.254.169.254, localhost-only services, private address ranges, and internal administrative interfaces unless explicitly required.
• Deploy WAF or reverse-proxy detections for proxy parameters containing internal IPs, metadata service hostnames, loopback names, or dangerous URL schemes.
• Rotate any cloud credentials, API keys, or secrets that may have been accessible from the WordPress host if exploitation is suspected.
• Harden WordPress by removing unused plugins/themes, disabling direct file editing, enforcing least-privilege filesystem permissions, and monitoring for unexpected new files or admin accounts.