[ { "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" }, { "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(\\\"CLICK ME!\\\")}\n })\n\napp.listen(port, () => {\n console.log(`Example app listening on port ${port}`)\n })\n```", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "repository": "auth0/symfony", "repo": "auth0/symfony", "url": "https://github.com/auth0/symfony.git", "fix": "0103d6f8dcef6996653fad1f823d1c167f472479", "parent": "5b25bd544b93f0e912ec9a84a415c8dcf3055ad0", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-f3r2-88mq-9v4g", "advisory_text": "Auth0 Symfony SDK has Improper Audience Validation via Auth0-PHP SDK\n\n### Description\nIn applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.\n\n### Affected product and versions\nProjects are affected if they meet the following preconditions:\n\n- Applications using the Auth0 Symfony SDK with versions between 5.0.0 and 5.5.0\n- Auth0 Symfony SDK uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.\n\n### Resolution\nUpgrade Auth0/symfony to version 5.6.0 or greater.\n\n### Acknowledgement\nOkta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.", "ecosystem": "composer", "license_spdx": "MIT", "origin": "osv" }, { "repository": "friendsofflarum/byobu", "repo": "friendsofflarum/byobu", "url": "https://github.com/FriendsOfFlarum/byobu.git", "fix": "23dcf93a30f948d30c678a96681f7fdefeba5171", "parent": "2e99cdb7e356a259ea90aa7f84a71fc0f050e006", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-6gjm-6wj6-4px5", "advisory_text": "Byobu user preference to prevent private discussions being started are not respected\n\n### Impact\nUsers electing to prevent others starting private discussions with themselves.\n\n> Please note that admins and others with appropriate permissions can always bypass this preference, as was the case before.\n\n### Patches\nUsers of Byobu should update the extension to version 1.1.7, where this has been patched. **This version is only supported on v1.2.0 and later of Flarum Core.**\n\nUsers of Byobu with Flarum 1.0 or 1.1 should upgrade to Flarum 1.2 or later, or evaluate the impact this issue has on your forum's users and choose to disable the extension if needed.\n\n### Workarounds\nThere are no workarounds for this issue.", "ecosystem": "composer", "license_spdx": "MIT", "origin": "osv" }, { "repository": "koajs/router", "repo": "koajs/router", "url": "https://github.com/koajs/router.git", "fix": "d53e17f284557b1f417946f9807ee52290c3c759", "parent": "e64b164174f8f09301da02d697c9c7dddc515b8c", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-47p6-69vm-vw6v", "advisory_text": "@koa/router has an Access Control Bypass\n\nVersions of the package @koa/router from 14.0.0 and before 15.0.0 are vulnerable to Access Control Bypass due to the middleware being silently dropped from the execution chain when the router prefix contains path parameters. Depending on what the skipped middleware was supposed to protect, an attacker could bypass authentication and authorization, evade rate limiting or bypass input sanitization.", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "ionicabizau/parse-path", "repo": "ionicabizau/parse-path", "url": "https://github.com/IonicaBizau/parse-path.git", "fix": "f9ad8856a3c8ae18e1cf4caef5edbabbc42840e8", "parent": "3795a3cda744b599a9247cca35395be4f3635b1b", "family": "access_control", "cwe": "CWE-639", "advisory": "GHSA-3j8f-xvm3-ffx4", "advisory_text": "Authorization Bypass in parse-path\n\nAuthorization Bypass Through User-Controlled Key in GitHub repository ionicabizau/parse-path prior to 5.0.0.", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/conjur-credentials-plugin", "repo": "jenkinsci/conjur-credentials-plugin", "url": "https://github.com/jenkinsci/conjur-credentials-plugin.git", "fix": "eda06cde26cdf2d40ae4e2f4d2709e8174489068", "parent": "811b0672d5a88d2145823f7355619ddd5f328e17", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-372f-jc47-7gr5", "advisory_text": "Missing permission check in Jenkins Conjur Secrets Plugin allows enumerating credentials IDs\n\nConjur Secrets Plugin 1.0.11 and earlier does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "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:opensource@zyte.com)", "ecosystem": "pip", "license_spdx": "BSD-3-Clause", "origin": "osv" }, { "repository": "googlechrome/rendertron", "repo": "googlechrome/rendertron", "url": "https://github.com/GoogleChrome/rendertron.git", "fix": "8d70628c96ae72eff6eebb451d26fc9ed6b58b0e", "parent": "93e2c48088ea24853a61f1e0d205d0f356fa16ca", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-4q69-q4q7-x82c", "advisory_text": "rendertron can remotely shut down Chrome instance\n\nRendertron 1.0.0 includes an `_ah/stop` route to shutdown the Chrome instance responsible for serving render requests to all users. Visiting this route with a GET request allows any unauthorized remote attacker to disable the core service of the application.", "ecosystem": "npm", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jupyterhub/kubespawner", "repo": "jupyterhub/kubespawner", "url": "https://github.com/jupyterhub/kubespawner.git", "fix": "3dfe870a7f5e98e2e398b01996ca6b8eff4bb1d0", "parent": "b7f55eae3d5afb6ac9f2facf76f46239e2f2a38a", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-v7m9-9497-p9gr", "advisory_text": "Possible pod name collisions in jupyterhub-kubespawner\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nJupyterHub deployments using:\n\n- KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and\n- enabled named_servers (not default), and\n- an Authenticator that allows:\n - usernames with hyphens or other characters that require escape (e.g. `user-hyphen` or `user@email`), and\n - usernames which may match other usernames up to but not including the escaped character (e.g. `user` in the above cases)\n\nIn this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nPatch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n#### KubeSpawner\n\nSpecify configuration:\n\nfor KubeSpawner\n```python\nfrom traitlets import default\nfrom kubespawner import KubeSpawner\n\nclass PatchedKubeSpawner(KubeSpawner):\n @default(\"pod_name_template\")\n def _default_pod_name_template(self):\n if self.name:\n return \"jupyter-{username}-{servername}\"\n else:\n return \"jupyter-{username}\"\n\n @default(\"pvc_name_template\")\n def _default_pvc_name_template(self):\n if self.name:\n return \"claim-{username}-{servername}\"\n else:\n return \"claim-{username}\"\n\nc.JupyterHub.spawner_class = PatchedKubeSpawner\n```\n\n**Note for KubeSpawner:** this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.\n\nChanging the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.\n\n### References\n_Are there any links users can visit to find out more?_\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [kubespawner](https://github.com/jupyterhub/kubespawner)\n* Email us at [security@ipython.org](mailto:security@ipython.org)\n\nCredit: Jining Huang", "ecosystem": "pip", "license_spdx": "BSD-3-Clause", "origin": "osv" }, { "repository": "jenkinsci/database-plugin", "repo": "jenkinsci/database-plugin", "url": "https://github.com/jenkinsci/database-plugin.git", "fix": "7a438d96897af0034cb2e06db0819ca4595c24cb", "parent": "a68258cf17ba8d5264010cc760770a62a3cc6c2d", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-hj36-v72x-cc6j", "advisory_text": "Missing permission checks in Jenkins Database Plugin\n\nA missing permission check in Jenkins database Plugin 1.6 and earlier allows attackers with Overall/Read access to Jenkins to connect to an attacker-specified database server using attacker-specified credentials.\n\nDatabase Plugin 1.7 requires Overall/Administer permission for the affected form validation method.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "keylime/keylime", "repo": "keylime/keylime", "url": "https://github.com/keylime/keylime.git", "fix": "9e5ac9f25cd400b16d5969f531cee28290543f2a", "parent": "d21f3b46aa5d8c3ec2050a98abc37958413647a5", "family": "access_control", "cwe": "CWE-639", "advisory": "GHSA-f4r5-q63f-gcww", "advisory_text": "Keylime registrar and (untrusted) Agent can be bypassed by an attacker\n\n### Impact\n\nA security issue was found in the Keylime `registrar` code which allows an attacker to effectively bypass the challenge-response protocol used to verify that an `agent` has indeed access to an AIK which in indeed related to the EK.\n\nWhen an `agent` starts up, it will contact a `registrar` and provide a public EK and public AIK, in addition to the EK Certificate. This `registrar` will then challenge the `agent` to decrypt a challenge encrypted with the EK. \n\nWhen receiving the wrong \"auth_tag\" back from the `agent` during activation, the `registrar` answers with an error message that contains the expected correct \"auth_tag\" (an HMAC which is calculated within the `registrar` for checking). An attacker could simply record the correct expected \"auth_tag\" from the HTTP error message and perform the activate call again with the correct expected \"auth_tag\" for the `agent`.\n\nThe security issue allows an attacker to pass the challenge-response protocol during registration with (almost) arbitrary registration data. In particular, the attacker can provide a valid EK Certificate and EK, which passes verification by the `tenant` (or `registrar`), while using a compromised AIK, which is stored unprotected outside the TPM and is unrelated to former two. The attacker then deliberately fails the initial activation call to get to know the correct \"auth_tag\" and then provides it in a subsequent activation call. This results in an `agent` which is (incorrectly) registered with a valid EK Certificate, but with a compromised/unrelated AIK.\n\n### Patches\nUsers should upgrade to release 7.5.0", "ecosystem": "pip", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "auth0/nextjs-auth0", "repo": "auth0/nextjs-auth0", "url": "https://github.com/auth0/nextjs-auth0.git", "fix": "98c36dc306970c2230ea1a32efef431d29b99978", "parent": "b06d30f26a22cd738ddfd5cfdaff8a4faf4328b6", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-xq8m-7c5p-c2r6", "advisory_text": "Auth0 Next.js SDK has Improper Proxy Cache Lookup\n\n### Description\nIn affected versions of the Next.js SDK, simultaneous requests that trigger a nonce retry may cause the proxy cache fetcher to perform improper lookups for the token request results.\n\n### Which Projects are Affected?\nUsers are affected if they meet all of the following preconditions:\n- Applications using the auth0/nextjs-auth0 SDK, versions 4.12.0 to 4.17.0, and\n- Applications using the proxy handler /me/* and /my-org/* with DPoP enabled.\n\n\n### Affected product and versions\nAuth0/nextjs-auth0 v4.12.0 to 4.17.0\n\n### Resolution\nUpgrade Auth0/nextjs-auth0 version to v4.18.0 or greater\n\n### Acknowledgements\nOkta would like to thank Reynaldo Immanuel for their discovery and responsible disclosure.", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "repository": "keystonejs/keystone", "repo": "keystonejs/keystone", "url": "https://github.com/keystonejs/keystone.git", "fix": "650e27e6e9b42abfb94c340c8470faf61f0ff284", "parent": "8c43bd37baacaee6180b763cfde391a665c5d322", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-9cvc-v7wm-992c", "advisory_text": "When `ui.isAccessAllowed` is `undefined`, the `adminMeta` GraphQL query is publicly accessible\n\n### Summary\nWhen `ui.isAccessAllowed` is `undefined`, the `adminMeta` GraphQL query is publicly accessible, that is to say, no session is required for the query.\n\nThis is different to the behaviour of the default AdminUI middleware, which by default will only be publicly accessible if a `session` strategy is not defined. \n\n### Impact\nThis vulnerability does not affect developers using the `@keystone-6/auth` package, or any users that have written their own `ui.isAccessAllowed` (that is to say, you are unaffected if `ui.isAccessAllowed` is defined).\n\nThis vulnerability does affect developers who thought that their `session` strategy will, by default, enforce that `adminMeta` is inaccessible by the public in accordance with that strategy; akin to the behaviour of the AdminUI middleware.\n\n### Patches\nThis vulnerability has been patched in `@keystone-6/core` version `5.5.1`.\n\n### Workarounds\nYou can opt to write your own `isAccessAllowed` to work-around this vulnerability.\n\n### References\nPull request https://github.com/keystonejs/keystone/pull/8771", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/electricflow-plugin", "repo": "jenkinsci/electricflow-plugin", "url": "https://github.com/jenkinsci/electricflow-plugin.git", "fix": "597cbb1d767ae92c44b4cbd9525fa53ddab37117", "parent": "fe6308b281ded7377c927b78fb0390d5816ba492", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-7rx6-4vwv-432g", "advisory_text": "Missing permission check in Jenkins CloudBees CD Plugin allows scheduling builds\n\nJenkins CloudBees CD Plugin does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Item/Read permission to schedule builds of projects without having Item/Build permission.\n\nJenkins CloudBees CD Plugin requires Item/Build permission to schedule builds via its HTTP endpoint.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/crx-content-package-deployer-plugin", "repo": "jenkinsci/crx-content-package-deployer-plugin", "url": "https://github.com/jenkinsci/crx-content-package-deployer-plugin.git", "fix": "06cd0e7e1b3f2fb87b3fa332ee1da710ca94b8e1", "parent": "1313c422170a064dab0f9359324ff27e30a9f4a5", "family": "access_control", "cwe": "CWE-285", "advisory": "GHSA-4cmq-88f8-53r5", "advisory_text": "Jenkins CRX Content Package Deployer Plugin subject to credentials enumeration via Missing Authorization\n\nA missing permission check in Jenkins CRX Content Package Deployer Plugin prior to version 1.9 in various 'doFillCredentialsIdItems' methods allowed users with Overall/Read access to enumerate credentials ID of credentials stored in Jenkins. This issue is patched in version 1.9.", "ecosystem": "maven", "license_spdx": "Unlicense", "origin": "osv" }, { "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 [security@openzeppelin.com](mailto:security@openzeppelin.com)", "ecosystem": "pip", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/azure-keyvault-plugin", "repo": "jenkinsci/azure-keyvault-plugin", "url": "https://github.com/jenkinsci/azure-keyvault-plugin.git", "fix": "f09ed652cc572d8ba5d7c8c8f9972fd241883c21", "parent": "36680c54a27685d6d35d75135daa6e386a107a1b", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-gf8w-6hcm-rh3j", "advisory_text": "Missing permission checks in Jenkins Azure Key Vault Plugin allow enumerating credentials IDs\n\nJenkins Azure Key Vault Plugin 2.0 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.\n\nAn enumeration of credentials IDs in Jenkins Azure Key Vault Plugin 2.1 requires the appropriate permissions.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "aws/aws-dynamodb-encryption-python", "repo": "aws/aws-dynamodb-encryption-python", "url": "https://github.com/aws/aws-dynamodb-encryption-python.git", "fix": "90606ec9af7c2b5cb338d64639a62ee867d38d6b", "parent": "f133fc2dc4cfa763829faa5be7ea8f23140a5f1d", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-4ph2-8337-hm62", "advisory_text": "Key Caching behavior in the DynamoDB Encryption Client.\n\n### Impact\nThis advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified.\n\nWhen key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider.\n\n### Patches\nFixed as of 1.3.0. We recommend users to modify their code and adopt `CachingMostRecentProvider`.\n\n\n### Workarounds\nUsers who cannot upgrade to use the `CachingMostRecentProvider` can call `clear()` on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.", "ecosystem": "pip", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/azure-credentials-plugin", "repo": "jenkinsci/azure-credentials-plugin", "url": "https://github.com/jenkinsci/azure-credentials-plugin.git", "fix": "64da8176c83a41bb83d3ad759628c9bd275b42f5", "parent": "887e0f9e898b2765d78e53c7b39017b8d6295dca", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-7j55-28qq-676g", "advisory_text": "Missing Authorization in Jenkins Azure Credentials Plugin\n\nA missing permission check in Jenkins Azure Credentials Plugin 253.v887e0f9e898b and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "mage-ai/mage-ai", "repo": "mage-ai/mage-ai", "url": "https://github.com/mage-ai/mage-ai.git", "fix": "f63cd00f6a3be372397d37a4c9a49bfaf50d7650", "parent": "e16a64962d540046b1210b5b749897cf600f0ed3", "family": "access_control", "cwe": "CWE-306", "advisory": "GHSA-c6mm-2g84-v4m7", "advisory_text": "Mage-ai missing user authentication\n\n### Impact\n\nYou may be impacted if you're using Mage with user authentication enabled. The terminal could be accessed by users who are not signed in or do not have editor permissions.\n\n### Patches\n\nThe vulnerability has been resolved in Mage version 0.8.72.", "ecosystem": "pip", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "balderdashy/sails", "repo": "balderdashy/sails", "url": "https://github.com/balderdashy/sails.git", "fix": "0057123a0321be6758845abbeb4290bf418ce542", "parent": "8d642f1ab3d46491cf7b73af1ec54941ff0eb84b", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-qmv4-jgp7-mf68", "advisory_text": "Sails before 0.12.7 vulnerable to Broken CORS\n\nAffected versions of `sails` have an issue with the CORS configuration where the value of the origin header is reflected as the value for the `Access-Control-Allow-Origin` header. This may allow an attacker to make AJAX requests to vulnerable hosts through cross-site scripting or a malicious HTML Document, effectively bypassing the Same Origin Policy. \n\n## Mitigating Factors\n\nThis is only an issue when `allRoutes` is set to `true` and `origin` is set to `*` or left commented out in the sails CORS config file. \n\nThe problem can be compounded when the cors `credentials` setting is not provided, because at that point authenticated cross domain requests are possible.\n\n\n## Recommendation\n\nUpdate to version 0.12.7 or later.\n\nAs this vulnerability is primarily a user error, the patch for the vulnerability will simply cause the application to write an error message to the console when a vulnerable configuration is used in a production environment.\n\nWriting a proper CORS configuration is still the responsibility of the user, so it is necessary to check for the error message after installing the patch. Be sure you are not using `allRoutes: true` with `origin:'*'`, and that you uncomment `origin` and set it to a reasonable value. Ensure that if `origin` is set to `*` that you truly mean for all other websites to be able to make cross-domain requests to your API.\n\nLikewise, ensure `credentials` is uncommented out and set to the appropriate value. Make sure to explicitly set which origins may request resources via CORS.", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "arthurfiorette/axios-cache-interceptor", "repo": "arthurfiorette/axios-cache-interceptor", "url": "https://github.com/arthurfiorette/axios-cache-interceptor.git", "fix": "49a808059dfc081b9cc23d48f243d55dfce15f01", "parent": "f88d836f0895dec621b84793ff78564873bc2e6c", "family": "access_control", "cwe": "CWE-639", "advisory": "GHSA-x4m5-4cw8-vc44", "advisory_text": "axios-cache-interceptor Vulnerable to Cache Poisoning via Ignored HTTP Vary Header\n\n## Summary\n\nWhen a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass.\n\n## Details\n\nThe cache key is generated only from the URL, ignoring request headers like `Authorization`. When the server responds with `Vary: Authorization` (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization.\n\n## Impact\n\n**Affected:** Server-side applications (APIs, proxies, backend services) that:\n\n- Use axios-cache-interceptor to cache requests to upstream services\n- Handle requests from multiple users with different auth tokens\n- Upstream services replies on `Vary` to differentiate caches\n\n**Not affected:** Browser/client-side applications (single user per browser session).\n\nServices using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions.\n\n## Solution\n\nAfter `v1.11.1`, automatic `Vary` header support is now enabled by default.\n\nWhen server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache.\n\n```js\n// v1.11.1+ (automatic, no config needed)\n// User 123: key = hash(url + {authorization: 'Bearer 123'})\n// User 456: key = hash(url + {authorization: 'Bearer 456'})\n// ✓ Different caches, no poisoning\n```\n\n## Remediation\n\nUpgrade to v1.11.1 or later. _No code changes required, protection is automatic_\n\n\n## Proof of Concept\n\n```js\nconst http = require('node:http');\nconst axios = require('axios');\nconst { setupCache } = require('axios-cache-interceptor');\n\n// Server that returns different responses based on Authorization\nconst server = http.createServer((req, res) => {\n const auth = req.headers.authorization;\n\n res.setHeader('Vary', 'Authorization');\n\n if (auth === 'Bearer 123') {\n res.write('Hello, user 123!');\n } else if (auth === 'Bearer 456') {\n res.write('Hello, user 456!');\n } else {\n res.write('Unknown');\n }\n\n res.end();\n});\n\nserver.listen(5000);\n\n// Client making requests with different tokens\nconst cachedAxios = setupCache(axios.create());\n\nconst server2 = http.createServer(async (_req, res) => {\n const authHeader =\n Math.random() < 0.5 ? 'Bearer 123' : 'Bearer 456';\n\n const response = await cachedAxios.get('http://localhost:5000', {\n headers: { Authorization: authHeader }\n });\n\n console.log({\n response: response.data,\n cached: response.cached,\n auth: authHeader\n });\n res.write(response.data);\n res.end();\n});\n\nserver2.listen(5001);\n\n// Trigger 10 requests\nPromise.all(\n Array.from({ length: 10 }, () =>\n axios.get('http://localhost:5001').catch(console.error)\n )\n).finally(() => {\n server.close();\n server2.close();\n});\n```\n\nAll 10 responses return \"Hello, user 123!\" even when using \"Bearer 456\" - users receive each other's cached data.", "ecosystem": "npm", "license_spdx": "MIT", "origin": "osv" }, { "repository": "labd/wagtail-2fa", "repo": "labd/wagtail-2fa", "url": "https://github.com/labd/wagtail-2fa.git", "fix": "ac23550d33b7436e90e3beea904647907eba5b74", "parent": "ad8d77ab4fbae04d0f4f29613a3f9aa32d420d4a", "family": "access_control", "cwe": "CWE-285", "advisory": "GHSA-9gjv-6qq6-v7qm", "advisory_text": "2FA bypass through deleting devices in wagtail-2fa\n\n### Impact\nAny user with access to the CMS can view and delete other users' 2FA devices by going to the correct path. The user does not require special permissions in order to do so. By deleting the other user's device they can disable the target user's 2FA devices and potentially compromise the account if they figure out their password.\n\n### Patches\nThe problem has been patched in version 1.4.1.\n\n### Workarounds\nThere is no workaround for this issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [github.com/labd/wagtail-2fa](https://github.com/labd/wagtail-2fa)\n* Email us at [security@labdigital.nl](mailto:security@labdigital.nl)", "ecosystem": "pip", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/mac-plugin", "repo": "jenkinsci/mac-plugin", "url": "https://github.com/jenkinsci/mac-plugin.git", "fix": "86aebd3d33526d83d6cbc9aef7fb1f4831fb1805", "parent": "9f7e1dbbf0636515cc900459f36d5534014d4f95", "family": "access_control", "cwe": "CWE-285", "advisory": "GHSA-2m74-x26c-g7xc", "advisory_text": "Missing permission checks in Mac Plugin\n\nA missing permission check in Jenkins Mac Plugin 1.1.0 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "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" }, { "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" }, { "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" }, { "repository": "jenkinsci/compuware-topaz-utilities-plugin", "repo": "jenkinsci/compuware-topaz-utilities-plugin", "url": "https://github.com/jenkinsci/compuware-topaz-utilities-plugin.git", "fix": "a79f95c7d32ad6a2e161159fa77f371705f3b20d", "parent": "24b499623f52c930df3e2715dd64ae1079d70b43", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-qf4p-7gqc-x6jx", "advisory_text": "Jenkins Compuware Topaz Utilities Plugin is missing authorization\n\nJenkins Compuware Topaz Utilities Plugin 1.0.8 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to enumerate hosts and ports of Compuware configurations and credentials IDs of credentials stored in Jenkins. Those credentials IDs can be used as part of an attack to capture the credentials using another vulnerability.\n\nCompuware Topaz Utilities Plugin 1.0.9 requires the appropriate permissions to enumerate hosts and ports of Compuware configurations and credentials IDs.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/zephyr-enterprise-test-management-plugin", "repo": "jenkinsci/zephyr-enterprise-test-management-plugin", "url": "https://github.com/jenkinsci/zephyr-enterprise-test-management-plugin.git", "fix": "a2a698660c12d78e06f78c813c3ff10b4c30db16", "parent": "7d833b27eb41824523c39c468834c7889a055c0b", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-4p5r-2m5c-hvcc", "advisory_text": "Jenkins Zephyr Enterprise Test Management Plugin missing permission check\n\nA missing permission check in Jenkins Zephyr Enterprise Test Management Plugin in the ZeeDescriptor#doTestConnection form validation method allows attackers with Overall/Read permission to initiate a connection to an attacker-specified server.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "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" }, { "repository": "aws/aws-dynamodb-encryption-java", "repo": "aws/aws-dynamodb-encryption-java", "url": "https://github.com/aws/aws-dynamodb-encryption-java.git", "fix": "7de5f5a5929271ab25bce685089eb7ec564dac4b", "parent": "14c6a95bf91b3b301c1b4f621abb2c97f155bd09", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-w736-hf9p-qqh3", "advisory_text": "Key Caching behavior in the DynamoDB Encryption Client.\n\n### Impact\nThis advisory concerns users of MostRecentProvider in the DynamoDB Encryption Client with a key provider like AWS Key Management Service that allows for permissions on keys to be modified.\n\nWhen key usage permissions were changed at the key provider, time-based key reauthorization logic in MostRecentProvider did not reauthorize the use of the key. This created the potential for keys to be used in the DynamoDB Encryption Client after permissions to do so were revoked at the key provider.\n\n### Patches\nFixed as of 1.15.0. We recommend users to modify their code and adopt `CachingMostRecentProvider`.\n\n### Workarounds\nUsers who cannot upgrade to use the `CachingMostRecentProvider` can call `clear()` on the cache to manually flush all of its contents. Next use of the key will force a re-validation to occur with the key provider.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/oidc-provider-plugin", "repo": "jenkinsci/oidc-provider-plugin", "url": "https://github.com/jenkinsci/oidc-provider-plugin.git", "fix": "29fd614b36171048ddc78a995ce44bd12bd7997d", "parent": "f462a057cf7234277b270a56e93b2b61e0be50d3", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-q7c3-x7hm-qq72", "advisory_text": "Jenkins OpenID Connect Provider Plugin Incorrectly Validates Crafted Build ID Tokens\n\nIn Jenkins OpenID Connect Provider Plugin 96.vee8ed882ec4d and earlier the generation of build ID Tokens uses potentially overridden values of environment variables, in conjunction with certain other plugins allowing attackers able to configure jobs to craft a build ID Token that impersonates a trusted job, potentially gaining unauthorized access to external services.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "kimai/kimai", "repo": "kimai/kimai", "url": "https://github.com/kimai/kimai.git", "fix": "ff9acab0fc81f0e9490462739ef15fe4ab028ea5", "parent": "76e09447c85e762882126b49626a4fe4d93fe8b5", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-9w8f-7wgr-2h7g", "advisory_text": "kimai2 is vulnerable to Improper Access Control\n\nkimai2 is vulnerable to Improper Access Control", "ecosystem": "composer", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "jenkinsci/gitea-plugin", "repo": "jenkinsci/gitea-plugin", "url": "https://github.com/jenkinsci/gitea-plugin.git", "fix": "7555cb7c168cfa49d31271e7d65d76c1fab311f7", "parent": "7569bb8d7e7c94841a78a76500ef000cdebc95f5", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-q98c-rqx7-7ghf", "advisory_text": "Improper handling of untrusted branches in Gitea Jenkins Plugin\n\nJenkins Gitea Plugin prior to 1.1.2 did not implement trusted revisions, allowing attackers without commit access to the Git repo to change Jenkinsfiles even if Jenkins is configured to consider them to be untrusted.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "jenkinsci/compuware-topaz-for-total-test-plugin", "repo": "jenkinsci/compuware-topaz-for-total-test-plugin", "url": "https://github.com/jenkinsci/compuware-topaz-for-total-test-plugin.git", "fix": "0ba4274d545eac39e3db48b5dfb4512db3242946", "parent": "5fca6eb21599f8f27323dfa17a6e44f8176ca551", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-x5gv-5rqv-654m", "advisory_text": "Jenkins Compuware Topaz for Total Test Plugin allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins\n\nJenkins Compuware Topaz for Total Test Plugin 2.4.8 and earlier does not perform permission checks in several HTTP endpoints, allowing attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "apache/ozone", "repo": "apache/ozone", "url": "https://github.com/apache/ozone.git", "fix": "60e078729e18ef1be276f35659957ac553d266f7", "parent": "d054faa9b10f4c9ee323705d63abc1d28048da92", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-5993-wwpg-m92c", "advisory_text": "Apache Ozone user impersonation due to non-validation of Ozone S3 tokens\n\nIn Apache Ozone before 1.2.0, Authenticated users with valid Ozone S3 credentials can create specific OM requests, impersonating any other user.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/git-plugin", "repo": "jenkinsci/git-plugin", "url": "https://github.com/jenkinsci/git-plugin.git", "fix": "b46165c74a0bf15e08763de2e506005624d5d238", "parent": "18577d14afa2d1fbf970c44f60fce426d083073b", "family": "access_control", "cwe": "CWE-306", "advisory": "GHSA-449w-c77c-vmf6", "advisory_text": "Lack of authentication mechanism in Jenkins Git Plugin webhook\n\nGit Plugin provides a webhook endpoint at `/git/notifyCommit` that can be used to notify Jenkins of changes to an SCM repository. For its most basic functionality, this endpoint receives a repository URL, and Jenkins will schedule polling for all jobs configured with the specified repository. In Git Plugin 4.11.3 and earlier, this endpoint can be accessed with GET requests and without authentication. In addition to this basic functionality, the endpoint also accept a `sha1` parameter specifying a commit ID. If this parameter is specified, jobs configured with the specified repo will be triggered immediately, and the build will check out the specified commit. Additionally, the output of the webhook endpoint will provide information about which jobs were triggered or scheduled for polling, including jobs the user has no permission to access. This allows attackers with knowledge of Git repository URLs to trigger builds of jobs using a specified Git repository and to cause them to check out an attacker-specified commit, and to obtain information about the existence of jobs configured with this Git repository. Additionally, this webhook endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Git Plugin 4.11.4 requires a `token` parameter which will act as an authentication for the webhook endpoint. While GET requests remain allowed, attackers would need to be able to provide a webhook token. For more information see [the plugin documentation](https://github.com/jenkinsci/git-plugin/#push-notification-from-repository).", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "apache/seatunnel", "repo": "apache/seatunnel", "url": "https://github.com/apache/seatunnel.git", "fix": "53325aa3e76e3939f41a4bf3eaaf3ee56f13f311", "parent": "8a9db476bdc37d5e4079491bdb7092b892a17a7b", "family": "access_control", "cwe": "CWE-306", "advisory": "GHSA-9x53-gr7p-4qf5", "advisory_text": "Apache SeaTunnel: Unauthenticated insecure access\n\n# Summary\n\nUnauthorized users can perform Arbitrary File Read and Deserialization\nattack by submit job using restful api-v1.\n\n# Details\nUnauthorized users can access `/hazelcast/rest/maps/submit-job` to submit\njob.\nAn attacker can set extra params in mysql url to perform Arbitrary File\nRead and Deserialization attack.\n\nThis issue affects Apache SeaTunnel: <=2.3.10\n\n# Fixed\n\nUsers are recommended to upgrade to version 2.3.11, and enable restful api-v2 & open https two-way authentication , which fixes the issue.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "dromara/sa-token", "repo": "dromara/sa-token", "url": "https://github.com/dromara/Sa-Token.git", "fix": "954efeb73277f924f836da2a25322ea35ee1bfa3", "parent": "f2416a6175fd4dc30e98a82ddfd7ddcf89c7eb5a", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-54f6-9mx9-86f7", "advisory_text": "SaToken privilege escalation vulnerability\n\nAn issue in Dromara SaToken version 1.36.0 and before allows a remote attacker to escalate privileges via a crafted payload to the URL.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "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" }, { "repository": "jenkinsci/android-signing-plugin", "repo": "jenkinsci/android-signing-plugin", "url": "https://github.com/jenkinsci/android-signing-plugin.git", "fix": "33162c65c9f52ca5fa85609bdb652a5d1feda95b", "parent": "930cd584681e114fb1e2e3dbbbc9b39ad47d4cfd", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-vp68-fm96-7v79", "advisory_text": "Jenkins Android Signing Plugin allows attackers to check whether attacker-specified file patterns match workspace contents\n\nJenkins Android Signing Plugin 2.2.5 and earlier does not perform a permission check in a method implementing form validation.\n\nThis allows attackers with Item/Read permission but without Item/Workspace or Item/Configure permission to check whether attacker-specified file patterns match workspace contents. A sequence of requests can be used to effectively list workspace contents.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/jx-resources-plugin", "repo": "jenkinsci/jx-resources-plugin", "url": "https://github.com/jenkinsci/jx-resources-plugin.git", "fix": "f0d9fb76230b65e851095da936a439d953c5f64d", "parent": "520f0a91dd01f404d29cee07433635e43c474294", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-xqqr-mq8x-22qx", "advisory_text": "Jenkins JX Resources Plugin missing permission check\n\nJenkins jx-resources Plugin did not perform permission checks on a method implementing form validation. This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified Kubernetes server and obtain information about an attacker-specified namespace. Doing so might also leak service account credentials used for the connection. Additionally, it allowed attackers to obtain the value of any attacker-specified environment variable for the Jenkins controller process.\n\nAdditionally, this form validation method did not require POST requests, resulting in a cross-site request forgery vulnerability.\n\nThis form validation method now requires POST requests and Overall/Administer permissions.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/compuware-xpediter-code-coverage-plugin", "repo": "jenkinsci/compuware-xpediter-code-coverage-plugin", "url": "https://github.com/jenkinsci/compuware-xpediter-code-coverage-plugin.git", "fix": "2bb312d91f8dc20e7e1e2098584dbea65a9bffb6", "parent": "e506fc9e77a2609f6a5aa331e052d35be652071c", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-hxf7-9rv9-88v6", "advisory_text": "Jenkins Compuware Xpediter Code Coverage Plugin Missing Authorization\n\nJenkins Compuware Xpediter Code Coverage Plugin 1.0.7 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to enumerate hosts and ports of Compuware configurations and credentials IDs of credentials stored in Jenkins. Those credentials IDs can be used as part of an attack to capture the credentials using another vulnerability.\n\nCompuware Xpediter Code Coverage Plugin 1.0.8 requires the appropriate permissions to enumerate hosts and ports of Compuware configurations and credentials IDs.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/compuware-scm-downloader-plugin", "repo": "jenkinsci/compuware-scm-downloader-plugin", "url": "https://github.com/jenkinsci/compuware-scm-downloader-plugin.git", "fix": "bf00665b13641351a9f67027bbe34609cc4f65e2", "parent": "115f057078baad506e2b34b74f4f0600f81990b3", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-75fc-fv3p-xh82", "advisory_text": "Jenkins Compuware Source Code Download is missing authorization\n\nBMC Compuware Source Code Download for Endevor, PDS, and ISPW Plugin 2.0.12 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to enumerate hosts and ports of Compuware configurations and credentials IDs of credentials stored in Jenkins. Those credentials IDs can be used as part of an attack to capture the credentials using another vulnerability.\n\nBMC Compuware Source Code Download for Endevor, PDS, and ISPW Plugin 2.0.13 requires the appropriate permissions to enumerate hosts and ports of Compuware configurations and credentials IDs.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/support-core-plugin", "repo": "jenkinsci/support-core-plugin", "url": "https://github.com/jenkinsci/support-core-plugin.git", "fix": "9b7a1d48db0fdfb840ca3393e9462e687e69385b", "parent": "abaff0102139d9ec56ce3905f2ffef27649c88a4", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-w2j3-pq63-339w", "advisory_text": "Incorrect permission checks in Jenkins Support Core Plugin\n\nSupport Core Plugin defines the permission Support/DownloadBundle that allows users without Overall/Administer permission to create and download support bundles containing a limited set of diagnostic information.\n\nSupport Core Plugin 1206.v14049fa_b_d860 and earlier does not correctly perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Support/DownloadBundle permission to download a previously created support bundle containing information limited to users with Overall/Administer permission.\n\nSupport Core Plugin 1206.1208.v9b_7a_1d48db_0f deprecates the Support/DownloadBundle permission. The Overall/Administer permission is now required to download support bundles.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "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" }, { "repository": "apache/kafka", "repo": "apache/kafka", "url": "https://github.com/apache/kafka.git", "fix": "c000b1fae2bd7d4b76713a53508f128a13431ab6", "parent": "08b68583fa1042c9b9473e4dc9352a3b45c772fb", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-79vv-vp32-gpp7", "advisory_text": "Apache Kafka: Potential incorrect access control during migration from ZK mode to KRaft mode\n\nWhile an Apache Kafka cluster is being migrated from ZooKeeper mode to KRaft mode, in some cases ACLs will not be correctly enforced.\n\nTwo preconditions are needed to trigger the bug:\n1. The administrator decides to remove an ACL\n2. The resource associated with the removed ACL continues to have two or more other ACLs associated with it after the removal.\n\nWhen those two preconditions are met, Kafka will treat the resource as if it had only one ACL associated with it after the removal, rather than the two or more that would be correct.\n\nThe incorrect condition is cleared by removing all brokers in ZK mode, or by adding a new ACL to the affected resource. Once the migration is completed, there is no metadata loss (the ACLs all remain).\n\nThe full impact depends on the ACLs in use. If only ALLOW ACLs were configured during the migration, the impact would be limited to availability impact. if DENY ACLs were configured, the impact could include confidentiality and integrity impact depending on the ACLs configured, as the DENY ACLs might be ignored due to this vulnerability during the migration period.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "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" }, { "repository": "jenkinsci/jiratestresultreporter-plugin", "repo": "jenkinsci/jiratestresultreporter-plugin", "url": "https://github.com/jenkinsci/JiraTestResultReporter-plugin.git", "fix": "0cc6208295b5cb683528e8bf04d139f0bee8eb53", "parent": "81792855394237a2f78b06f509985a894ac5c008", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-gc7m-x2cj-3775", "advisory_text": "Missing permission check in Jenkins JiraTestResultReporter Plugin\n\nA missing permission check in Jenkins JiraTestResultReporter Plugin 165.v817928553942 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/hashicorp-vault-plugin", "repo": "jenkinsci/hashicorp-vault-plugin", "url": "https://github.com/jenkinsci/hashicorp-vault-plugin.git", "fix": "3b38d767aba8bd98d6f4fb53c1f1678d95b5e752", "parent": "db858fd6bf48b0784598b8f1b12d006c8d6dec98", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-vpf7-q2rx-26mh", "advisory_text": "Jenkins HashiCorp Vault Plugin does not perform permission checks in several HTTP endpoints that perform Vault connection tests\n\nA missing permission check in Jenkins HashiCorp Vault Plugin 354.vdb_858fd6b_f48 and earlier allows attackers with Overall/Read permission to obtain credentials stored in Vault with attacker-specified path and keys.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/mabl-integration-plugin", "repo": "jenkinsci/mabl-integration-plugin", "url": "https://github.com/jenkinsci/mabl-integration-plugin.git", "fix": "4e21f498b0704d62f5a6114fcd8c274a5f440b18", "parent": "61281f28815b3e05ca3d156f5b080fdde34ba1df", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-m9jj-p947-m8xv", "advisory_text": "Jenkins mabl Plugin missing permission check\n\nJenkins mabl Plugin 0.0.46 and earlier does not perform permission checks in several HTTP endpoints.\n\nThis allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.\n\nAdditionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.\n\nmabl Plugin 0.0.47 requires POST requests and the appropriate permissions for the affected HTTP endpoints.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/kubernetes-credentials-provider-plugin", "repo": "jenkinsci/kubernetes-credentials-provider-plugin", "url": "https://github.com/jenkinsci/kubernetes-credentials-provider-plugin.git", "fix": "862c6e5fb1ef65968ebfa399239cbef4fff7afc6", "parent": "128ee9800c048d89c334f901a9671608e1218e4e", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-2jpx-h8j2-g8m4", "advisory_text": "Exposure of system-scoped Kubernetes credentials in Jenkins Kubernetes Credentials Provider Plugin\n\nJenkins Kubernetes Credentials Provider Plugin 1.208.v128ee9800c04 and earlier does not set the appropriate context for Kubernetes credentials lookup, allowing attackers with Item/Configure permission to access and potentially capture Kubernetes credentials they are not entitled to.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/deployer-framework-plugin", "repo": "jenkinsci/deployer-framework-plugin", "url": "https://github.com/jenkinsci/deployer-framework-plugin.git", "fix": "7ba4a55bf3ec567ee5325ea7b24b4086ac1cb3ad", "parent": "1d1888e8c0214fa42ee932b3eb26c06a6c7279f0", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-rqqx-fvqx-539g", "advisory_text": "Jenkins Deployer Framework Plugin allows attackers with Item/Read permission to read deployment logs\n\nJenkins Deployer Framework Plugin 85.v1d1888e8c021 and earlier does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Item/Read permission to read deployment logs.\n\nDeployer Framework Plugin 86.v7b_a_4a_55b_f3ec requires Deploy Now/Deploy permission to read deployment logs.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/nomad-plugin", "repo": "jenkinsci/nomad-plugin", "url": "https://github.com/jenkinsci/nomad-plugin.git", "fix": "93ea215a649575e4063e1dfe8361b684c29a91e3", "parent": "fe2cc9498561b357c7b1a17fc3b76a492abff755", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-p278-2qh9-6mwj", "advisory_text": "Jenkins Nomad Plugin missing permission check\n\nA missing permission check in Jenkins Nomad Plugin in the NomadCloud.DescriptorImpl#doTestConnection form validation method allows attackers with Overall/Read permission to initiate a connection to an attacker-specified server.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "apache/shenyu", "repo": "apache/shenyu", "url": "https://github.com/apache/shenyu.git", "fix": "9a02215013037e1cc8cd41f216164628a9e9e28f", "parent": "6ca007400ebd17eabc2769573c081652cecdf134", "family": "access_control", "cwe": "CWE-306", "advisory": "GHSA-7rjp-fgwj-47rw", "advisory_text": "Missing authentication in ShenYu\n\nMissing authentication on ShenYu Admin when register by HTTP. This issue affected Apache ShenYu 2.4.0 and 2.4.1.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "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" }, { "repository": "jenkinsci/global-build-stats-plugin", "repo": "jenkinsci/global-build-stats-plugin", "url": "https://github.com/jenkinsci/global-build-stats-plugin.git", "fix": "32aeb0493c4ff5423448576f477ac612f7a25138", "parent": "6478447abafa3d984bdfb4f73a358b68a97bdcf3", "family": "access_control", "cwe": "CWE-284", "advisory": "GHSA-gm8g-fh49-qq6v", "advisory_text": "Jenkins global-build-stats Plugin missing permission check can result in graph IDs being enumerated\n\nJenkins global-build-stats Plugin 322.v22f4db_18e2dd and earlier does not perform permission checks in its REST API endpoints, allowing attackers with Overall/Read permission to enumerate graph IDs. \n\nThis has been patched in version 347.v32a_eb_0493c4f.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/cloudfoundry-plugin", "repo": "jenkinsci/cloudfoundry-plugin", "url": "https://github.com/jenkinsci/cloudfoundry-plugin.git", "fix": "61208697f60b91ad7f03a4dcec391b6d2115abca", "parent": "4ab76d590f48ec42342c113cb2653d20ccdfb5f0", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-2mh9-wpgv-7xr8", "advisory_text": "Jenkins Cloud Foundry Plugin vulnerable to exposure of sensitive information\n\n\\Jenkins Cloud Foundry Plugin did not perform permission checks on a method implementing form validation. This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.\n\nAdditionally, this form validation method did not require POST requests, resulting in a cross-site request forgery vulnerability.\n\nThis form validation method now requires POST requests and Overall/Administer (for global configuration) or Item/Configure permissions (for job configuration).", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/groovy-plugin", "repo": "jenkinsci/groovy-plugin", "url": "https://github.com/jenkinsci/groovy-plugin.git", "fix": "212e048a319ae32dad4cfec5e73a885a9f4781f0", "parent": "da0739d3507c5973d506d18efbda33ad5e37893b", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-xfwj-2f34-32f5", "advisory_text": "Jenkins Groovy Plugin sandbox bypass vulnerability\n\nA sandbox bypass vulnerability exists in Jenkins Groovy Plugin 2.0 and earlier in `src/main/java/hudson/plugins/groovy/StringScriptSource.java` that allows attackers with Overall/Read permission to provide a Groovy script to an HTTP endpoint that can result in arbitrary code execution on the Jenkins master JVM. In version 2.1, the affected HTTP endpoint applies a safe Groovy compiler configuration preventing the use of unsafe AST transforming annotations.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/rocketchatnotifier-plugin", "repo": "jenkinsci/rocketchatnotifier-plugin", "url": "https://github.com/jenkinsci/rocketchatnotifier-plugin.git", "fix": "1a0023be9f2e143434d028d5292ef9dc3195d051", "parent": "14cdaa96d98d6d65fbefde1103a04bc478edf415", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-4p8f-2fwv-6xcw", "advisory_text": "Missing permission check in Jenkins RocketChat Notifier Plugin\n\nJenkins RocketChat Notifier Plugin 1.4.10 and earlier does not perform a permission check in a method implementing form validation.\n\nThis allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials.\n\nAdditionally, this form validation method does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.\n\nRocketChat Notifier Plugin 1.5.0 requires POST requests and Overall/Administer permission for the affected form validation method.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "apache/artemis", "repo": "apache/artemis", "url": "https://github.com/apache/artemis.git", "fix": "cfb585eaf61d570eecd65c6ad0e92282df7d3869", "parent": "f154c0b7ddc63bdfb908ed6a0ad0c25217489b74", "family": "access_control", "cwe": "CWE-285", "advisory": "GHSA-443j-grxv-2pgv", "advisory_text": "Apache ActiveMQ Artemis: Authenticated users could perform RCE via Jolokia MBeans\n\nApache ActiveMQ Artemis allows access to diagnostic information and controls through MBeans, which are also exposed through the authenticated Jolokia endpoint. Before version 2.29.0, this also included the Log4J2 MBean. This MBean is not meant for exposure to non-administrative users. This could eventually allow an authenticated attacker to write arbitrary files to the filesystem and indirectly achieve RCE.\n\n\nUsers are recommended to upgrade to version 2.29.0 or later, which fixes the issue.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/analysis-core-plugin", "repo": "jenkinsci/analysis-core-plugin", "url": "https://github.com/jenkinsci/analysis-core-plugin.git", "fix": "3d7a0c7907d831c58541508b893dcea2039809c5", "parent": "892ab94f85a49d8c04b302c9bf48b112efe97536", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-vvfj-p4jf-j8rm", "advisory_text": "Missing permission check in Jenkins Static Analysis Utilities Plugin\n\nA missing permission check in Jenkins Static Analysis Utilities Plugin 1.95 and earlier in the DefaultGraphConfigurationView#doSave form handler method allowed attackers with Overall/Read permission to change the per-job default graph configuration for all users.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/blueocean-plugin", "repo": "jenkinsci/blueocean-plugin", "url": "https://github.com/jenkinsci/blueocean-plugin.git", "fix": "659a66aff0d0ad693eab9d2807985d591e102aab", "parent": "966da5a824c0e78767ba8b6a40be2ebfd8d8919f", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-vc7g-4269-f7hw", "advisory_text": "Missing permission check in Blue Ocean Plugin\n\n### Updated 2020-09-16\nThis entry previously misidentified the problematic behavior. The HTTP request itself is legitimate, but only authorized users should be able to perform it.\n\n### Original Description\nBlue Ocean Plugin 1.23.2 and earlier does not perform permission checks in several HTTP endpoints implementing connection tests.\n\nThis allows attackers with Overall/Read permission to connect to an attacker-specified URL.\n\nBlue Ocean Plugin 1.23.3 requires Item/Create permission to perform these connection tests.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "beobal/cassandra", "repo": "beobal/cassandra", "url": "https://github.com/beobal/cassandra.git", "fix": "28ee665b3c0c9238b61a871064f024d54cddcc79", "parent": "6b00767427706124e016e4f471c2266899387163", "family": "access_control", "cwe": "CWE-306", "advisory": "GHSA-52gq-7j6c-xw6x", "advisory_text": "Missing Authentication for Critical Function in Apache Cassandra\n\nThe default configuration in Apache Cassandra 3.8 through 3.11.1 binds an unauthenticated JMX/RMI interface to all network interfaces, which allows remote attackers to execute arbitrary Java code via an RMI request. This issue is a regression of CVE-2015-0225. The regression was introduced in https://issues.apache.org/jira/browse/CASSANDRA-12109. The fix for the regression is implemented in https://issues.apache.org/jira/browse/CASSANDRA-14173. This fix is contained in the 3.11.2 release of Apache Cassandra.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "jenkinsci/opentelemetry-plugin", "repo": "jenkinsci/opentelemetry-plugin", "url": "https://github.com/jenkinsci/opentelemetry-plugin.git", "fix": "f5a4ec123769096ad9a4930ede56588b0fee40f3", "parent": "26675a20647122918cb1cf154470e7e71ff1882f", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-f696-867g-2759", "advisory_text": "Jenkins OpenTelemetry Plugin missing permission check allows capturing credentials\n\nA missing permission check in Jenkins OpenTelemetry Plugin 3.1543.v8446b_92b_cd64 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.", "ecosystem": "maven", "license_spdx": "Apache-2.0", "origin": "osv" }, { "repository": "karlamoe/unsafe-accessor", "repo": "karlamoe/unsafe-accessor", "url": "https://github.com/karlamoe/unsafe-accessor.git", "fix": "4ef83000184e8f13239a1ea2847ee401d81585fd", "parent": "971c479496c38c89f6201ee73c108d2a342a9a5a", "family": "access_control", "cwe": "CWE-863", "advisory": "GHSA-cr6p-23cf-w9g9", "advisory_text": "UnsafeAccessor 1.4.0 until 1.7.0 has no security checking for UnsafeAccess.getInstance()\n\n### Overview\n\nAffected versions have no limit to using unsafe-accessor. Can be ignored if `SecurityCheck.AccessLimiter` not setup\n\n### Details\n\nIf UA was loaded as a named module, the internal data of UA will be protected by JVM and others can only access UA via UA's standard api.\nMain application can setup `SecurityCheck.AccessLimiter` for UA to limit accesses to UA.\nUntrusted code can access UA without lmitation in affected versions even UA was loaded as a named module.\n\n### References\n\n[The commit to fix](https://github.com/Karlatemp/UnsafeAccessor/commit/4ef83000184e8f13239a1ea2847ee401d81585fd)", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "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" }, { "repository": "jenkinsci/ec2-plugin", "repo": "jenkinsci/ec2-plugin", "url": "https://github.com/jenkinsci/ec2-plugin.git", "fix": "0cdbaf2d7da5c368209f427559c8608dec22a63b", "parent": "2af0a6da84ef203c463981afbd81da0c0b1b5364", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-6hmm-77r2-h6hr", "advisory_text": "Missing permission checks in Jenkins Amazon EC2 Plugin\n\nAmazon EC2 Plugin 1.47 and earlier does not perform permission checks in methods performing form validation. This allows users with Overall/Read access to Jenkins to connect to an attacker-specified URL within the AWS region using attacker-specified credentials IDs obtained through another method.\n\nThis vulnerability might also allow attackers to capture credentials stored in Jenkins. We have not been able to confirm that this is possible.\n\nAdditionally, these form validation methods do not require POST requests, resulting in a CSRF vulnerability.\n\nAmazon EC2 Plugin 1.48 requires POST requests and Overall/Administer permission for the affected form validation methods.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" }, { "repository": "jenkinsci/cloud-stats-plugin", "repo": "jenkinsci/cloud-stats-plugin", "url": "https://github.com/jenkinsci/cloud-stats-plugin.git", "fix": "07dd3da346a65083a93a071036409f1128e0b133", "parent": "6c75484141e98af5c22b0ae6000ccbdf15c6e5e7", "family": "access_control", "cwe": "CWE-862", "advisory": "GHSA-xv69-6rf3-w5g2", "advisory_text": "Missing permission check in Jenkins Cloud Statistics Plugin\n\nJenkins Cloud Statistics Plugin 0.26 and earlier does not perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Overall/Read permission and knowledge of random activity IDs to view related provisioning exception error messages.\n\nJenkins Cloud Statistics Plugin 0.27 requires Overall/Administer permission to access provisioning exception error messages.", "ecosystem": "maven", "license_spdx": "MIT", "origin": "osv" } ]