CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
15462 vulnerabilities reference this CWE, most recent first.
GHSA-8GC6-9VPR-VW7H
Vulnerability from github – Published: 2025-06-20 15:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in aThemeArt Translations eDS Responsive Menu allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects eDS Responsive Menu: from n/a through 1.2.
{
"affected": [],
"aliases": [
"CVE-2025-49971"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-20T15:15:22Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in aThemeArt Translations eDS Responsive Menu allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects eDS Responsive Menu: from n/a through 1.2.",
"id": "GHSA-8gc6-9vpr-vw7h",
"modified": "2026-04-01T18:35:30Z",
"published": "2025-06-20T15:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49971"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/eds-responsive-menu/vulnerability/wordpress-eds-responsive-menu-plugin-1-2-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:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8GC8-CG2Q-4Q27
Vulnerability from github – Published: 2025-12-21 03:31 – Updated: 2025-12-21 03:31The Frontend Post Submission Manager Lite plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.2.5. This is due to missing authorization checks on the post update functionality in the fpsml_form_process AJAX action. This makes it possible for unauthenticated attackers to modify arbitrary posts by providing a post_id parameter via the guest posting form, allowing them to change post titles, content, excerpts, and remove post authors.
{
"affected": [],
"aliases": [
"CVE-2025-14080"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-21T03:15:52Z",
"severity": "MODERATE"
},
"details": "The Frontend Post Submission Manager Lite plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.2.5. This is due to missing authorization checks on the post update functionality in the fpsml_form_process AJAX action. This makes it possible for unauthenticated attackers to modify arbitrary posts by providing a post_id parameter via the guest posting form, allowing them to change post titles, content, excerpts, and remove post authors.",
"id": "GHSA-8gc8-cg2q-4q27",
"modified": "2025-12-21T03:31:11Z",
"published": "2025-12-21T03:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14080"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/frontend-post-submission-manager-lite/tags/1.2.5/includes/cores/ajax-process-form.php#L104"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/frontend-post-submission-manager-lite/trunk/includes/cores/ajax-process-form.php#L104"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3419835%40frontend-post-submission-manager-lite\u0026new=3419835%40frontend-post-submission-manager-lite\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3e9b6514-e727-42fe-8893-a317b71b2760?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-8GCG-VWMW-RXJ4
Vulnerability from github – Published: 2023-01-10 22:27 – Updated: 2023-01-23 18:52Using the notifications feature, one can read restricted/private content and bypass access checks that would be in place for such content.
The notification-sending component does not check that the subject of the notification can be seen by the receiver, and proceeds to send notifications through their different channels. The alerts do not leak data despite this as they are listed based on a visibility check, however, emails are still sent out.
This means that, for extensions which restrict access to posts, any actor can bypass the restriction by subscribing to the discussion if the Subscriptions extension is enabled.
Impact
The attack allows the leaking of some posts in the forum database, including posts awaiting approval, posts in tags the user has no access to if they could subscribe to a discussion before it becomes private, and posts restricted by third-party extensions.
Other leaks could also happen for different notification subjects if some features allowed to receive specific types of notifications for restricted content.
All Flarum versions prior to v1.6.3 are affected.
Patches
The vulnerability has been fixed and published as flarum/core v1.6.3. All communities running Flarum should upgrade as soon as possible to v1.6.3 using:
composer update --prefer-dist --no-dev -a -W
You can then confirm you run the latest version using:
composer show flarum/core
Workarounds
Disable the Flarum Subscriptions extension or disable email notifications altogether.
There is no other supported workaround for this issue for Flarum versions below 1.6.3.
For more information
For any questions or comments on this vulnerability please visit https://discuss.flarum.org/
For support questions create a discussion at https://discuss.flarum.org/t/support.
A reminder that if you ever become aware of a security issue in Flarum, please report it to us privately by emailing security@flarum.org, and we will address it promptly.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "flarum/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-22488"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-10T22:27:13Z",
"nvd_published_at": "2023-01-12T20:15:00Z",
"severity": "MODERATE"
},
"details": "Using the notifications feature, one can read restricted/private content and bypass access checks that would be in place for such content.\n\nThe notification-sending component does not check that the subject of the notification can be seen by the receiver, and proceeds to send notifications through their different channels. The alerts do not leak data despite this as they are listed based on a visibility check, however, emails are still sent out.\n\nThis means that, for extensions which restrict access to posts, any actor can bypass the restriction by subscribing to the discussion if the [*Subscriptions*](https://extiverse.com/extension/flarum/subscriptions) extension is enabled.\n\n### Impact\nThe attack allows the leaking of some posts in the forum database, including posts awaiting approval, posts in tags the user has no access to if they could subscribe to a discussion before it becomes private, and posts restricted by third-party extensions.\n\nOther leaks could also happen for different notification subjects if some features allowed to receive specific types of notifications for restricted content.\n\nAll Flarum versions prior to v1.6.3 are affected.\n\n### Patches\nThe vulnerability has been fixed and published as flarum/core v1.6.3. All communities running Flarum should upgrade as soon as possible to v1.6.3 using:\n\n```\ncomposer update --prefer-dist --no-dev -a -W\n```\nYou can then confirm you run the latest version using:\n\n```\ncomposer show flarum/core\n```\n\n### Workarounds\nDisable the Flarum Subscriptions extension or disable email notifications altogether.\n\n**There is no other supported workaround for this issue for Flarum versions below 1.6.3.**\n\n### For more information\nFor any questions or comments on this vulnerability please visit https://discuss.flarum.org/\n\nFor support questions create a discussion at https://discuss.flarum.org/t/support.\n\nA reminder that if you ever become aware of a security issue in Flarum, please report it to us privately by emailing [security@flarum.org](mailto:security@flarum.org), and we will address it promptly.\n",
"id": "GHSA-8gcg-vwmw-rxj4",
"modified": "2023-01-23T18:52:11Z",
"published": "2023-01-10T22:27:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/flarum/framework/security/advisories/GHSA-8gcg-vwmw-rxj4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22488"
},
{
"type": "WEB",
"url": "https://github.com/flarum/framework/commit/d0a2b95dca57d3dae9a0d77b610b1cb1d0b1766a"
},
{
"type": "PACKAGE",
"url": "https://github.com/flarum/framework"
},
{
"type": "WEB",
"url": "https://github.com/flarum/framework/releases/tag/v1.6.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Flarum notifications can leak restricted content"
}
GHSA-8GH7-8V8F-6F45
Vulnerability from github – Published: 2026-02-14 09:31 – Updated: 2026-02-14 09:31The CallbackKiller service widget plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the cbk_save() function in all versions up to, and including, 1.2. This makes it possible for unauthenticated attackers to modify the plugin's site ID settings via the 'cbk_save_v1' AJAX action.
{
"affected": [],
"aliases": [
"CVE-2026-1944"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T07:16:12Z",
"severity": "MODERATE"
},
"details": "The CallbackKiller service widget plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the cbk_save() function in all versions up to, and including, 1.2. This makes it possible for unauthenticated attackers to modify the plugin\u0027s site ID settings via the \u0027cbk_save_v1\u0027 AJAX action.",
"id": "GHSA-8gh7-8v8f-6f45",
"modified": "2026-02-14T09:31:33Z",
"published": "2026-02-14T09:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1944"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/callbackkiller-service-widget/tags/1.2/callbackkiller-widget.php#L133"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/callbackkiller-service-widget/tags/1.2/callbackkiller-widget.php#L34"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/callbackkiller-service-widget/trunk/callbackkiller-widget.php#L133"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/callbackkiller-service-widget/trunk/callbackkiller-widget.php#L34"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/98a7572d-9642-4150-8112-c0fa2b25ae05?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-8GHR-W65F-J3QR
Vulnerability from github – Published: 2026-06-08 23:07 – Updated: 2026-06-08 23:07Summary
An authorization issue in the Scheduler API allowed authenticated non-admin users to create or modify scheduled actions that should be restricted to administrators.
Details
The Scheduler API did not correctly enforce administrator permissions when processing scheduler modifications.
As a result, authenticated users with non-administrative roles could create or modify scheduled actions that execute privileged operations, including device value changes and server-side script execution.
The issue was fixed in version 1.3.2 by enforcing the appropriate permission checks for scheduler modifications.
Impact
An operator-level user in FUXA reaches the PLC-write and server-side-script-execution surface that the platform otherwise restricts to administrators. In a SCADA deployment those two privileges cover setpoint control and the automation scripting engine. Alice schedules a job that rewrites a pump's enable tag, opens a safety interlock, or runs a project script that walks the device tree. The scheduled-action model extends the attack: Alice does not need to keep a session open for the action to fire, and a repeating schedule re-applies her changes every cycle even if an admin reverts them manually.
CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L (Medium, 6.3). CWE-862.
Recommended Fix
Add authJwt.haveAdminPermission(permission) to both POST /api/scheduler and DELETE /api/scheduler, matching every other write endpoint that reaches runtime.devices.setTagValue or runtime.scriptsMgr.runScript.
schedulerApp.post("/api/scheduler", secureFnc, function(req, res) {
if (res.statusCode === 403) {
runtime.logger.error("api post scheduler: Tocken Expired");
return;
}
const permission = checkGroupsFnc(req);
const isGuest = authJwt.isGuestUser(req.userId, req.userGroups);
if (runtime.settings?.secureEnabled && (isGuest || !authJwt.haveAdminPermission(permission))) {
res.status(401).json({error:"unauthorized_error", message: "Unauthorized!"});
runtime.logger.error("api post scheduler: admin permission required");
return;
}
// ... rest unchanged ...
});
Apply the same change to the delete handler at server/api/scheduler/index.js:102-112. As defense in depth, the scheduler service should also validate each deviceActions entry against the creator's stored groups before execution (e.g., reject onRunScript on any scheduler whose author is not an admin at execution time).
A fix is available at https://github.com/frangoteam/FUXA/releases/tag/v1.3.2.
Found by aisafe.io
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fuxa-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.1.14-1243"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47721"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:07:02Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nAn authorization issue in the Scheduler API allowed authenticated non-admin users to create or modify scheduled actions that should be restricted to administrators.\n\n## Details\n\nThe Scheduler API did not correctly enforce administrator permissions when processing scheduler modifications.\n\nAs a result, authenticated users with non-administrative roles could create or modify scheduled actions that execute privileged operations, including device value changes and server-side script execution.\n\nThe issue was fixed in version 1.3.2 by enforcing the appropriate permission checks for scheduler modifications.\n\n\n## Impact\n\nAn operator-level user in FUXA reaches the PLC-write and server-side-script-execution surface that the platform otherwise restricts to administrators. In a SCADA deployment those two privileges cover setpoint control and the automation scripting engine. Alice schedules a job that rewrites a pump\u0027s enable tag, opens a safety interlock, or runs a project script that walks the device tree. The scheduled-action model extends the attack: Alice does not need to keep a session open for the action to fire, and a repeating schedule re-applies her changes every cycle even if an admin reverts them manually.\n\n**CVSS 3.1**: `AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L` (Medium, 6.3). CWE-862.\n\n## Recommended Fix\n\nAdd `authJwt.haveAdminPermission(permission)` to both `POST /api/scheduler` and `DELETE /api/scheduler`, matching every other write endpoint that reaches `runtime.devices.setTagValue` or `runtime.scriptsMgr.runScript`.\n\n```javascript\nschedulerApp.post(\"/api/scheduler\", secureFnc, function(req, res) {\n if (res.statusCode === 403) {\n runtime.logger.error(\"api post scheduler: Tocken Expired\");\n return;\n }\n const permission = checkGroupsFnc(req);\n const isGuest = authJwt.isGuestUser(req.userId, req.userGroups);\n if (runtime.settings?.secureEnabled \u0026\u0026 (isGuest || !authJwt.haveAdminPermission(permission))) {\n res.status(401).json({error:\"unauthorized_error\", message: \"Unauthorized!\"});\n runtime.logger.error(\"api post scheduler: admin permission required\");\n return;\n }\n // ... rest unchanged ...\n});\n```\n\nApply the same change to the delete handler at `server/api/scheduler/index.js:102-112`. As defense in depth, the scheduler service should also validate each `deviceActions` entry against the creator\u0027s stored groups before execution (e.g., reject `onRunScript` on any scheduler whose author is not an admin at execution time).\n\n---\nA fix is available at https://github.com/frangoteam/FUXA/releases/tag/v1.3.2.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-8ghr-w65f-j3qr",
"modified": "2026-06-08T23:07:02Z",
"published": "2026-06-08T23:07:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/frangoteam/FUXA/security/advisories/GHSA-8ghr-w65f-j3qr"
},
{
"type": "PACKAGE",
"url": "https://github.com/frangoteam/FUXA"
},
{
"type": "WEB",
"url": "https://github.com/frangoteam/FUXA/releases/tag/v1.3.2"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "FUXA\u0027s scheduler API missing admin check enables operator-to-admin escalation via scheduled device actions"
}
GHSA-8GJ2-2CVC-6XX7
Vulnerability from github – Published: 2026-08-04 19:19 – Updated: 2026-08-04 19:19Summary
The /api/v1/text-to-speech/generate endpoint is whitelisted (requires no authentication) and accepts any chatflowId without checking whether the referenced chatflow is public. An unauthenticated attacker who knows a valid chatflow UUID can abuse that chatflow's TTS credential (OpenAI or ElevenLabs API key) to generate unlimited text-to-speech audio, incurring costs on the chatflow owner's account.
Details
The TTS generateTextToSpeech controller at packages/server/src/controllers/text-to-speech/index.ts:10-171 is whitelisted at packages/server/src/utils/constants.ts:41:
'/api/v1/text-to-speech/generate',
When a chatflowId is provided and the user is not authenticated (no req.user), the controller falls back to fetching the chatflow without workspace scoping:
// packages/server/src/controllers/text-to-speech/index.ts:36-42
if (workspaceId) {
chatflow = await chatflowsService.getChatflowById(chatflowId, workspaceId)
} else {
// Fallback: get workspaceId from chatflow when req.user.activeWorkspaceId is not set
chatflow = await chatflowsService.getChatflowById(chatflowId) // NO isPublic check
workspaceId = chatflow.workspaceId
}
The getChatflowById function at packages/server/src/services/chatflows/index.ts:247-272 fetches any chatflow by ID when workspaceId is not provided:
const dbResponse = await appServer.AppDataSource.getRepository(ChatFlow).findOne({
where: {
id: chatflowId,
...(workspaceId ? { workspaceId } : {}) // No workspace filter when workspaceId is undefined
}
})
The controller then extracts the TTS provider configuration from the chatflow:
// packages/server/src/controllers/text-to-speech/index.ts:51-66
const ttsConfig = JSON.parse(chatflow.textToSpeech)
const activeProviderKey = Object.keys(ttsConfig).find(key => ttsConfig[key].status === true)
const providerConfig = ttsConfig[activeProviderKey]
provider = activeProviderKey
credentialId = providerConfig.credentialId // Extracted from private chatflow
This credentialId is then used to decrypt and use the stored credential (OpenAI or ElevenLabs API key) to make TTS API calls at packages/components/src/textToSpeech.ts:33-34:
const credentialId = textToSpeechConfig.credentialId as string
const credentialData = await getCredentialData(credentialId ?? '', options)
PoC
# Step 1: Know a chatflow UUID that has TTS enabled (any chatflow, public or private)
CHATFLOW_ID="<any-chatflow-uuid-with-tts-enabled>"
# Step 2: Abuse the TTS credential to generate audio without authentication
curl -X POST "http://localhost:3000/api/v1/text-to-speech/generate" \
-H "Content-Type: application/json" \
-d '{
"chatflowId": "'${CHATFLOW_ID}'",
"chatId": "attacker-chat-1",
"chatMessageId": "msg-1",
"text": "This is a test of unauthorized TTS generation using someone elses API key"
}'
# Expected: Returns SSE stream with TTS audio data using the chatflow owner's OpenAI/ElevenLabs credentials
# event: tts_start
# data: {"event":"tts_start","data":{"chatMessageId":"msg-1","format":"mp3"}}
# event: tts_data
# data: {"event":"tts_data","data":{"chatMessageId":"msg-1","audioChunk":"<base64-audio>"}}
# Step 3: Repeat with large text to incur costs
curl -X POST "http://localhost:3000/api/v1/text-to-speech/generate" \
-H "Content-Type: application/json" \
-d '{
"chatflowId": "'${CHATFLOW_ID}'",
"chatId": "attacker-chat-2",
"chatMessageId": "msg-2",
"text": "'$(python3 -c "print('A' * 4096)")'"
}'
Impact
- Financial Impact: An attacker can generate unlimited TTS audio using the chatflow owner's OpenAI or ElevenLabs API credentials, incurring potentially significant costs. OpenAI TTS costs ~$15/1M characters; an attacker could generate large volumes of audio.
- Credential Abuse: The attacker effectively gains indirect access to the stored API credentials without needing to authenticate or have any permissions. The credentials are not directly exposed but are used on behalf of the attacker.
- Denial of Service: By exhausting the API quota/budget of the credential, the attacker can deny service to legitimate users of the chatflow.
- Affects Private Chatflows: This vulnerability affects all chatflows with TTS configured, including those explicitly marked as private (
isPublic: false).
Recommended Fix
- Check
isPublicbefore allowing unauthenticated TTS generation:
// packages/server/src/controllers/text-to-speech/index.ts
if (chatflowId) {
let chatflow;
let workspaceId = req.user?.activeWorkspaceId;
if (workspaceId) {
chatflow = await chatflowsService.getChatflowById(chatflowId, workspaceId)
} else {
chatflow = await chatflowsService.getChatflowById(chatflowId)
// Verify the chatflow is public before using its credentials
if (!chatflow.isPublic) {
throw new InternalFlowiseError(
StatusCodes.UNAUTHORIZED,
'TTS generation requires authentication for non-public chatflows'
)
}
workspaceId = chatflow.workspaceId
}
// ... rest of the function
}
- Consider applying rate limiting to the TTS endpoint to prevent abuse even for public chatflows.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.3"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T19:19:44Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `/api/v1/text-to-speech/generate` endpoint is whitelisted (requires no authentication) and accepts any `chatflowId` without checking whether the referenced chatflow is public. An unauthenticated attacker who knows a valid chatflow UUID can abuse that chatflow\u0027s TTS credential (OpenAI or ElevenLabs API key) to generate unlimited text-to-speech audio, incurring costs on the chatflow owner\u0027s account.\n\n## Details\n\nThe TTS `generateTextToSpeech` controller at `packages/server/src/controllers/text-to-speech/index.ts:10-171` is whitelisted at `packages/server/src/utils/constants.ts:41`:\n\n```typescript\n\u0027/api/v1/text-to-speech/generate\u0027,\n```\n\nWhen a `chatflowId` is provided and the user is not authenticated (no `req.user`), the controller falls back to fetching the chatflow without workspace scoping:\n\n```typescript\n// packages/server/src/controllers/text-to-speech/index.ts:36-42\nif (workspaceId) {\n chatflow = await chatflowsService.getChatflowById(chatflowId, workspaceId)\n} else {\n // Fallback: get workspaceId from chatflow when req.user.activeWorkspaceId is not set\n chatflow = await chatflowsService.getChatflowById(chatflowId) // NO isPublic check\n workspaceId = chatflow.workspaceId\n}\n```\n\nThe `getChatflowById` function at `packages/server/src/services/chatflows/index.ts:247-272` fetches any chatflow by ID when `workspaceId` is not provided:\n\n```typescript\nconst dbResponse = await appServer.AppDataSource.getRepository(ChatFlow).findOne({\n where: {\n id: chatflowId,\n ...(workspaceId ? { workspaceId } : {}) // No workspace filter when workspaceId is undefined\n }\n})\n```\n\nThe controller then extracts the TTS provider configuration from the chatflow:\n\n```typescript\n// packages/server/src/controllers/text-to-speech/index.ts:51-66\nconst ttsConfig = JSON.parse(chatflow.textToSpeech)\nconst activeProviderKey = Object.keys(ttsConfig).find(key =\u003e ttsConfig[key].status === true)\nconst providerConfig = ttsConfig[activeProviderKey]\nprovider = activeProviderKey\ncredentialId = providerConfig.credentialId // Extracted from private chatflow\n```\n\nThis `credentialId` is then used to decrypt and use the stored credential (OpenAI or ElevenLabs API key) to make TTS API calls at `packages/components/src/textToSpeech.ts:33-34`:\n\n```typescript\nconst credentialId = textToSpeechConfig.credentialId as string\nconst credentialData = await getCredentialData(credentialId ?? \u0027\u0027, options)\n```\n\n## PoC\n\n```bash\n# Step 1: Know a chatflow UUID that has TTS enabled (any chatflow, public or private)\nCHATFLOW_ID=\"\u003cany-chatflow-uuid-with-tts-enabled\u003e\"\n\n# Step 2: Abuse the TTS credential to generate audio without authentication\ncurl -X POST \"http://localhost:3000/api/v1/text-to-speech/generate\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"chatflowId\": \"\u0027${CHATFLOW_ID}\u0027\",\n \"chatId\": \"attacker-chat-1\",\n \"chatMessageId\": \"msg-1\",\n \"text\": \"This is a test of unauthorized TTS generation using someone elses API key\"\n }\u0027\n\n# Expected: Returns SSE stream with TTS audio data using the chatflow owner\u0027s OpenAI/ElevenLabs credentials\n# event: tts_start\n# data: {\"event\":\"tts_start\",\"data\":{\"chatMessageId\":\"msg-1\",\"format\":\"mp3\"}}\n# event: tts_data\n# data: {\"event\":\"tts_data\",\"data\":{\"chatMessageId\":\"msg-1\",\"audioChunk\":\"\u003cbase64-audio\u003e\"}}\n\n# Step 3: Repeat with large text to incur costs\ncurl -X POST \"http://localhost:3000/api/v1/text-to-speech/generate\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"chatflowId\": \"\u0027${CHATFLOW_ID}\u0027\",\n \"chatId\": \"attacker-chat-2\",\n \"chatMessageId\": \"msg-2\",\n \"text\": \"\u0027$(python3 -c \"print(\u0027A\u0027 * 4096)\")\u0027\"\n }\u0027\n```\n\n## Impact\n\n- **Financial Impact**: An attacker can generate unlimited TTS audio using the chatflow owner\u0027s OpenAI or ElevenLabs API credentials, incurring potentially significant costs. OpenAI TTS costs ~$15/1M characters; an attacker could generate large volumes of audio.\n- **Credential Abuse**: The attacker effectively gains indirect access to the stored API credentials without needing to authenticate or have any permissions. The credentials are not directly exposed but are used on behalf of the attacker.\n- **Denial of Service**: By exhausting the API quota/budget of the credential, the attacker can deny service to legitimate users of the chatflow.\n- **Affects Private Chatflows**: This vulnerability affects all chatflows with TTS configured, including those explicitly marked as private (`isPublic: false`).\n\n## Recommended Fix\n\n1. Check `isPublic` before allowing unauthenticated TTS generation:\n\n```typescript\n// packages/server/src/controllers/text-to-speech/index.ts\nif (chatflowId) {\n let chatflow;\n let workspaceId = req.user?.activeWorkspaceId;\n \n if (workspaceId) {\n chatflow = await chatflowsService.getChatflowById(chatflowId, workspaceId)\n } else {\n chatflow = await chatflowsService.getChatflowById(chatflowId)\n // Verify the chatflow is public before using its credentials\n if (!chatflow.isPublic) {\n throw new InternalFlowiseError(\n StatusCodes.UNAUTHORIZED,\n \u0027TTS generation requires authentication for non-public chatflows\u0027\n )\n }\n workspaceId = chatflow.workspaceId\n }\n // ... rest of the function\n}\n```\n\n2. Consider applying rate limiting to the TTS endpoint to prevent abuse even for public chatflows.",
"id": "GHSA-8gj2-2cvc-6xx7",
"modified": "2026-08-04T19:19:44Z",
"published": "2026-08-04T19:19:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-8gj2-2cvc-6xx7"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/pull/6650"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/commit/dbec8f9fd3c42faab49416fe81ff1774a5344cba"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Flowise: Unauthenticated Credential Abuse via Text-to-Speech Endpoint Allows Unauthorized Use of Private Chatflow TTS Credentials"
}
GHSA-8GJ3-QCVJ-2568
Vulnerability from github – Published: 2026-06-26 15:32 – Updated: 2026-06-26 15:32Unauthenticated Broken Access Control in Five Star Restaurant Menu <= 2.5.2 versions.
{
"affected": [],
"aliases": [
"CVE-2026-54835"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-26T15:16:41Z",
"severity": "HIGH"
},
"details": "Unauthenticated Broken Access Control in Five Star Restaurant Menu \u003c= 2.5.2 versions.",
"id": "GHSA-8gj3-qcvj-2568",
"modified": "2026-06-26T15:32:15Z",
"published": "2026-06-26T15:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54835"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/food-and-drink-menu/vulnerability/wordpress-five-star-restaurant-menu-plugin-2-5-2-broken-access-control-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:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8GJ5-HV8W-8H4X
Vulnerability from github – Published: 2025-10-22 15:31 – Updated: 2026-01-20 15:31Missing Authorization vulnerability in Made Neat Acknowledgify acknowledgify.This issue affects Acknowledgify: from n/a through <= 1.1.3.
{
"affected": [],
"aliases": [
"CVE-2025-62021"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-22T15:16:03Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Made Neat Acknowledgify acknowledgify.This issue affects Acknowledgify: from n/a through \u003c= 1.1.3.",
"id": "GHSA-8gj5-hv8w-8h4x",
"modified": "2026-01-20T15:31:32Z",
"published": "2025-10-22T15:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62021"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/acknowledgify/vulnerability/wordpress-acknowledgify-plugin-1-1-3-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/acknowledgify/vulnerability/wordpress-acknowledgify-plugin-1-1-3-broken-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/acknowledgify/vulnerability/wordpress-acknowledgify-plugin-1-1-3-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:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8GJG-HFM2-FFQ6
Vulnerability from github – Published: 2023-02-12 06:30 – Updated: 2023-02-21 21:30In wlan driver, there is a possible missing permission check. This could lead to local information disclosure.
{
"affected": [],
"aliases": [
"CVE-2022-47325"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-12T04:15:00Z",
"severity": "MODERATE"
},
"details": "In wlan driver, there is a possible missing permission check. This could lead to local information disclosure.",
"id": "GHSA-8gjg-hfm2-ffq6",
"modified": "2023-02-21T21:30:17Z",
"published": "2023-02-12T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47325"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1621031430231134210"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8GJH-4454-QCRX
Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32Missing Authorization vulnerability in WP Legal Pages WP Cookie Notice for GDPR, CCPA & ePrivacy Consent gdpr-cookie-consent allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Cookie Notice for GDPR, CCPA & ePrivacy Consent: from n/a through <= 4.0.7.
{
"affected": [],
"aliases": [
"CVE-2025-66133"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T09:15:57Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WP Legal Pages WP Cookie Notice for GDPR, CCPA \u0026 ePrivacy Consent gdpr-cookie-consent allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP Cookie Notice for GDPR, CCPA \u0026 ePrivacy Consent: from n/a through \u003c= 4.0.7.",
"id": "GHSA-8gjh-4454-qcrx",
"modified": "2026-01-20T15:32:15Z",
"published": "2025-12-16T09:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66133"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/gdpr-cookie-consent/vulnerability/wordpress-wp-cookie-notice-for-gdpr-ccpa-eprivacy-consent-plugin-4-0-7-broken-access-control-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/gdpr-cookie-consent/vulnerability/wordpress-wp-cookie-notice-for-gdpr-ccpa-eprivacy-consent-plugin-4-0-7-broken-access-control-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"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.