marius/Open_Ultra_SAST
1
0
Fork 0
mirror of https://github.com/norandom/OpenUltraSAST.git synced 2026-10-16 11:49:28 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
Open_Ultra_SAST/benchmarks/valid/train/sources_access_control_dropped.json
T

318 lines
27 KiB
JSON
Raw Permalink Normal View History

data: access-control batch verified, awaiting spot-check: 57 of 78 cloned (6 GB disk guard), 148 catalog sites, 69 pass all three checks in 27 changes
2026-10-13 22:07:39 +02:00
[
{
"repository": "payloadcms/payload",
"repo": "payloadcms/payload",
"url": "https://github.com/payloadcms/payload.git",
"fix": "19b58692d20d3947f31124bf7a88ac14a5ebf02e",
"parent": "b8fc06a18afb6974dc07f95ac1e541c716e5926b",
"family": "access_control",
"cwe": "CWE-862",
"advisory": "GHSA-p96c-xwx8-3cqj",
"advisory_text": "Payload has a tenant authorization bypass in Multi-Tenant Plugin\n\n## Impact\n\nWhen using the default tenant array field access, an authenticated user could assign themselves to other tenants.\n\n**You are affected if:**\n\n- You are using `@payloadcms/plugin-multi-tenant`\n\nIf you configure the tenants arrayFieldAccess.create/update functions, a secured replacement membership field, you are not affected by this specific default behavior.\n\n## Patches\n\nUsers should upgrade Payload packages to `>= 3.90.0` or `>= 4.0.0-canary.34`.\n\n## Workarounds\n\nConfigure tenants arrayFieldAccess.create and tenants arrayFieldAccess.update so only trusted users authorized for all tenants can modify memberships.",
"ecosystem": "npm",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "unshiftio/url-parse",
"repo": "unshiftio/url-parse",
"url": "https://github.com/unshiftio/url-parse.git",
"fix": "0e3fb542d60ddbf6933f22eb9b1e06e25eaa5b63",
"parent": "61864a8eccff714a45d23db85a814e3c6ee0baba",
"family": "access_control",
"cwe": "CWE-639",
"advisory": "GHSA-jf5r-8hm2-f872",
"advisory_text": "url-parse incorrectly parses hostname / protocol due to unstripped leading control characters.\n\nLeading control characters in a URL are not stripped when passed into url-parse. This can cause input URLs to be mistakenly be interpreted as a relative URL without a hostname and protocol, while the WHATWG URL parser will trim control characters and treat it as an absolute URL.\n\nIf url-parse is used in security decisions involving the hostname / protocol, and the input URL is used in a client which uses the WHATWG URL parser, the decision may be incorrect.\n\nThis can also lead to a cross-site scripting (XSS) vulnerability if url-parse is used to check for the javascript: protocol in URLs. See following example:\n```js\nconst parse = require('url-parse')\nconst express = require('express')\nconst app = express()\nconst port = 3000\n\nurl = parse(\\\"\\\\bjavascript:alert(1)\\\")\n\nconsole.log(url)\n\napp.get('/', (req, res) => {\n if (url.protocol !== \\\"javascript:\\\") {res.send(\\\"<a href=\\\\'\\\" + url.href + \\\"\\\\'>CLICK ME!</a>\\\")}\n })\n\napp.listen(port, () => {\n console.log(`Example app listening on port ${port}`)\n })\n```",
"ecosystem": "npm",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "yonle/bostr",
"repo": "yonle/bostr",
"url": "https://github.com/Yonle/bostr.git",
"fix": "49181f4ec9ae1472c6675cab56bbc01e723855af",
"parent": "8b131e239b92db889ac5d8fd02bee1d3a035fd9d",
"family": "access_control",
"cwe": "CWE-285",
"advisory": "GHSA-5cf7-cxrf-mq73",
"advisory_text": "Bostr Improper Authorization vulnerability\n\nEven with `authorized_keys` is filled with allowed pubkeys, If `noscraper` is enabled, It will allow anyone to use bouncer even it's pubkey is not in `authorized_keys`.\n\n### Impact\n- Private bouncer\n\n### Patches\nAvailable on version [3.0.10](https://github.com/Yonle/bostr/releases/tag/3.0.10)\n\n### Workarounds\nDisable `noscraper` if you have `authorized_keys` being set in config\n\n### References\nThis [line of code](https://github.com/Yonle/bostr/blob/8665374a66e2afb9f92d0414b0d6f420a95d5d2d/auth.js#L21) is the cause.",
"ecosystem": "npm",
"license_spdx": "BSD-3-Clause",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "scrapy/scrapy",
"repo": "scrapy/scrapy",
"url": "https://github.com/scrapy/scrapy.git",
"fix": "8ce01b3b76d4634f55067d6cfdf632ec70ba304a",
"parent": "aa0306a167ef34b23cc2ec407a48359a4b5a8d0a",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-cjvr-mfj7-j4j8",
"advisory_text": "Incorrect Authorization and Exposure of Sensitive Information to an Unauthorized Actor in scrapy\n\n### Impact\n\nIf you manually define cookies on a [`Request`](https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request) object, and that `Request` object gets a redirect response, the new `Request` object scheduled to follow the redirect keeps those user-defined cookies, regardless of the target domain.\n\n### Patches\n\nUpgrade to Scrapy 2.6.0, which resets cookies when creating `Request` objects to follow redirects¹, and drops the ``Cookie`` header if manually-defined if the redirect target URL domain name does not match the source URL domain name².\n\nIf you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.6.0 is not an option, you may upgrade to Scrapy 1.8.2 instead.\n\n¹ At that point the original, user-set cookies have been processed by the cookie middleware into the global or request-specific cookiejar, with their domain restricted to the domain of the original URL, so when the cookie middleware processes the new (redirect) request it will incorporate those cookies into the new request as long as the domain of the new request matches the domain of the original request.\n\n² This prevents cookie leaks to unintended domains even if the cookies middleware is not used.\n\n### Workarounds\n\nIf you cannot upgrade, set your cookies using a list of dictionaries instead of a single dictionary, as described in the [`Request` documentation](https://docs.scrapy.org/en/latest/topics/request-response.html#scrapy.http.Request), and set the right domain for each cookie.\n\nAlternatively, you can [disable cookies altogether](https://docs.scrapy.org/en/latest/topics/downloader-middleware.html#std-setting-COOKIES_ENABLED), or [limit target domains](https://docs.scrapy.org/en/latest/topics/spiders.html#scrapy.spiders.Spider.allowed_domains) to domains that you trust with all your user-set cookies.\n\n### References\n* Originally reported at [huntr.dev](https://huntr.dev/bounties/3da527b1-2348-4f69-9e88-2e11a96ac585/)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* [Open an issue](https://github.com/scrapy/scrapy/issues)\n* [Email us](mailto:[email protected])",
"ecosystem": "pip",
"license_spdx": "BSD-3-Clause",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "openzeppelin/cairo-contracts",
"repo": "openzeppelin/cairo-contracts",
"url": "https://github.com/OpenZeppelin/cairo-contracts.git",
"fix": "2cd60279c3332285d47edf9ee3888b71257acdc9",
"parent": "f7d319fb19b9afe868034283d66062ae83da649a",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-8mjr-jr5h-q2xr",
"advisory_text": "OpenZeppelin Contracts for Cairo account cannot process transactions on Goerli\n\n### Impact\nThis vulnerability affects all accounts (vanilla and ethereum flavors) in the [v0.2.0 release of OpenZeppelin Contracts for Cairo](https://github.com/OpenZeppelin/cairo-contracts/releases/tag/v0.2.0), which are not whitelisted on StarkNet mainnet, so only goerli deployments of v0.2.0 accounts are affected.\n\nThis faulty behavior is not observed in [StarkNet's testing framework](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/testing/starknet.py), so don't rely on it passing to detect this issue on custom accounts.\n\n### Patches\nThis bug has been patched in [v0.2.1](https://github.com/OpenZeppelin/cairo-contracts/releases/tag/v0.2.1).\n\n### References\nThe issue is detailed in https://github.com/OpenZeppelin/cairo-contracts/issues/386.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [the Contracts for Cairo repo](https://github.com/OpenZeppelin/cairo-contracts/issues/new/choose)\n* Email us at [[email protected]](mailto:[email protected])",
"ecosystem": "pip",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "mercurius-js/mercurius",
"repo": "mercurius-js/mercurius",
"url": "https://github.com/mercurius-js/mercurius.git",
"fix": "5b56f60f4b0d60780b0ff499a479bd830bdd6986",
"parent": "249809aed8c6bcb98c1d53404c6896b32e1f29e1",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-m4h2-mjfm-mp55",
"advisory_text": "Mercurius's queryDepth limit bypassed for WebSocket subscriptions\n\n## Description\n\nMercurius fails to enforce the configured queryDepth limit on GraphQL subscription queries received over WebSocket connections. The depth check is correctly applied to HTTP queries and mutations, but subscription queries are parsed and executed without invoking the depth validation. This allows a remote client to submit arbitrarily deeply nested subscription queries over WebSocket, bypassing the intended depth restriction. On schemas with recursive types, this can lead to denial of service through exponential data resolution on each subscription event.\n\n## Workarounds\n\nDisable subscriptions and, in general, queries over the WebSocket.",
"ecosystem": "npm",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "web-auth/webauthn-framework",
"repo": "web-auth/webauthn-framework",
"url": "https://github.com/web-auth/webauthn-framework.git",
"fix": "572e239c5702667ca52487faf861abc768a46308",
"parent": "de5cd2451e74220708ba5ac891a3c97ce87e7011",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-6whf-q6p5-84wg",
"advisory_text": "Improper Access Control in Webauthn Framework\n\nWebauthn Framework 3.3.x before 3.3.4 has Incorrect Access Control. An attacker that controls a user's system is able to login to a vulnerable service using an attached FIDO2 authenticator without passing a check of the user presence.",
"ecosystem": "composer",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "medialize/uri.js",
"repo": "medialize/uri.js",
"url": "https://github.com/medialize/URI.js.git",
"fix": "6ea641cc8648b025ed5f30b090c2abd4d1a5249f",
"parent": "19e54c78d5864aec43986e8f96be8d15998daa80",
"family": "access_control",
"cwe": "CWE-639",
"advisory": "GHSA-gcv8-gh4r-25x6",
"advisory_text": "Authorization Bypass Through User-Controlled Key in urijs\n\nAttacker can use case-insensitive protocol schemes like HTTP, htTP, HTtp etc. in order to bypass the patch for CVE-2021-3647.",
"ecosystem": "npm",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "thinkst/opencanary",
"repo": "thinkst/opencanary",
"url": "https://github.com/thinkst/opencanary.git",
"fix": "2c11575b1a3dd8b0df26a879ba856c0aa350c049",
"parent": "d3956bc602f95d2bec55eebc96d5e3a2cb35bf47",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-pf5v-pqfv-x8jj",
"advisory_text": "OpenCanary Executes Commands From Potentially Writable Config File\n\n### Impact\n\nOpenCanary directly executed commands taken from its config file. Where the config file is stored in an unprivileged user directory but the daemon is executed by root, it’s possible for the unprivileged user to change the config file and escalate permissions when root later runs the daemon.\n\nThanks to the folks at [Whirlylabs](https://whirlylabs.com/) for finding and fixing this.\n\n### Patches\n\nUpgrade to 0.9.4 or higher.",
"ecosystem": "pip",
"license_spdx": "BSD-3-Clause",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "openstack/barbican",
"repo": "openstack/barbican",
"url": "https://github.com/openstack/barbican.git",
"fix": "7d270bacbe29a90a10f1855abc3b50dac0f08022",
"parent": "8bd16953ebb11c38c02151687967ee93c88067d7",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-p2jg-q8hw-p7gc",
"advisory_text": "Barbican authorization flaw before v14.0.0\n\nAn authorization flaw was found in openstack-barbican. The default policy rules for the secret metadata API allowed any authenticated user to add, modify, or delete metadata from any secret regardless of ownership. This flaw allows an attacker on the network to modify or delete protected data, causing a denial of service by consuming protected resources.",
"ecosystem": "pip",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "parisneo/lollms",
"repo": "parisneo/lollms",
"url": "https://github.com/ParisNeo/lollms.git",
"fix": "a3b2b82b84d537a9da63e63a370a6a8ad55fed34",
"parent": "a2f10ca90129cd8a3a01474562d50d3089eb8c85",
"family": "access_control",
"cwe": "CWE-284",
"advisory": "GHSA-9296-v3fr-j92j",
"advisory_text": "LoLLMs is vulnerable to Improper Access Control through weak secret key\n\nIn parisneo/lollms version 2.1.0, the application's session management is vulnerable to improper access control due to the use of a weak secret key for signing JSON Web Tokens (JWT). This vulnerability allows an attacker to perform an offline brute-force attack to recover the secret key. Once the secret key is obtained, the attacker can forge administrative tokens by modifying the JWT payload and resigning it with the cracked secret. This enables unauthorized users to escalate privileges, impersonate the administrator, and gain access to restricted endpoints. The issue is resolved in version 2.2.0.",
"ecosystem": "pip",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "tomasvotava/fastapi-sso",
"repo": "tomasvotava/fastapi-sso",
"url": "https://github.com/tomasvotava/fastapi-sso.git",
"fix": "6117d1a5ad498ba57d671e8a059ebe20db5abe02",
"parent": "da63c19bca7db0fe8a7e66d03fdf07154ec7182a",
"family": "access_control",
"cwe": "CWE-285",
"advisory": "GHSA-hp6r-r9vc-q8wx",
"advisory_text": "FastAPI SSP is vulnerable to Cross-site Request Forgery (CSRF) through improper OAuth parameter validation\n\nVersions of the package fastapi-sso before 0.19.0 are vulnerable to Cross-site Request Forgery (CSRF) due to the improper validation of the OAuth state parameter during the authentication callback. While the get_login_url method allows for state generation, it does not persist the state or bind it to the user's session. Consequently, the verify_and_process method accepts the state received in the query parameters without verifying it against a trusted local value. This allows a remote attacker to trick a victim into visiting a malicious callback URL, which can result in the attacker's account being linked to the victim's internal account.",
"ecosystem": "pip",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "neuron-core/neuron-ai",
"repo": "neuron-core/neuron-ai",
"url": "https://github.com/neuron-core/neuron-ai.git",
"fix": "44bab85d92bf162898ee48d0bcef6ba0d29b59c9",
"parent": "72735d0ea133266cf2f5d5d195d41e9dd865289a",
"family": "access_control",
"cwe": "CWE-284",
"advisory": "GHSA-898v-775g-777c",
"advisory_text": "Neuron MySQLWriteTool allows arbitrary/destructive SQL when exposed to untrusted prompts (agent “footgun”)\n\n### Impact\n\n`MySQLWriteTool` executes arbitrary SQL provided by the caller using `PDO::prepare()` + `execute()` without semantic restrictions. \n\nThis is consistent with the name (“write tool”), but in an LLM/agent context it becomes a high-risk capability: prompt injection or indirect prompt manipulation can cause execution of destructive queries such as `DROP TABLE`, `TRUNCATE`, `DELETE`, `ALTER`, or privilege-related statements (subject to DB permissions).\n\n\n\n**Who is impacted:** Deployments that expose an agent with `MySQLWriteTool` enabled to untrusted input and/or run the tool with a DB user that has broad privileges.\n\n### Patches\n\n**Not patched in:** 2.8.11 \n\nRecommended improvements (even if keeping the tool intentionally powerful):\n\n- Provide a safer API that supports only constrained operations (e.g., `insertRecord`, `updateRecord`) with allowlisted tables/columns.\n\n- Add a policy/allowlist layer (e.g., allow only `INSERT`/`UPDATE` on selected tables; forbid `DROP/TRUNCATE/ALTER/GRANT`).\n\n- Add optional review workflow: log + require human approval for high-risk statements; or “dry-run” mode.\n\n- Document strongly that the tool must not be exposed to untrusted prompts without additional safeguards.\n\n\n\n### Workarounds\n\n- Do not enable `MySQLWriteTool` for public/untrusted agents.\n\n- Use a dedicated DB user with **least privilege**:\n\n - no `DROP`, no `ALTER`, no `GRANT`, no access to sensitive tables unless necessary\n\n- Add an application-layer policy rejecting high-risk statements (`DROP`, `TRUNCATE`, `ALTER`, `GRANT`, `REVOKE`, `CREATE USER`, etc.).\n\n- Implement authorization gating for tool calls (RBAC, allow tool use only for trusted operators).",
"ecosystem": "composer",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "opensearch-project/reporting",
"repo": "opensearch-project/reporting",
"url": "https://github.com/opensearch-project/reporting.git",
"fix": "2403014c57ee63268e83d919db3334b676a8c992",
"parent": "e54a3eab2c463d2e9eb722fdc0fcec5c78c31864",
"family": "access_control",
"cwe": "CWE-639",
"advisory": "GHSA-xmvg-335g-x44q",
"advisory_text": "The OpenSearch reporting plugin improperly controls tenancy access to reporting resources\n\n### Summary\n\nAn issue in the OpenSearch reporting plugin allows unintended access to private tenant resources like notebooks. The system did not properly check if the user was the resource author when accessing resources in a private tenant, leading to potential data being revealed.\n\n### Impact\n\nThe lack of proper access control validation for private tenant resources in the OpenSearch observability and reporting plugins can lead to unintended data access. If an authorized user with observability or reporting roles is aware of another user's private tenant resource ID, such as a notebook, they can potentially read, modify, or take ownership of that resource, despite not being the original author, thus impacting the confidentiality and integrity of private tenant resources. The impact is confined to private tenant resources, where authorized users may gain inappropriate visibility into data intended to be private from other users within the same OpenSearch instance, potentially violating the intended separation of access. This issue does not alter the scope of access but highlights a flaw in the existing access control mechanisms.\n\nImpacted versions <= 2.13\n\n### Patches\n\nThe patches are included in OpenSearch 2.14\n\n### Workarounds\n\nNone\n\n### References\n\nOpenSearch 2.14 is available for download at https://opensearch.org/versions/opensearch-2-14-0.html\n\nThe latest version of OpenSearch is available for download at https://opensearch.org/downloads.html",
"ecosystem": "maven",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "phpvms/phpvms",
"repo": "phpvms/phpvms",
"url": "https://github.com/phpvms/phpvms.git",
"fix": "f59ba8e0e8fc25c60c3faf14e526cfd49df3f7dc",
"parent": "61118a5802a26b358fadaeb1fb2a95fcfb93ae38",
"family": "access_control",
"cwe": "CWE-284",
"advisory": "GHSA-fv26-4939-62fh",
"advisory_text": "phpVMS has an /importer authorization bypass causing full database wipe\n\n# Security Advisory: Unauthenticated Access to Legacy Import Feature\n\n**Severity:** Critical\n**Affected versions:** phpVMS 7.x (up to 7.0.5)\n**Fixed in:** v7.0.6\n**Component:** Legacy importer\n\n## Summary\n\nA critical vulnerability in phpVMS 7.x allowed unauthenticated access to a legacy import feature. Although this feature is deprecated, parts of it remained accessible and operational.\n\n## Impact\n\nA remote attacker could trigger internal processes that modify or delete application data, potentially resulting in:\n\n- Data loss\n- Service disruption\n\nNo authentication was required.\n\n## Remediation\n\n- **Update immediately** to [the latest patched version](https://github.com/phpvms/phpvms/releases/tag/7.0.7)\n- If unable to update:\n - The release link has instructions on how to fix it (it's a one-line fix to comment out the routes)\n\n## Affected Versions\n\n* Affected: phpVMS 7.x ≤ 7.0.5\n* Not affected: phpVMS >= 7.0.6, v8 (feature removed from public access)",
"ecosystem": "composer",
"license_spdx": "BSD-3-Clause",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "shopware/core",
"repo": "shopware/core",
"url": "https://github.com/shopware/core.git",
"fix": "329e4d7e028dd8081496cf8bd3acc822000b0ec0",
"parent": "2c23a54172c6323bbfef4054d615a131d80fd296",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-83vp-6jqg-6cmr",
"advisory_text": "Incorrect Authentication in shopware\n\n### Impact\nModify Customers, create Orders without App Permission\n\n## Patches\nWe recommend updating to the current version 6.4.8.2. You can get the update to 6.4.8.2 regularly via the Auto-Updater or directly via the download overview.\n\nhttps://www.shopware.com/en/download/#shopware-6\n\n## Workarounds\nFor older versions of 6.1, 6.2, and 6.3, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.",
"ecosystem": "composer",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "smallrye/smallrye-config",
"repo": "smallrye/smallrye-config",
"url": "https://github.com/smallrye/smallrye-config.git",
"fix": "fb0def6f61c09a2a80c9145e4ec6521225cd0b99",
"parent": "4e7ea864c0e3fb32f1f74554133de86032977807",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-54fx-gm74-q676",
"advisory_text": "Permissions bypass in SmallRye\n\nA flaw was found in SmallRye's API through version 1.6.1. The API can allow other code running within the application server to potentially obtain the ClassLoader, bypassing any permissions checks that should have been applied. The largest threat from this vulnerability is a threat to data confidentiality. This is fixed in SmallRye 1.6.2",
"ecosystem": "maven",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "qos-ch/slf4j",
"repo": "qos-ch/slf4j",
"url": "https://github.com/qos-ch/slf4j.git",
"fix": "d2b27fba88e983f921558da27fc29b5f5d269405",
"parent": "0ec1f6aac8648e87a7dda2f5730fef6db3b4fa33",
"family": "access_control",
"cwe": "CWE-284",
"advisory": "GHSA-w77p-8cfg-2x43",
"advisory_text": "Improper Access Control in SLF4J\n\norg.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before `1.8.0-beta4` allows remote attackers to bypass intended access restrictions via crafted data. EventData in the slf4j-ext module in QOS.CH SLF4J, has been fixed in SLF4J version `1.7.26` and later and in the `2.0.x` series.\n\nNote that while the [fix commit](https://github.com/qos-ch/slf4j/commit/d2b27fba88e983f921558da27fc29b5f5d269405) is associated with the tag `1.8.0-beta3`, the versions in [Maven](https://mvnrepository.com/artifact/org.slf4j/slf4j-ext) go directly from `1.8.0-beta2` to `1.8.0-beta4`.",
"ecosystem": "maven",
"license_spdx": "MIT",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "opensearch-project/observability",
"repo": "opensearch-project/observability",
"url": "https://github.com/opensearch-project/observability.git",
"fix": "014423178f8f61d90442dde03cbdcd754c70a84e",
"parent": "162e81a61874c08a3a8ded1d0e39b6aa77390748",
"family": "access_control",
"cwe": "CWE-285",
"advisory": "GHSA-77vc-rj32-2r33",
"advisory_text": "OpenSearch Observability does not properly restrict access to private tenant resources\n\n### Summary\n\nAn issue in the OpenSearch observability plugins allows unintended access to private tenant resources like notebooks. The system did not properly check if the user was the resource author when accessing resources in a private tenant, leading to potential data being revealed.\n\n### Impact\n\nThe lack of proper access control validation for private tenant resources in the OpenSearch observability and reporting plugins can lead to unintended data access. If an authorized user with observability or reporting roles is aware of another user's private tenant resource ID, such as a notebook, they can potentially read, modify, or take ownership of that resource, despite not being the original author, thus impacting the confidentiality and integrity of private tenant resources. The impact is confined to private tenant resources, where authorized users may gain inappropriate visibility into data intended to be private from other users within the same OpenSearch instance, potentially violating the intended separation of access. This issue does not alter the scope of access but highlights a flaw in the existing access control mechanisms.\n\nImpacted versions <= 2.13\n\n### Patches\n\nThe patches are included in OpenSearch 2.14\n\n### Workarounds\n\nNone\n\n### References\n\nOpenSearch 2.14 is available for download at https://opensearch.org/versions/opensearch-2-14-0.html\n\nThe latest version of OpenSearch is available for download at https://opensearch.org/downloads.html",
"ecosystem": "maven",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "stevespringett/alpine",
"repo": "stevespringett/alpine",
"url": "https://github.com/stevespringett/Alpine.git",
"fix": "a7432184b9137ea095799a77f9ced370553acbd7",
"parent": "142876cecbbf4a0169f397651c83c96d0d9b459b",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-2w4p-2hf7-gh8x",
"advisory_text": "Alpine allows URL access filter bypass\n\nAlpine is a scaffolding library in Java. Alpine prior to version 1.10.4 allows URL access filter bypass. This issue has been fixed in version 1.10.4. There are no known workarounds.",
"ecosystem": "maven",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
},
{
"repository": "spring-cloud/spring-cloud-netflix",
"repo": "spring-cloud/spring-cloud-netflix",
"url": "https://github.com/spring-cloud/spring-cloud-netflix.git",
"fix": "8ecb3dca511c3ce0454e42ac31ee2331d7318c07",
"parent": "df64a02013c11156835a9f795078c69323dd0271",
"family": "access_control",
"cwe": "CWE-863",
"advisory": "GHSA-vwpg-f6gw-rjvf",
"advisory_text": "Incorrect Authorization in Spring Cloud Netflix Zuul\n\nApplications using the “Sensitive Headers” functionality in Spring Cloud Netflix Zuul 2.2.6.RELEASE and below may be vulnerable to bypassing the “Sensitive Headers” restriction when executing requests with specially constructed URLs. Applications that use Spring Security's StrictHttpFirewall (enabled by default for all URLs) are not affected by the vulnerability, as they reject requests that allow bypassing.",
"ecosystem": "maven",
"license_spdx": "Apache-2.0",
"origin": "osv",
"clone_status": "not_cloned"
}
]
Reference in New Issue Copy Permalink