Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5659 vulnerabilities reference this CWE, most recent first.

GHSA-7Q64-3RG2-H9PF

Vulnerability from github – Published: 2026-02-27 18:31 – Updated: 2026-03-02 14:34
VLAI
Summary
Duplicate Advisory: Nest has a Fastify URL Encoding Middleware Bypass
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-r4wm-x892-vjmx. This link is maintained to preserve external references.

Original Description

A NestJS application using @nestjs/platform-fastify can allow bypass of authentication/authorization middleware when Fastify path-normalization options are enabled.

This issue affects nest.Js: 11.1.13.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@nestjs/platform-fastify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.1.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T14:34:03Z",
    "nvd_published_at": "2026-02-27T17:16:33Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-r4wm-x892-vjmx. This link is maintained to preserve external references.\n\n## Original Description\n\nA NestJS application using @nestjs/platform-fastify can allow bypass of authentication/authorization middleware when Fastify path-normalization options are enabled.\n\n\n\nThis issue affects nest.Js: 11.1.13.",
  "id": "GHSA-7q64-3rg2-h9pf",
  "modified": "2026-03-02T14:34:03Z",
  "published": "2026-02-27T18:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2293"
    },
    {
      "type": "WEB",
      "url": "https://fluidattacks.com/advisories/neton"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nestjs/nest"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nestjs/nest/releases/tag/v11.1.14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/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"
    }
  ],
  "summary": "Duplicate Advisory: Nest has a Fastify URL Encoding Middleware Bypass",
  "withdrawn": "2026-03-02T14:34:03Z"
}

GHSA-7QGV-8GH6-QMR8

Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37
VLAI
Details

The REST/JSON project 7.x-1.x for Drupal allows user registration bypass, aka SA-CONTRIB-2016-033. NOTE: This project is not covered by Drupal's security advisory policy.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-20005"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-01T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The REST/JSON project 7.x-1.x for Drupal allows user registration bypass, aka SA-CONTRIB-2016-033. NOTE: This project is not covered by Drupal\u0027s security advisory policy.",
  "id": "GHSA-7qgv-8gh6-qmr8",
  "modified": "2022-05-24T17:37:31Z",
  "published": "2022-05-24T17:37:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-20005"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/node/2744889"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7QPW-JHJ9-8G8X

Vulnerability from github – Published: 2024-11-25 18:33 – Updated: 2024-11-25 18:33
VLAI
Details

Incorrect authorization in the add permission component in Devolutions Remote Desktop Manager 2024.2.21 and earlier on Windows allows an authenticated malicious user to bypass the "Add" permission via the import in vault feature.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11672"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-25T15:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in the add permission component in Devolutions Remote Desktop Manager 2024.2.21 and earlier on Windows allows an authenticated malicious user to bypass the \"Add\" permission via the import in vault feature.",
  "id": "GHSA-7qpw-jhj9-8g8x",
  "modified": "2024-11-25T18:33:27Z",
  "published": "2024-11-25T18:33:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11672"
    },
    {
      "type": "WEB",
      "url": "https://devolutions.net/security/advisories/DEVO-2024-0016"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7QR3-855V-3QHW

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-07-13 00:01
VLAI
Details

Microsoft Office Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-34469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-14T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Office Security Feature Bypass Vulnerability",
  "id": "GHSA-7qr3-855v-3qhw",
  "modified": "2022-07-13T00:01:26Z",
  "published": "2022-05-24T19:07:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34469"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-34469"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7QW2-W5RC-37X2

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-07-20 21:28
VLAI
Summary
PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml
Details

Summary

PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools.

For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context.

As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.

The local PoV uses a harmless printf canary and explicitly unsets PRAISONAI_AUTO_APPROVE.

Technical Details

recipe.run() checks the recipe policy unless options["allow_dangerous_tools"] is true. _check_tool_policy() gets the required tool list from recipe_config.get_required_tools(), which is backed by TEMPLATE.yaml requires.tools.

The steps workflow execution path is separate:

  1. _execute_steps_workflow() parses the workflow file with YAMLWorkflowParser.
  2. YAMLWorkflowParser resolves agents.*.tools.
  3. The same parser reads top-level approve: and stores it on workflow.approve_tools.
  4. Workflow.start() calls set_yaml_approved_tools(approve_tools).
  5. The approval registry treats YAML-approved tools as approved.

execute_command is listed as a default dangerous tool with critical risk and is decorated with @require_approval(risk_level="critical"). The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.

Why This Is Not Intended Behavior

YAML approve: is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.

The unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, allow_dangerous_tools=True, but a recipe can avoid that policy by moving the dangerous tool declaration from TEMPLATE.yaml requires.tools into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.

This conflicts with the documented safety model:

  • PraisonAI's approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.
  • The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.
  • Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.
  • Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.

A control recipe that declares requires.tools: [execute_command] is denied with:

Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.

The bypass recipe uses the same tool but omits it from requires.tools; it passes policy and reaches the recipe runner's dry-run state.

PoV

Run:

python3 poc/poc.py

Expected output:

{
  "ok": true,
  "control_policy": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "bypass_policy": null,
  "bypass_recipe_dry_run_status": "dry_run",
  "workflow_approve_tools": [
    "execute_command"
  ],
  "runner_tool_names": [
    "execute_command"
  ],
  "command_stdout": "poc",
  "operator_env_auto_approve": null
}

The PoV creates two temporary recipes:

  1. A control recipe with TEMPLATE.yaml requires.tools: [execute_command]. recipe.run() returns policy_denied.
  2. A bypass recipe with no dangerous tools in TEMPLATE.yaml, but with workflow.yaml declaring execute_command under an agent and approve: [execute_command]. recipe.run(..., dry_run=True) reaches dry_run, and the same parser/approval context permits a harmless `printf poc.

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Impact

If an operator runs an untrusted recipe, or exposes the recipe runner to users who can choose recipe names/URIs, the recipe can self-authorize a default-denied critical shell tool without the operator setting allow_dangerous_tools=True.

Successful exploitation lets the workflow run execute_command with the privileges of the PraisonAI process if the agent reaches the tool call. The exact trigger depends on the workflow and model/tool-call path, but the policy boundary is already bypassed before execution.

This can affect both local CLI use and HTTP recipe-runner deployments. The HTTP recipe runner defaults to localhost/no-auth and requires auth for non-localhost binding, so this report uses local/UI-required severity rather than claiming an unauthenticated network RCE by default.

The local HTTP sidecar documentation also frames the sidecar as a localhost REST API for local/polyglot integration. If a deployment exposes that API to authenticated users who can choose recipe names or URIs, the same policy bypass can become an authenticated remote recipe-execution issue, but that is not the default severity claim.

Severity

Suggested severity: High.

Suggested Fix

Normalize and validate the actual workflow tool graph before recipe execution:

  • Parse the selected workflow file before or during _check_tool_policy().
  • Include workflow.yaml agents.*.tools, roles.*.tools, included recipes, and other workflow-resolved tool lists in the dangerous-tool policy.
  • Treat approve: as an operator-supplied approval policy, not a recipe-controlled bypass of the recipe-level dangerous-tool gate.
  • If approve: remains recipe-controlled, ignore dangerous/default-denied tool entries unless the caller passed allow_dangerous_tools=True or an explicit external policy allowed that exact tool.
  • Add regression tests for:
  • dangerous tool in TEMPLATE.yaml requires.tools is denied;
  • dangerous tool in workflow.yaml agents.*.tools is also denied;
  • approve: [execute_command] does not bypass the recipe policy;
  • allow_dangerous_tools=True keeps the intended opt-in behavior.

Affected Package/Versions

  • Repository: MervinPraison/PraisonAI
  • Package: praisonai
  • Components:
  • src/praisonai/praisonai/recipe/core.py
  • src/praisonai/praisonai/recipe/models.py
  • src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py
  • src/praisonai-agents/praisonaiagents/workflows/workflows.py
  • src/praisonai-agents/praisonaiagents/approval/registry.py

Validated affected:

  • current main 2f9677abb2ea68eab864ee8b6a828fd0141612e1
  • v4.6.57
  • v4.6.56
  • v4.6.10
  • v4.6.9
  • v4.5.128
  • v4.5.120
  • v4.5.96
  • v4.5.87

Suggested affected range: >= 4.5.87, <= 4.6.57.

PyPI lists PraisonAI 4.6.57 as the latest release on 2026-06-13.

Earlier tested tags through v4.5.85 failed in this source checkout before the tested workflow path due an unrelated praisonaiagents.output.models import error. They are not claimed fixed or unaffected.

Advisory History

Checked visible PraisonAI advisories and prior submissions for the same root cause, affected entrypoint, and exploit preconditions. No exact duplicate is identified in this report text. Adjacent advisories, where relevant, are listed in References or discussed above.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.87"
            },
            {
              "fixed": "4.6.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57142"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:26:57Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes `allow_dangerous_tools=True`. That policy only checks tools declared in `TEMPLATE.yaml` `requires.tools`.\n\nFor steps-based recipes, the actual execution path loads `workflow.yaml` with `YAMLWorkflowParser`. That parser resolves agent-level `tools:` declarations and preserves top-level `approve:`. `Workflow.start()` then installs those YAML-approved tools into the approval context.\n\nAs a result, an untrusted recipe can omit `execute_command` from `TEMPLATE.yaml requires.tools`, declare it in `workflow.yaml agents.*.tools`, and add top-level `approve: [execute_command]`. The caller did not set `allow_dangerous_tools=True`, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.\n\nThe local PoV uses a harmless `printf` canary and explicitly unsets `PRAISONAI_AUTO_APPROVE`.\n\n## Technical Details\n\n`recipe.run()` checks the recipe policy unless `options[\"allow_dangerous_tools\"]` is true. `_check_tool_policy()` gets the required tool list from `recipe_config.get_required_tools()`, which is backed by `TEMPLATE.yaml` `requires.tools`.\n\nThe steps workflow execution path is separate:\n\n1. `_execute_steps_workflow()` parses the workflow file with `YAMLWorkflowParser`.\n2. `YAMLWorkflowParser` resolves `agents.*.tools`.\n3. The same parser reads top-level `approve:` and stores it on `workflow.approve_tools`.\n4. `Workflow.start()` calls `set_yaml_approved_tools(approve_tools)`.\n5. The approval registry treats YAML-approved tools as approved.\n\n`execute_command` is listed as a default dangerous tool with `critical` risk and is decorated with `@require_approval(risk_level=\"critical\")`. The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.\n\n### Why This Is Not Intended Behavior\n\nYAML `approve:` is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.\n\nThe unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, `allow_dangerous_tools=True`, but a recipe can avoid that policy by moving the dangerous tool declaration from `TEMPLATE.yaml requires.tools` into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.\n\nThis conflicts with the documented safety model:\n\n- PraisonAI\u0027s approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.\n- The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.\n- Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.\n- Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.\n\nA control recipe that declares `requires.tools: [execute_command]` is denied with:\n\n```text\nTool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\n```\n\nThe bypass recipe uses the same tool but omits it from `requires.tools`; it passes policy and reaches the recipe runner\u0027s dry-run state.\n\n## PoV\n\nRun:\n\n```bash\npython3 poc/poc.py\n```\n\nExpected output:\n\n```json\n{\n  \"ok\": true,\n  \"control_policy\": \"Tool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\",\n  \"control_recipe_status\": \"policy_denied\",\n  \"bypass_policy\": null,\n  \"bypass_recipe_dry_run_status\": \"dry_run\",\n  \"workflow_approve_tools\": [\n    \"execute_command\"\n  ],\n  \"runner_tool_names\": [\n    \"execute_command\"\n  ],\n  \"command_stdout\": \"poc\",\n  \"operator_env_auto_approve\": null\n}\n```\n\nThe PoV creates two temporary recipes:\n\n1. A control recipe with `TEMPLATE.yaml requires.tools: [execute_command]`. `recipe.run()` returns `policy_denied`.\n2. A bypass recipe with no dangerous tools in `TEMPLATE.yaml`, but with `workflow.yaml` declaring `execute_command` under an agent and `approve: [execute_command]`. `recipe.run(..., dry_run=True)` reaches `dry_run`, and the same parser/approval context permits a harmless `printf poc.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nIf an operator runs an untrusted recipe, or exposes the recipe runner to users who can choose recipe names/URIs, the recipe can self-authorize a default-denied critical shell tool without the operator setting `allow_dangerous_tools=True`.\n\nSuccessful exploitation lets the workflow run `execute_command` with the privileges of the PraisonAI process if the agent reaches the tool call. The exact trigger depends on the workflow and model/tool-call path, but the policy boundary is already bypassed before execution.\n\nThis can affect both local CLI use and HTTP recipe-runner deployments. The HTTP recipe runner defaults to localhost/no-auth and requires auth for non-localhost binding, so this report uses local/UI-required severity rather than claiming an unauthenticated network RCE by default.\n\nThe local HTTP sidecar documentation also frames the sidecar as a localhost REST API for local/polyglot integration. If a deployment exposes that API to authenticated users who can choose recipe names or URIs, the same policy bypass can become an authenticated remote recipe-execution issue, but that is not the default severity claim.\n\n### Severity\n\nSuggested severity: High.\n\n## Suggested Fix\n\nNormalize and validate the actual workflow tool graph before recipe execution:\n\n- Parse the selected workflow file before or during `_check_tool_policy()`.\n- Include `workflow.yaml agents.*.tools`, `roles.*.tools`, included recipes, and other workflow-resolved tool lists in the dangerous-tool policy.\n- Treat `approve:` as an operator-supplied approval policy, not a recipe-controlled bypass of the recipe-level dangerous-tool gate.\n- If `approve:` remains recipe-controlled, ignore dangerous/default-denied tool entries unless the caller passed `allow_dangerous_tools=True` or an explicit external policy allowed that exact tool.\n- Add regression tests for:\n  - dangerous tool in `TEMPLATE.yaml requires.tools` is denied;\n  - dangerous tool in `workflow.yaml agents.*.tools` is also denied;\n  - `approve: [execute_command]` does not bypass the recipe policy;\n  - `allow_dangerous_tools=True` keeps the intended opt-in behavior.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Components:\n  - `src/praisonai/praisonai/recipe/core.py`\n  - `src/praisonai/praisonai/recipe/models.py`\n  - `src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py`\n  - `src/praisonai-agents/praisonaiagents/workflows/workflows.py`\n  - `src/praisonai-agents/praisonaiagents/approval/registry.py`\n\nValidated affected:\n\n- current main `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n- `v4.6.57`\n- `v4.6.56`\n- `v4.6.10`\n- `v4.6.9`\n- `v4.5.128`\n- `v4.5.120`\n- `v4.5.96`\n- `v4.5.87`\n\nSuggested affected range: `\u003e= 4.5.87, \u003c= 4.6.57`.\n\nPyPI lists `PraisonAI 4.6.57` as the latest release on 2026-06-13.\n\nEarlier tested tags through `v4.5.85` failed in this source checkout before the tested workflow path due an unrelated `praisonaiagents.output.models` import error. They are not claimed fixed or unaffected.\n\n## Advisory History\n\nChecked visible PraisonAI advisories and prior submissions for the same root cause, affected entrypoint, and exploit preconditions. No exact duplicate is identified in this report text. Adjacent advisories, where relevant, are listed in References or discussed above.",
  "id": "GHSA-7qw2-w5rc-37x2",
  "modified": "2026-07-20T21:28:14Z",
  "published": "2026-06-18T14:26:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI recipe workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml"
}

GHSA-7QXH-M238-859C

Vulnerability from github – Published: 2024-06-10 15:31 – Updated: 2024-07-26 21:31
VLAI
Details

An issue was discovered in LIVEBOX Collaboration vDesk through v018. A Bypass of Two-Factor Authentication can occur under the /login/backup_code endpoint and the /api/v1/vdeskintegration/createbackupcodes endpoint, because the application allows a user to generate or regenerate the backup codes before checking the TOTP.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-45168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-10T15:15:50Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in LIVEBOX Collaboration vDesk through v018. A Bypass of Two-Factor Authentication can occur under the /login/backup_code endpoint and the /api/v1/vdeskintegration/createbackupcodes endpoint, because the application allows a user to generate or regenerate the backup codes before checking the TOTP.",
  "id": "GHSA-7qxh-m238-859c",
  "modified": "2024-07-26T21:31:15Z",
  "published": "2024-06-10T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45168"
    },
    {
      "type": "WEB",
      "url": "https://www.gruppotim.it/it/footer/red-team.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7R29-W7VH-5P6Q

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40
VLAI
Details

The vulnerability have been reported to affect earlier versions of QTS. If exploited, this improper access control vulnerability could allow attackers to obtain control of a QNAP device. This issue affects: QNAP Systems Inc. Helpdesk versions prior to 3.0.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-2507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-03T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The vulnerability have been reported to affect earlier versions of QTS. If exploited, this improper access control vulnerability could allow attackers to obtain control of a QNAP device. This issue affects: QNAP Systems Inc. Helpdesk versions prior to 3.0.3.",
  "id": "GHSA-7r29-w7vh-5p6q",
  "modified": "2022-05-24T17:40:47Z",
  "published": "2022-05-24T17:40:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2507"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/zh-tw/security-advisory/qsa-20-08"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7R2P-P57X-PQQ4

Vulnerability from github – Published: 2022-05-27 00:00 – Updated: 2022-06-09 00:00
VLAI
Details

The issue was addressed with additional permissions checks. This issue is fixed in macOS Monterey 12.4, macOS Big Sur 11.6.6. A malicious application may be able to bypass Privacy preferences.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-26767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-26T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with additional permissions checks. This issue is fixed in macOS Monterey 12.4, macOS Big Sur 11.6.6. A malicious application may be able to bypass Privacy preferences.",
  "id": "GHSA-7r2p-p57x-pqq4",
  "modified": "2022-06-09T00:00:26Z",
  "published": "2022-05-27T00:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26767"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213256"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213257"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7R4H-2H23-6JQ9

Vulnerability from github – Published: 2022-05-13 01:12 – Updated: 2022-07-01 18:28
VLAI
Summary
Incorrect Authorization in Jenkins
Details

Jenkins before versions 2.44 and 2.32.2 is vulnerable to an insufficient permission check. This allows users with permissions to create new items (e.g. jobs) to overwrite existing items they don't have access to (SECURITY-321).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.32.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.32.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.43"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.34"
            },
            {
              "fixed": "2.44"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-2599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-01T18:28:34Z",
    "nvd_published_at": "2018-04-11T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins before versions 2.44 and 2.32.2 is vulnerable to an insufficient permission check. This allows users with permissions to create new items (e.g. jobs) to overwrite existing items they don\u0027t have access to (SECURITY-321).",
  "id": "GHSA-7r4h-2h23-6jq9",
  "modified": "2022-07-01T18:28:34Z",
  "published": "2022-05-13T01:12:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2599"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/4ed5c850b6855ab064a66d02fb338f366853ce89"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2599"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/jenkins"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2017-02-01"
    }
  ],
  "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"
    }
  ],
  "summary": "Incorrect Authorization in Jenkins"
}

GHSA-7R57-25XW-X723

Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-07-13 00:01
VLAI
Details

IBM Security Secret Server up to 11.0 stores sensitive information in URL parameters. This may lead to information disclosure if unauthorized parties have access to the URLs via server logs, referrer header or browser history. IBM X-Force ID: 199328.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-20582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-14T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Secret Server up to 11.0 stores sensitive information in URL parameters. This may lead to information disclosure if unauthorized parties have access to the URLs via server logs, referrer header or browser history. IBM X-Force ID: 199328.",
  "id": "GHSA-7r57-25xw-x723",
  "modified": "2022-07-13T00:01:05Z",
  "published": "2022-05-24T19:14:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20582"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/199328"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6488459"
    }
  ],
  "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
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.

No CAPEC attack patterns related to this CWE.