CVE-2026-12095: Kargo Takip WordPress Plugin SSRF Flaw

CVE-2026-12095 Overview

CVE-2026-12095 is a Server-Side Request Forgery (SSRF) vulnerability in the Kargo Takip plugin for WordPress, affecting all versions up to and including 1.2. The flaw resides in the api_url parameter handled by the decodeandview.php script. Unauthenticated attackers can force the WordPress server to issue HTTP requests to arbitrary destinations, including internal services not reachable from the public internet. The script also echoes the value of any auth key from a JSON response back to the attacker's browser, enabling direct exfiltration of data from internal endpoints such as cloud instance metadata services. The vulnerability is classified under CWE-918.

Critical Impact
Unauthenticated SSRF allows attackers to probe internal networks, query cloud metadata services, and exfiltrate authentication tokens returned in JSON auth fields.

Affected Products

WordPress plugin: Kargo Takip versions 1.0 through 1.2
WordPress installations with the Kargo Takip plugin enabled
Cloud-hosted WordPress sites where instance metadata endpoints are reachable from the web server

Discovery Timeline

2026-06-24 - CVE-2026-12095 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-12095

Vulnerability Analysis

The Kargo Takip plugin exposes a script at ui/decodeandview.php that accepts a user-supplied api_url parameter. The script performs an outbound HTTP request to the supplied URL without validating the destination host, scheme, or address range. Because the endpoint is reachable without authentication, any remote attacker can submit crafted requests through the WordPress front end.

The response handling logic compounds the impact. After fetching the remote URL, the script parses the response as JSON and writes the value of any auth key directly to the HTTP response sent back to the requester. This converts a blind SSRF into a full read SSRF whenever the targeted internal service returns a JSON document containing an auth field.

Common SSRF targets include cloud instance metadata services such as AWS IMDS at 169.254.169.254, Kubernetes API endpoints, internal admin panels, and Redis or Elasticsearch instances bound to loopback. Attackers can also map internal network ranges by observing response timing and content differences.

Root Cause

The root cause is missing input validation on the api_url parameter combined with unrestricted outbound request handling. The plugin does not enforce an allowlist of permitted hostnames, does not block private or link-local IP ranges, and does not require authentication to invoke the endpoint. Reflecting the auth field back to the client further removes the practical barrier of blind exploitation.

Attack Vector

An unauthenticated attacker sends an HTTP request to the vulnerable decodeandview.php endpoint with api_url set to an internal resource such as http://169.254.169.254/latest/meta-data/iam/security-credentials/. The WordPress server fetches the URL from its own network position and returns response content containing any auth key verbatim to the attacker. This allows enumeration of internal services, retrieval of cloud IAM credentials when the response is JSON-formatted, and pivoting against services that trust requests from the application server. See the Wordfence Vulnerability Report and the WordPress Plugin Code Review for source-level details.

Detection Methods for CVE-2026-12095

Indicators of Compromise

HTTP requests to /wp-content/plugins/kargo-takip/ui/decodeandview.php containing an api_url query parameter
Outbound requests from the web server to private IP ranges such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 127.0.0.0/8
Outbound requests from the web server to cloud metadata addresses including 169.254.169.254 and fd00:ec2::254
Unexpected JSON responses containing auth fields returned through the plugin endpoint

Detection Strategies

Inspect web server access logs for requests targeting decodeandview.php with non-vendor URLs in api_url
Correlate inbound requests to the plugin endpoint with outbound network connections from the WordPress host
Alert on any HTTP request from a web server to link-local metadata IP addresses
Deploy WAF rules that block api_url values resolving to private, loopback, or link-local addresses

Monitoring Recommendations

Enable egress logging on WordPress hosts and forward records to a centralized SIEM for correlation
Monitor cloud audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) for unexpected API calls originating from the web server identity
Track rate and diversity of destinations in outbound HTTP traffic from PHP processes

How to Mitigate CVE-2026-12095

Immediate Actions Required

Deactivate the Kargo Takip plugin until a patched release is published and verified
Apply IMDSv2 with hop-limit 1 on AWS instances to defeat metadata SSRF from the application layer
Restrict outbound traffic from WordPress hosts to an allowlist of required destinations
Place a WAF rule in front of decodeandview.php that rejects requests where api_url resolves to private or link-local addresses

Patch Information

At the time of CVE publication on 2026-06-24, no patched version of the Kargo Takip plugin had been listed in the NVD record. Administrators should monitor the Wordfence Vulnerability Report and the plugin's WordPress.org page for an updated release that validates the api_url parameter.

Workarounds

Remove or rename ui/decodeandview.php within the plugin directory to disable the vulnerable endpoint
Block the endpoint at the web server using an Nginx location deny rule or Apache <Location> block
Enforce egress filtering that denies requests from the PHP worker to RFC1918 and link-local ranges
Require authentication in front of the plugin endpoint using HTTP basic auth at the reverse proxy

bash

# Nginx configuration to block the vulnerable endpoint
location ~* /wp-content/plugins/kargo-takip/ui/decodeandview\.php$ {
    deny all;
    return 403;
}

# Egress filter example using iptables to block metadata access
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner www-data -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -m owner --uid-owner www-data -j DROP