ghsa

A path traversal vulnerability accessible via MediaController's download_private_file method allows authenticated users to download any file on the web server Camaleon CMS is running on (depending on the file permissions). In the [download_private_file](https://github.com/owen2345/camaleon-cms/blob/feccb96e542319ed608acd3a16fa5d92f13ede67/app/controllers/camaleon_cms/admin/media_controller.rb#L28) method: ```ruby def download_private_file cama_uploader.enable_private_mode! file = cama_uploader.fetch_file("private/#{params[:file]}") send_file file, disposition: 'inline' end ``` The file parameter is passed to the [fetch_file](https://github.com/owen2345/camaleon-cms/blob/feccb96e542319ed608acd3a16fa5d92f13ede67/app/uploaders/camaleon_cms_local_uploader.rb#L27) method of the CamaleonCmsLocalUploader class (when files are uploaded locally): ```ruby def fetch_file(file_name) raise ActionController::RoutingError, 'File not found' unless file_exists?(file_name) file_name end ``...

An arbitrary code execution vulnerability exists in versions 0.2.9 up to 0.5.10 of the Guardrails AI Guardrails framework because of the way it validates XML files. If a victim user loads a maliciously crafted XML file containing Python code, the code will be passed to an eval function, causing it to execute on the user's machine.

An issue was discovered in CoreDNS through 1.10.1. There is a vulnerability in DNS resolving software, which triggers a resolver to ignore valid responses, thus causing denial of service for normal resolution. In an exploit, the attacker could just forge a response targeting the source port of a vulnerable resolver without the need to guess the correct TXID.

Insecure deserialization in sqlitedict up to v2.1.0 allows attackers to execute arbitrary code.

An arbitrary file write vulnerability accessible via the upload method of the MediaController allows authenticated users to write arbitrary files to any location on the web server Camaleon CMS is running on (depending on the permissions of the underlying filesystem). E.g. This can lead to a delayed remote code execution in case an attacker is able to write a Ruby file into the config/initializers/ subfolder of the Ruby on Rails application. Once a user upload is started via the [upload](https://github.com/owen2345/camaleon-cms/blob/feccb96e542319ed608acd3a16fa5d92f13ede67/app/controllers/camaleon_cms/admin/media_controller.rb#L86-L87) method, the file_upload and the folder parameter ```ruby def upload(settings = {}) params[:dimension] = nil if params[:skip_auto_crop].present? f = { error: 'File not found.' } if params[:file_upload].present? f = upload_file(params[:file_upload], { folder: params[:folder], dimension: params['dimension'], formats: params[:fo...

### Impact It's possible to get access to notification filters of any user by using a URL such as `<hostname>xwiki/bin/get/XWiki/Notifications/Code/NotificationFilterPreferenceLivetableResults?outputSyntax=plain&type=custom&user=<username>`. This vulnerability impacts all versions of XWiki since 13.2-rc-1. The filters do not provide much information (they mainly contain references which are public data in XWiki), though some info could be used in combination with other vulnerabilities. ### Patches The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0RC1. The patch consists in checking the rights of the user when sending the data. ### Workarounds It's possible to workaround the vulnerability by applying manually the patch: it's possible for an administrator to edit directly the document `XWiki.Notifications.Code.NotificationFilterPreferenceLivetableResults` to apply the same changes as in the patch. See c8c6545f9bde6f5aade994aa5b5903a67b5c2582. ### Reference...

### Impact It's possible for any user knowing the ID of a notification filter preference of another user, to enable/disable it or even delete it. The impact is that the target user might start loosing notifications on some pages because of this. This vulnerability is present in XWiki since 13.2-rc-1. ### Patches The vulnerability has been patched in XWiki 14.10.21, 15.5.5, 15.10.1, 16.0-rc-1. The patch consists in checking properly the rights of the user before performing any action on the filters. ### Workarounds It's possible to fix manually the vulnerability by editing the document `XWiki.Notifications.Code.NotificationPreferenceService` to apply the changes performed in this commit e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20337 * Commit: e8acc9d8e6af7dfbfe70716ded431642ae4a6dd4 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https...

If an attacker launches many login attempts in parallel then the attacker can have more guesses at a password than the brute force protection configuration permits. This is due to the brute force check occurring before the brute force protector has locked the user. **Acknowledgements:** Special thanks to Maurizio Agazzini for reporting this issue and helping us improve our project.

### Impact By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a `Cache-Control: s-maxage=1, stale-while-revalidate` header which some upstream CDNs may cache as well. To be potentially affected all of the following must apply: - Next.js between 13.5.1 and 14.2.9 - Using pages router - Using non-dynamic server-side rendered routes e.g. `pages/dashboard.tsx` not `pages/blog/[slug].tsx` The below configurations are unaffected: - Deployments using only app router - Deployments on [Vercel](https://vercel.com/) are not affected ### Patches This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not. ### Workarounds There are no official or recommended work...

### Summary Under the default configuration, Devise-Two-Factor versions >= 2.2.0 & < 6.0.0 generate TOTP shared secrets that are 120 bits instead of the 128-bit minimum defined by [RFC 4226](https://datatracker.ietf.org/doc/html/rfc4226). Using a shared secret shorter than the minimum to generate a multi-factor authentication code could make it easier for an attacker to guess the shared secret and generate valid TOTP codes. ### Remediation Devise-Two-Factor should be upgraded to version v6.0.0 as soon as possible. After upgrading, the length of shared secrets and TOTP URLs generated by the library will increase since the new shared secrets will be longer. If upgrading is not possible, you can override the default `otp_secret_length` attribute in the model when configuring `two_factor_authenticable` and set it to a value of at least 26 to ensure newly generated shared secrets are at least 128-bits long. After upgrading or implementing the workaround, applications using Devise-Two-Fac...