CWE-862
Weakness 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.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
19865 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-8GM3-2259-XX5M
Vulnerability from github – Published: 2026-10-09 12:31 – Updated: 2026-10-09 12:31Missing Authorization vulnerability in TMS Amelia ameliabooking allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Amelia: from n/a through 2.4.10.
{
"affected": [],
"aliases": [
"CVE-2026-96461"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-09T10:16:45Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in TMS Amelia ameliabooking allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Amelia: from n/a through 2.4.10.",
"id": "GHSA-8gm3-2259-xx5m",
"modified": "2026-10-09T12:31:43Z",
"published": "2026-10-09T12:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96461"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/ameliabooking/vulnerability/wordpress-amelia-plugin-2-4-10-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-8GMG-9RXM-VW89
Vulnerability from github – Published: 2025-02-22 18:31 – Updated: 2026-04-01 18:33Missing Authorization vulnerability in enituretechnology Distance Based Shipping Calculator allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Distance Based Shipping Calculator: from n/a through 2.0.22.
{
"affected": [],
"aliases": [
"CVE-2025-26764"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-22T16:15:31Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in enituretechnology Distance Based Shipping Calculator allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Distance Based Shipping Calculator: from n/a through 2.0.22.",
"id": "GHSA-8gmg-9rxm-vw89",
"modified": "2026-04-01T18:33:43Z",
"published": "2025-02-22T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26764"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/distance-based-shipping-calculator/vulnerability/wordpress-distance-based-shipping-calculator-plugin-2-0-22-settings-change-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:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-8GMQ-J984-VP4R
Vulnerability from github – Published: 2026-08-28 18:32 – Updated: 2026-08-28 18:32Summary
9router exposes an OpenAI/Anthropic-compatible LLM proxy. Remote access to this proxy is intended to be protected by an API-key check in the Next.js middleware.
However, 9router also defines a rewrite that maps /codex/* to the backend LLM endpoint /api/v1/responses. The middleware authorization decision is made on the incoming request path before the rewrite is applied. Because /codex is not included in the middleware's protected LLM API prefix list, requests to /codex/* bypass the API-key gate and are later rewritten to the same backend used by /api/v1/responses.
As a result, an unauthenticated remote attacker can access the LLM proxy through /codex/* and cause the server to make upstream provider calls using the operator-stored LLM provider credentials.
Details
| Component | File | Note |
|---|---|---|
| Middleware authorization gate | src/dashboardGuard.js |
Protects /v1, /v1beta, /api/v1, and /api/v1beta, but not /codex |
| Rewrite configuration | next.config.mjs |
Rewrites /codex/:path* to /api/v1/responses |
| LLM backend route | src/app/api/v1/responses/route.js |
Dispatches rewritten requests to the LLM handler |
| Chat handler | src/sse/handlers/chat.js |
Uses operator-stored provider credentials for upstream calls |
Tested version:
| Version / Commit | Runtime | Status |
|---|---|---|
v0.4.80, commit 23da7b1fe3bb8edd2bdbdb63fbbb15a476b02c56 |
Next.js 16.2.9 |
Affected |
Root Cause
The middleware classifies requests by the original incoming pathname. The protected public LLM API prefixes are:
PUBLIC_PREFIXES = ["/v1", "/v1beta", "/api/v1", "/api/v1beta"];
Because /codex is not included in this list, a request such as /codex/x does not enter the LLM API authorization branch and falls through to:
return NextResponse.next();
The rewrite configuration then maps the allowed request to the protected backend route:
{
source: "/codex/:path*",
destination: "/api/v1/responses"
}
The backend route reaches the same handler used by the canonical LLM endpoint:
return await handleChat(request);
The handler then processes the request and performs the upstream LLM provider call. In the tested configuration, the handler does not repeat the same middleware API-key gate for remote callers, so the rewritten request is served after bypassing the intended authorization check.
PoC
The following requests use the same target server and the same remote-style Host header. The only meaningful difference is the request path.
Case 01 — Protected canonical endpoint rejects unauthenticated access
POST /api/v1/responses HTTP/1.1
Host: evil.attacker.com
Content-Type: application/json
Content-Length: 156
{"model":"fakeoai/x","input":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello","messages":[{"role":"user","content":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello"}]}
Observed result:
HTTP/1.1 401 Unauthorized
This confirms that the canonical /api/v1/responses path is protected by the intended API-key gate.
Case 02 — Rewritten /codex/* path bypasses the API-key gate
POST /codex/x HTTP/1.1
Host: evil.attacker.com
Content-Type: application/json
Content-Length: 156
{"model":"fakeoai/x","input":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello","messages":[{"role":"user","content":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello"}]}
Observed result:
HTTP/1.1 200 OK
The request reaches the LLM backend without an API key.
A controlled upstream provider endpoint recorded the outbound request from 9router:
POST /responses
Authorization: Bearer NINEROUTER_OPERATOR_STORED_KEY_MARKER
request-body marker present: true
operator key marker in Authorization: true
This confirms that the unauthenticated /codex/* request causes 9router to make an upstream provider call using the operator-stored credentials.
Case 03 — Unrelated unknown path does not reach the backend
POST /notcodex/x HTTP/1.1
Host: evil.attacker.com
Content-Type: application/json
Content-Length: 156
{"model":"fakeoai/x","input":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello","messages":[{"role":"user","content":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello"}]}
Observed result:
HTTP/1.1 404 Not Found
No upstream provider call is made. This isolates the issue to the /codex/* rewrite.
Case 04 — Canonical endpoint succeeds only with a valid API key
POST /api/v1/responses HTTP/1.1
Host: evil.attacker.com
Authorization: Bearer sk-REDACTED
Content-Type: application/json
Content-Length: 156
{"model":"fakeoai/x","input":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello","messages":[{"role":"user","content":"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello"}]}
Observed result:
HTTP/1.1 200 OK
This confirms that the canonical endpoint is functional and that the 401 response in Case 01 is an authorization failure, not a backend error.
Attack Scenario
- A remote attacker identifies a publicly reachable 9router instance.
- The attacker sends LLM proxy requests to
/codex/*instead of/api/v1/responses. - The middleware evaluates the original
/codex/*path and does not apply the LLM API-key gate. - The rewrite maps the request to
/api/v1/responses. - The backend processes the request and performs an upstream provider call.
- The upstream call uses the operator-stored provider credentials.
Impact
A successful attacker can use the operator's configured LLM provider account without authentication.
Likely consequences include:
- Unauthorized use of the 9router LLM proxy.
- Consumption of the operator's provider credits or quota.
- Unexpected billing impact.
- Abuse of configured OpenAI/Anthropic-compatible providers.
- Exposure of model/provider behavior through proxy responses.
- Bypass of the intended API-key access control for remote LLM proxy access.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "9router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55638"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T18:32:01Z",
"nvd_published_at": "2026-07-10T17:16:59Z",
"severity": "HIGH"
},
"details": "## Summary\n\n9router exposes an OpenAI/Anthropic-compatible LLM proxy. Remote access to this proxy is intended to be protected by an API-key check in the Next.js middleware.\n\nHowever, 9router also defines a rewrite that maps `/codex/*` to the backend LLM endpoint `/api/v1/responses`. The middleware authorization decision is made on the incoming request path before the rewrite is applied. Because `/codex` is not included in the middleware\u0027s protected LLM API prefix list, requests to `/codex/*` bypass the API-key gate and are later rewritten to the same backend used by `/api/v1/responses`.\n\nAs a result, an unauthenticated remote attacker can access the LLM proxy through `/codex/*` and cause the server to make upstream provider calls using the operator-stored LLM provider credentials.\n\n## Details\n\n| Component | File | Note |\n| ----------------------------- | ----------------------------------- | ------------------------------------------------------------------------- |\n| Middleware authorization gate | `src/dashboardGuard.js` | Protects `/v1`, `/v1beta`, `/api/v1`, and `/api/v1beta`, but not `/codex` |\n| Rewrite configuration | `next.config.mjs` | Rewrites `/codex/:path*` to `/api/v1/responses` |\n| LLM backend route | `src/app/api/v1/responses/route.js` | Dispatches rewritten requests to the LLM handler |\n| Chat handler | `src/sse/handlers/chat.js` | Uses operator-stored provider credentials for upstream calls |\n\nTested version:\n\n| Version / Commit | Runtime | Status |\n| ------------------------------------------------------------ | ---------------- | -------- |\n| `v0.4.80`, commit `23da7b1fe3bb8edd2bdbdb63fbbb15a476b02c56` | Next.js `16.2.9` | Affected |\n\n### Root Cause\n\nThe middleware classifies requests by the original incoming pathname. The protected public LLM API prefixes are:\n\n```js\nPUBLIC_PREFIXES = [\"/v1\", \"/v1beta\", \"/api/v1\", \"/api/v1beta\"];\n```\n\nBecause `/codex` is not included in this list, a request such as `/codex/x` does not enter the LLM API authorization branch and falls through to:\n\n```js\nreturn NextResponse.next();\n```\n\nThe rewrite configuration then maps the allowed request to the protected backend route:\n\n```js\n{\n source: \"/codex/:path*\",\n destination: \"/api/v1/responses\"\n}\n```\n\nThe backend route reaches the same handler used by the canonical LLM endpoint:\n\n```js\nreturn await handleChat(request);\n```\n\nThe handler then processes the request and performs the upstream LLM provider call. In the tested configuration, the handler does not repeat the same middleware API-key gate for remote callers, so the rewritten request is served after bypassing the intended authorization check.\n\n## PoC\n\nThe following requests use the same target server and the same remote-style `Host` header. The only meaningful difference is the request path.\n\n### Case 01 \u2014 Protected canonical endpoint rejects unauthenticated access\n\n```http\nPOST /api/v1/responses HTTP/1.1\nHost: evil.attacker.com\nContent-Type: application/json\nContent-Length: 156\n\n{\"model\":\"fakeoai/x\",\"input\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\",\"messages\":[{\"role\":\"user\",\"content\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\"}]}\n```\n\nObserved result:\n\n```http\nHTTP/1.1 401 Unauthorized\n```\n\nThis confirms that the canonical `/api/v1/responses` path is protected by the intended API-key gate.\n\n### Case 02 \u2014 Rewritten `/codex/*` path bypasses the API-key gate\n\n```http\nPOST /codex/x HTTP/1.1\nHost: evil.attacker.com\nContent-Type: application/json\nContent-Length: 156\n\n{\"model\":\"fakeoai/x\",\"input\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\",\"messages\":[{\"role\":\"user\",\"content\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\"}]}\n```\n\nObserved result:\n\n```http\nHTTP/1.1 200 OK\n```\n\nThe request reaches the LLM backend without an API key.\n\nA controlled upstream provider endpoint recorded the outbound request from 9router:\n\n```text\nPOST /responses\nAuthorization: Bearer NINEROUTER_OPERATOR_STORED_KEY_MARKER\nrequest-body marker present: true\noperator key marker in Authorization: true\n```\n\nThis confirms that the unauthenticated `/codex/*` request causes 9router to make an upstream provider call using the operator-stored credentials.\n\n### Case 03 \u2014 Unrelated unknown path does not reach the backend\n\n```http\nPOST /notcodex/x HTTP/1.1\nHost: evil.attacker.com\nContent-Type: application/json\nContent-Length: 156\n\n{\"model\":\"fakeoai/x\",\"input\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\",\"messages\":[{\"role\":\"user\",\"content\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\"}]}\n```\n\nObserved result:\n\n```http\nHTTP/1.1 404 Not Found\n```\n\nNo upstream provider call is made. This isolates the issue to the `/codex/*` rewrite.\n\n### Case 04 \u2014 Canonical endpoint succeeds only with a valid API key\n\n```http\nPOST /api/v1/responses HTTP/1.1\nHost: evil.attacker.com\nAuthorization: Bearer sk-REDACTED\nContent-Type: application/json\nContent-Length: 156\n\n{\"model\":\"fakeoai/x\",\"input\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\",\"messages\":[{\"role\":\"user\",\"content\":\"NINEROUTER_CODEX_AUTH_BYPASS_MARKER hello\"}]}\n```\n\nObserved result:\n\n```http\nHTTP/1.1 200 OK\n```\n\nThis confirms that the canonical endpoint is functional and that the `401` response in Case 01 is an authorization failure, not a backend error.\n\n## Attack Scenario\n\n1. A remote attacker identifies a publicly reachable 9router instance.\n2. The attacker sends LLM proxy requests to `/codex/*` instead of `/api/v1/responses`.\n3. The middleware evaluates the original `/codex/*` path and does not apply the LLM API-key gate.\n4. The rewrite maps the request to `/api/v1/responses`.\n5. The backend processes the request and performs an upstream provider call.\n6. The upstream call uses the operator-stored provider credentials.\n\n## Impact\n\nA successful attacker can use the operator\u0027s configured LLM provider account without authentication.\n\nLikely consequences include:\n\n* Unauthorized use of the 9router LLM proxy.\n* Consumption of the operator\u0027s provider credits or quota.\n* Unexpected billing impact.\n* Abuse of configured OpenAI/Anthropic-compatible providers.\n* Exposure of model/provider behavior through proxy responses.\n* Bypass of the intended API-key access control for remote LLM proxy access.",
"id": "GHSA-8gmq-j984-vp4r",
"modified": "2026-08-28T18:32:01Z",
"published": "2026-08-28T18:32:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/decolua/9router/security/advisories/GHSA-8gmq-j984-vp4r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55638"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/commit/b282f0554972ea35281520738759d76abcd0b0b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/decolua/9router"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/releases/tag/v0.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "9router: Unauthenticated LLM proxy access via /codex rewrite authorization bypass"
}
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.