{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.70"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:script-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.71"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-2135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-05T20:11:47Z",
    "nvd_published_at": "2020-03-09T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Sandbox protection in Script Security Plugin 1.70 and earlier can be circumvented through:\n- Crafted constructor calls and bodies (due to an incomplete fix of [SECURITY-582](https://www.jenkins.io/security/advisory/2017-08-07/#super-constructor-calls))\n- Crafted method calls on objects that implement `GroovyInterceptable`\n\nThis allows attackers able to specify and run sandboxed scripts to execute arbitrary code in the context of the Jenkins controller JVM.\n\nScript Security Plugin 1.71 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox. In addition, it also intercepts method calls on objects that implement `GroovyInterceptable` as calls to `GroovyObject#invokeMethod(String, Object)`, which is on the list of dangerous signatures and should not be approved for use in the sandbox.",
  "id": "GHSA-qvhf-3567-pc4v",
  "modified": "2025-06-19T14:41:34Z",
  "published": "2022-05-24T17:10:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2135"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/script-security-plugin/commit/5b1969e0bdf5cde04a165b847144756b28495788"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/script-security-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1754"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/03/09/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sandbox bypass vulnerability in Script Security Plugin"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-44911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-22T08:17:05Z",
    "severity": "LOW"
  },
  "details": "Authorization handling for component configuration verification requests in Apache NiFi 1.15.0 through 2.9.0 allows clients with read access to submit proposed configuration properties. The proposed properties override current configuration, enabling users with read access to invoke predefined verification methods with alternative settings. Apache NiFi installations that do not implement different levels of authorization for viewing and modifying component configuration are not subject to this vulnerability. Upgrading to Apache NiFi 2.10.0 is the recommended mitigation, requiring write access to submit configuration verification requests.",
  "id": "GHSA-qvj8-gwpm-4x49",
  "modified": "2026-06-23T21:30:27Z",
  "published": "2026-06-22T09:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44911"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/wrj3t4k2bwd2cztyp078f5kj3722qfzy"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/20/4"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/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:Y/R:U/V:C/RE:L/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-30531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-07T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in Content Security Policy in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass content security policy via a crafted HTML page.",
  "id": "GHSA-qvm2-gfgr-c2h6",
  "modified": "2022-07-13T00:01:22Z",
  "published": "2022-05-24T19:04:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30531"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1115628"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ETMZL6IHCTCTREEL434BQ4THQ7EOHJ43"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PAT6EOXVQFE6JFMFQF4IKAOUQSHMHL54"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.38.11-beta.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ory/oathkeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.38.0-beta.2"
            },
            {
              "fixed": "0.38.12-beta.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-22T20:50:44Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen you make a request to an endpoint that requires the scope `foo` using an access token granted with that `foo` scope, introspection will be valid and that token will be cached. The problem comes when a second requests to an endpoint that requires the scope `bar` is made before the cache has expired. Whether the token is granted or not to the `bar` scope, introspection will be valid.\n\n### Patches\n\nA patch will be released with `v0.38.12-beta.1`.\n\n### Workarounds\n\nPer default, caching is disabled for the `oauth2_introspection` authenticator. When caching is disabled, this vulnerability does not exist.\n\n### Trace\n\nThe cache is checked in [`func (a *AuthenticatorOAuth2Introspection) Authenticate(...)`](https://github.com/ory/oathkeeper/blob/6a31df1c3779425e05db1c2a381166b087cb29a4/pipeline/authn/authenticator_oauth2_introspection.go#L152). From [`tokenFromCache()`](https://github.com/ory/oathkeeper/blob/6a31df1c3779425e05db1c2a381166b087cb29a4/pipeline/authn/authenticator_oauth2_introspection.go#L97) it seems that it only validates the token expiration date, but ignores whether the token has or not the proper scopes.\n\n### Post-Mortem\n\nThe vulnerability was introduced in PR #424. During review, we failed to require appropriate test coverage by the submitter which is the primary reason that the vulnerability passed the review process.\n\nTo avoid this from happening again we enabled codecov with a strict policy on the Ory Oathkeeper repository: Without an increase in code coverage the PR can not be merged.\n\nTo address this issue and any regressions we have added a test suite ensuring that the cache behaviour is correct in the different scenarios:\n\n- Scope strategy is `none`, cache is enabled, and `requested_scope` is not empty -\u003e cache will not be used;\n- Scope strategy is `none`, cache is enabled, and `requested_scope` is empty -\u003e cache will be used;\n- Scope strategy is not `none`, cache is enabled, and `requested_scope` is not empty -\u003e cache will be used;\n\nas well as validating if `iss`, `aud`, `exp`, `token_use`, and scope are validated.\n\nAdditionally, we added [CodeQL scanning](https://github.com/ory/oathkeeper/commit/64ac7562669287d391cd72dfd43c5d71ff9f89a1) to the CI.",
  "id": "GHSA-qvp4-rpmr-xwrr",
  "modified": "2021-06-22T20:50:44Z",
  "published": "2021-06-23T18:00:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ory/oathkeeper/security/advisories/GHSA-qvp4-rpmr-xwrr"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Possible bypass of token claim validation when OAuth2 Introspection caching is enabled"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.58"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11.0"
            },
            {
              "fixed": "4.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:52:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# PraisonAI Slack `app_mention` bypasses configured user/channel authorization\n\n## Summary\n\nPraisonAI\u0027s Slack bot applies its configured `allowed_users`,\n`allowed_channels`, and unknown-user pairing policy in the normal Slack\n`message` event handler, but not in the adjacent Slack `app_mention` event\nhandler.\n\nA Slack workspace user who can mention the bot in a channel where the Slack app\nis present can trigger the configured PraisonAI agent even when:\n\n- the sender is not in `BotConfig.allowed_users`;\n- the channel is not in `BotConfig.allowed_channels`;\n- `unknown_user_policy=\"deny\"` is configured; and\n- the same event content is correctly dropped by the normal `message` handler.\n\nThis is a sibling-handler guard-coverage issue. Slack documents\n`app_mention` as a distinct event type rather than a `message.*` event, so\ndeployments subscribed to app mentions can route unauthorized sender input\naround the guarded message path.\n\n## Affected product\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Component: `src/praisonai/praisonai/bots/slack.py`\n- Configuration component: `src/praisonai-agents/praisonaiagents/bots/config.py`\n\nConfirmed affected:\n\n```text\nv3.11.0  7f37d754a72511a71f7eeaaa8e9f367a5dc45fd8\nv3.11.14 44b800df0eddf32dd5242f47da7513e4a3159d76\nv3.12.0  51f95ad904a6616b35caede1cd74026ec8f7152c\nv4.4.5   9a3363c900fa3be3fce5483be7f6c1f418757ebb\nv4.4.6   90b00f9a25ee5c7ccf4b6ab3152700e1881f262d\nv4.4.12  7d0657632fc477673153ad116cecf692b454bfa3\nv4.5.2   8ddbb4ee7152d3fa68fbaaf6e6c610ae03d938d3\nv4.5.16  02a19776517cc76483fd58dcd6a5fdf8c2c45170\nv4.5.28  16f93251766505a79f237a0f07f68a0ecb17e358\nv4.5.112 bfe3d94bad6db92fc2927c2e3c081ae8303e209e\nv4.5.128 b4e3a8a84ade44ac3dd9102b792cdb4311a95937\nv4.6.10  4b1b17b963cbd0625e41394a30168c95b26429b2\nv4.6.33  dfbb8d78ec7e8dc7118bc722ab1b2524bc98ddab\nv4.6.34  e5928449f73f66cc8af1de61621aa974ab255133\nv4.6.56  d3c4a2afadfbf3a3e172e460e607ba4efad263a6\nv4.6.57  e90d92231853161ad931f3498da57651a9f8b528\nv4.6.58  1ad58ca02975ff1398efeda694ea2ab78f20cf3e\n```\n\nUnaffected boundary control:\n\n```text\nv3.10.24 de1734c29a50af18cf8c69e1d1d90e0f8e391aae\n```\n\n`v3.10.24` does not contain `src/praisonai/praisonai/bots/slack.py`.\n\nSuggested affected range: `praisonai \u003e= 3.11.0, \u003c= 4.6.58`.\n\n## Root cause\n\nThe guarded `message` handler converts the Slack event into a `BotMessage`,\nthen applies channel and sender policy before any agent call:\n\n```python\n@self._app.event(\"message\")\nasync def handle_message(event, say):\n    if event.get(\"bot_id\"):\n        return\n\n    bot_message = self._convert_event_to_message(event)\n    bot_message._channel_type = \"slack\"\n    self.fire_message_received(bot_message)\n\n    if not self.config.is_channel_allowed(\n        bot_message.channel.channel_id if bot_message.channel else \"\"\n    ):\n        return\n\n    user_id = bot_message.sender.user_id if bot_message.sender else \"\"\n    is_explicitly_allowed = (\n        bool(self.config.allowed_users) and self.config.is_user_allowed(user_id)\n    )\n    if not is_explicitly_allowed:\n        user_allowed = await UnknownUserHandler.handle(bot_message, self._bot_context)\n        if not user_allowed:\n            return\n```\n\nOnly after these checks does `handle_message` call the session manager and\nagent.\n\nThe adjacent `app_mention` handler strips the bot mention and directly invokes\nthe agent session. It never calls `is_channel_allowed()`,\n`is_user_allowed()`, or `UnknownUserHandler.handle()`:\n\n```python\n@self._app.event(\"app_mention\")\nasync def handle_mention(event, say):\n    if event.get(\"bot_id\"):\n        return\n\n    text = event.get(\"text\", \"\")\n    if self._bot_user:\n        text = text.replace(f\"\u003c@{self._bot_user.user_id}\u003e\", \"\").strip()\n\n    if self._agent:\n        user_id = event.get(\"user\", \"unknown\")\n        response = await self._session.chat(\n            self._agent, user_id, text,\n            chat_id=str(event.get(\"channel\", \"\")),\n            thread_id=event.get(\"thread_ts\", \"\") or \"\",\n            message_id=event.get(\"ts\", \"\"),\n            account=self._config.get(\"account\", \"default\"),\n        )\n```\n\nOlder affected releases use `self._agent.chat(text)` instead of\n`self._session.chat(...)`, but have the same policy gap: `message` checks\n`allowed_users` and `allowed_channels`; `app_mention` does not.\n\n## Local-only PoV\n\nRun from the harness checkout:\n\n```fish\nenv PYTHONPATH=\"artifacts/repos/praisonai-v4.6.58/src/praisonai:artifacts/repos/praisonai-v4.6.58/src/praisonai-agents\" \\\n  python3 submission-bundle/praisonai-prai-cand-017-slack-app-mention-authz-bypass/poc/pov_prai_cand_017_slack_app_mention_authz_bypass.py \\\n    --repo artifacts/repos/praisonai-v4.6.58 \\\n    --label v4.6.58\n```\n\nThe PoV mocks Slack Bolt and Slack SDK in-process. It does not connect to\nSlack, bind a network port, or require real tokens.\n\nThe PoV configures:\n\n```python\nBotConfig(\n    allowed_users=[\"U_ALLOWED\"],\n    allowed_channels=[\"C_ALLOWED\"],\n    unknown_user_policy=\"deny\",\n    mention_required=True,\n)\n```\n\nIt then invokes the real registered SlackBot handlers with the same event\npayloads.\n\nObserved `v4.6.58` result:\n\n```json\n{\n  \"affected\": true,\n  \"scenarios\": [\n    {\n      \"name\": \"blocked_user_blocked_channel\",\n      \"message_delta\": 0,\n      \"app_mention_delta\": 1\n    },\n    {\n      \"name\": \"blocked_user_allowed_channel\",\n      \"message_delta\": 0,\n      \"app_mention_delta\": 1\n    },\n    {\n      \"name\": \"allowed_user_blocked_channel\",\n      \"message_delta\": 0,\n      \"app_mention_delta\": 1\n    },\n    {\n      \"name\": \"allowed_user_allowed_channel_control\",\n      \"message_delta\": 1,\n      \"app_mention_delta\": 1\n    }\n  ]\n}\n```\n\nThe first three scenarios are authorization bypasses. The fourth is the\npositive control showing that an allowed user in an allowed channel can invoke\nthe agent through both paths.\n\nStored evidence:\n\n- `evidence/pov-v4.6.58.json`\n- `evidence/version-sweep.tsv`\n\n## Why this is not intended behavior\n\nPraisonAI\u0027s bot security documentation describes Slack user/channel allowlists\nand built-in DM filtering as Slack security features. It also describes\n`unknown_user_policy=\"deny\"` and pairing flows as production controls for\nunknown users.\n\nThe code itself confirms the intended boundary: the normal `message` handler\nperforms channel and sender authorization before any agent call. The vulnerable\n`app_mention` path is adjacent to that handler and routes the same sender,\nchannel, text, timestamp, and thread metadata to the agent without those checks.\n\nSlack\u0027s own documentation states that `app_mention` is a separate event type,\nnot a `message.*` event. A PraisonAI deployment that subscribes to\n`app_mention` therefore cannot rely on the normal `message` handler to apply\nthe same sender/channel policy.\n\nThe PoV includes a direct control: the same unauthorized payloads are dropped\nby the guarded `message` handler and accepted by `app_mention`.\n\n## Impact\n\nAn attacker needs the ability to cause Slack to deliver an `app_mention` event\nto the PraisonAI Slack app, such as by mentioning the bot in a channel where the\napp is present or by using Slack\u0027s invite-by-mention flow where applicable.\n\nWhen exploited, the attacker can submit arbitrary prompt text to the configured\nPraisonAI agent despite Slack bot allowlists or pairing policy. The downstream\nimpact depends on the deployed agent and tools. PraisonAI\u0027s default bot config\nauto-approves safe tools and includes web, memory, scheduling, file, planning,\nand skill tools, so unauthorized invocation can affect confidentiality and\nintegrity in real deployments.\n\nThis report does not claim compromise of Slack itself, bypass of Slack request\nsignature verification, or arbitrary code execution by default.\n\n## Suggested fix\n\nUse one shared authorization preflight for every Slack ingress path before\nfiring message hooks or invoking agents.\n\nConcrete patch direction:\n\n1. Convert `app_mention` events through `_convert_event_to_message()` or a\n   dedicated equivalent that preserves sender, channel, text, timestamp, and\n   thread metadata.\n2. Set `bot_message._channel_type = \"slack\"` for `app_mention`.\n3. Run the same channel check, user allowlist check, and\n   `UnknownUserHandler.handle(...)` policy used by `handle_message`.\n4. Only then strip the bot mention and invoke `_session.chat(...)`.\n5. Add regression tests for:\n   - blocked user plus blocked channel: `message` and `app_mention` both drop;\n   - blocked user in allowed channel: both drop;\n   - allowed user in blocked channel: both drop;\n   - allowed user in allowed channel: both invoke;\n   - `unknown_user_policy=\"pair\"`: `app_mention` starts the same pairing flow\n     instead of invoking the agent.",
  "id": "GHSA-qvpf-j64c-jmhr",
  "modified": "2026-06-18T13:52:47Z",
  "published": "2026-06-18T13:52:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qvpf-j64c-jmhr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI Slack app_mention bypasses configured user/channel authorization"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.9-alpha1"
            },
            {
              "fixed": "2.4.9-alpha3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.8-beta1"
            },
            {
              "fixed": "2.4.8-p3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.7-beta1"
            },
            {
              "fixed": "2.4.7-p8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.6-p13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.8"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.7"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-21T20:49:43Z",
    "nvd_published_at": "2025-10-14T21:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Magento versions 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier are affected by an Incorrect Authorization vulnerability. A low-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized access to elevated privileges that increase integrity impact to high. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-qvwr-p3hj-j6jf",
  "modified": "2025-10-21T20:49:43Z",
  "published": "2025-10-14T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54267"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb25-94.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"
    }
  ],
  "summary": "Magento vulnerable to privilege escalation due to incorrect authorization"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:ontrack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-09T00:51:51Z",
    "nvd_published_at": "2019-04-18T17:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "A sandbox bypass vulnerability in Jenkins ontrack Plugin 3.4 and earlier allowed attackers with control over ontrack DSL definitions to execute arbitrary code on the Jenkins master JVM.",
  "id": "GHSA-qw28-g63m-jxqv",
  "modified": "2022-09-09T00:51:51Z",
  "published": "2022-05-24T16:43:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10306"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/ontrack-plugin/commit/7f0f806c18fdd6043103d848ba4c813cb805dd85"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/ontrack-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-04-17/#SECURITY-1341"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108045"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sandbox bypass in ontrack Jenkins Plugin"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-3920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-29T07:15:13Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab affecting all versions starting from 11.2 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. It was possible that a maintainer to create a fork relationship between existing projects contrary to the documentation.",
  "id": "GHSA-qw5x-x275-9wwh",
  "modified": "2024-04-04T07:58:13Z",
  "published": "2023-09-29T09:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3920"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2058121"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/417481"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-29927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-16T20:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Versions of Sage 300 through 2022 implement role-based access controls that are only enforced client-side. Low-privileged Sage users, particularly those on a workstation setup in the \"Windows Peer-to-Peer Network\" or \"Client Server Network\" Sage 300 configurations, could recover the SQL connection strings being used by Sage 300 and interact directly with the underlying database(s) to create, update, and delete all company records, bypassing the program\u2019s role-based access controls.",
  "id": "GHSA-qw6r-773c-w64h",
  "modified": "2025-01-23T18:31:06Z",
  "published": "2023-07-06T21:14:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29927"
    },
    {
      "type": "WEB",
      "url": "https://www.controlgap.com/blog/critical-vulnerability-disclosure-sage-300"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-23730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-11T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The public API error causes for the attacker to be able to bypass API access control.",
  "id": "GHSA-qwfh-q845-fhm2",
  "modified": "2022-03-19T00:01:12Z",
  "published": "2022-03-12T00:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23730"
    },
    {
      "type": "WEB",
      "url": "https://lgsecurity.lge.com/bulletins/tv"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}