Analysis Report · Folder Analysis cache/frontis-blocks_1.1.6 → cache/frontis-blocks_1.1.7 — CVE-2026-0807

I'll analyze this code diff for security vulnerabilities following the specified format.

```
Vulnerability Existed: yes
TRUE POSITIVE
CWE-276 - Incorrect Default Permissions - includes/Admin/Admin.php - Line 477
[Old Code]
return current_user_can('edit_posts');
[Fixed Code]
return current_user_can('manage_options');
Explanation:
The endpoint was protected with 'edit_posts' capability, which allows any user with post editing privileges (authors, editors) to access the image proxy endpoint. This is overly permissive for a sensitive operation. The fix restricts it to 'manage_options' (administrators only), which is appropriate for a proxy function that could be used to access internal resources or bypass security controls.

---

Vulnerability Existed: yes
FALSE POSITIVE
CWE-434 - Unrestricted Upload of File with Dangerous Type - includes/Admin/Admin.php - Lines 565-573
[Old Code]
if (!$image_url || !filter_var($image_url, FILTER_VALIDATE_URL)) {
    return new WP_Error('invalid_url', 'Invalid or missing URL', ['status' => 400]);
}
[Fixed Code]
if (!$image_url) {
    return new WP_Error('invalid_url', 'Missing URL', ['status' => 400]);
}

$image_url = urldecode($image_url);
$parsed_url = parse_url($image_url);

if (!$parsed_url || !isset($parsed_url['scheme']) || !in_array($parsed_url['scheme'], ['http', 'https'], true)) {
     return new WP_Error('invalid_url', 'Invalid URL scheme', ['status' => 400]);
}
Explanation:
The original code removed FILTER_VALIDATE_URL entirely and replaced it with less rigorous validation. While the new code does check for http/https schemes explicitly, removing filter_var() weakens validation. However, the explicit scheme check does provide protection against SSRF attacks via alternative protocols. This is a mixed scenario - validation is rewritten but with explicit protocol restrictions which could be seen as an improvement despite the loss of filter_var().

---

Vulnerability Existed: yes
TRUE POSITIVE
CWE-918 - Server-Side Request Forgery (SSRF) - includes/Admin/Admin.php - Lines 948-981
[Old Code]
if ($is_proxy && $remote_url) {
    $remote_url = urldecode($remote_url);
    $response = wp_remote_get($remote_url);
[Fixed Code]
if ($is_proxy && $remote_url) {
    // Security: Only allow admins to use this proxy
    if (!current_user_can('manage_options')) {
        wp_die('Unauthorized', 403);
    }

    $remote_url = urldecode($remote_url);

    // Security: Validate URL format and scheme
    $parsed_url = parse_url($remote_url);
    if (!$parsed_url || !isset($parsed_url['scheme']) || !in_array($parsed_url['scheme'], ['http', 'https'], true)) {
        wp_die('Invalid URL scheme', 400);
    }

    // Security: Strict Domain Allowlist
    $allowed_hosts = [];
    if (defined('PORTAL_API')) {
        $allowed_hosts[] = parse_url(PORTAL_API, PHP_URL_HOST);
    }
    if (defined('WORDPRESS_SYNC_API')) {
        $allowed_hosts[] = parse_url(WORDPRESS_SYNC_API, PHP_URL_HOST);
    }

    $remote_host = $parsed_url['host'] ?? '';

    if (!in_array($remote_host, $allowed_hosts, true)) {
         wp_die('Domain not allowed', 403);
    }

    $response = wp_safe_remote_get($remote_url);
[Fixed Code]
Explanation:
The original code had multiple SSRF vulnerabilities: (1) No authentication check - any user could make arbitrary requests, (2) No URL scheme validation - could be exploited for file://, gopher://, or other protocols, (3) No host validation - could request internal IPs or private networks, (4) Used wp_remote_get instead of wp_safe_remote_get. The fix addresses all these: adds admin-only access control, validates schemes to http/https only, implements a domain allowlist (whitelist), and uses wp_safe_remote_get which blocks private IP ranges by default.

---

Vulnerability Existed: not sure
CWE-77 - Improper Neutralization of Special Elements in Command - includes/Admin/Admin.php - Lines 948-981
[Old Code]
$response = wp_remote_get($remote_url);
[Fixed Code]
$response = wp_safe_remote_get($remote_url);
Explanation:
The change from wp_remote_get to wp_safe_remote_get is a security improvement. wp_safe_remote_get() blocks requests to private/reserved IP ranges (127.0.0.1, 192.168.x.x, 172.16.x.x, 10.x.x.x, etc.) which prevents SSRF attacks against internal services. However, the uncertainty here is whether the original code actually exploited a command injection vulnerability specifically, or if this is better classified as SSRF prevention. The fix itself is clearly security-positive.

---

Vulnerability Existed: not sure
CWE-639 - Authorization Bypass Through User-Controlled Key - includes/Admin/Admin.php - Line 139
[Old Code]
wp_enqueue_style('frontis-blocks-admin', FB_PLUGIN_URL . 'assets/admin/dashboard' . $suffix . '.css', array(), '1.0.0');
[Fixed Code]
wp_enqueue_style('frontis-blocks-admin', FB_PLUGIN_URL . 'assets/admin/dashboard' . $suffix . '.css', array(), '1.0.1');
Explanation:
This is a version number bump only and does not represent a security fix to the code itself. The change from '1.0.0' to '1.0.1' may be intended to bust browser caches after security updates elsewhere, but this particular line contains no vulnerability being fixed.
```