CVE-2024-6322 - Bypassing Access Control in Plugin Data Sources via Misapplied ReqActions in plugin.json

A critical security vulnerability, CVE-2024-6322, was recently discovered in systems that utilize plugin-based data sources. This issue allows users with legitimate access to any data source to bypass specific access controls intended to protect other data sources managed by plugins. The root cause lies in how ReqActions in the plugin.json configuration are checked: instead of enforcing permissions for each data source separately, the check is global. In this post, we'll break down how the exploit works, show code snippets, and cover steps to mitigate this flaw.

What Is CVE-2024-6322?

In platforms supporting plugin-based data sources, the plugin.json file can restrict access to particular operations or APIs through a ReqActions field. Ideally, these actions should be enforced for each data source—meaning that access to DataSourceA doesn't imply access to DataSourceB.

CVE-2024-6322 occurs because, if a user or service account has query access to any plugin data source, they can bypass ReqActions meant to protect other sensitive data sources. The vulnerability arises as the permission check wasn't scoped per data source but was instead handled globally for all plugin data sources.

Who Is Affected?

If your application or system uses plugin data sources protected via the ReqActions field in a plugin.json, and your access control logic isn't scoped per data source, you're potentially at risk. The account must, however, have prior query access to at least one affected data source.

Here’s a simplified look at the vulnerable logic

// Faulty pseudo-code
if userHasAccessToAnyPluginDataSource(user) {
    allow("somePluginAction") // Doesn't care which source the user can see
    // ReqActions check applies globally instead of per datasource
}

So, if a user has access to, say, mainDB, but not secretDB, they should be blocked from accessing actions tied to secretDB. Instead, they’re allowed, since the permissions check is not tied to specific data sources.

Example: plugin.json

{
  "version": "1.2.3",
  "datasources": [
    {
      "name": "mainDB",
      "ReqActions": ["read", "query"]
    },
    {
      "name": "secretDB",
      "ReqActions": ["admin", "query_sensitive"]
    }
  ]
}

Expected Behavior: Only users with query_sensitive permission should query secretDB.

Actual Behavior with CVE-2024-6322: Any user who can query mainDB can also do query_sensitive actions on secretDB.

Exploit Scenario

Let’s consider an attacker, Alice, who legitimately queries mainDB. Alice attempts to perform an action exclusive to secretDB (for example, a sensitive admin query). Due to improper scoping, the system checks if Alice has *any* datasource access and lets her through.

Example Request

curl -H "Authorization: Bearer alice_token" \
     https://example.com/plugins/secretDB/query_sensitive

Result: Alice receives data/actions from secretDB that she shouldn’t be able to access.

Mitigation

To fix this, access checks for each plugin data source should always be scoped to that specific data source in the plugin.json.

Corrected Pseudo-Code

// Secure version: check for each datasource individually
if userHasAccessToDatasource(user, requestedDatasource) &&
   userHasReqAction(user, requestedDatasource, requestedAction) {
    allow(requestedAction)
} else {
    deny(requestedAction)
}

Audit existing plugin.json files: Ensure ReqActions are set per-datasource.

3. Revise API endpoints: Confirm endpoints always check permissions against the correct data source.

References

- Official CVE entry for CVE-2024-6322
- Related security advisory (example link)
- Common pitfall with role-based access—OWASP Access Control Cheat Sheet

Conclusion

CVE-2024-6322 highlights why fine-grained, resource-scoped access checks are essential. If your system grants access to plugin data sources based on a global check, you may be vulnerable. Always make permission decisions at the most granular possible level and review your plugin.json implementations as soon as possible.

Stay secure! For more details on this and other vulnerabilities, follow updates from NIST NVD and your vendor's advisories.


> *This post is exclusive and written in simple American English for maximum clarity.*

Timeline

Published on: 08/20/2024 18:15:09 UTC
Last modified on: 08/21/2024 12:30:33 UTC