From 0a1e23bb04d72fcb5352902567f350ac8c6bb8b6 Mon Sep 17 00:00:00 2001 From: Al Snow <43523+jasnow@users.noreply.github.com> Date: Tue, 17 Mar 2026 10:05:52 -0400 Subject: [PATCH] GHSA/SYNC: 4 brand new advisories --- gems/action_text-trix/GHSA-qmpg-8xg6-ph5q.yml | 39 ++++++++++++ gems/camaleon_cms/CVE-2026-1776.yml | 34 +++++++++++ gems/devise/GHSA-57hq-95w6-v4fc.yml | 60 +++++++++++++++++++ gems/sigstore/CVE-2026-31830.yml | 56 +++++++++++++++++ 4 files changed, 189 insertions(+) create mode 100644 gems/action_text-trix/GHSA-qmpg-8xg6-ph5q.yml create mode 100644 gems/camaleon_cms/CVE-2026-1776.yml create mode 100644 gems/devise/GHSA-57hq-95w6-v4fc.yml create mode 100644 gems/sigstore/CVE-2026-31830.yml diff --git a/gems/action_text-trix/GHSA-qmpg-8xg6-ph5q.yml b/gems/action_text-trix/GHSA-qmpg-8xg6-ph5q.yml new file mode 100644 index 0000000000..835037f539 --- /dev/null +++ b/gems/action_text-trix/GHSA-qmpg-8xg6-ph5q.yml @@ -0,0 +1,39 @@ +--- +gem: action_text-trix +ghsa: qmpg-8xg6-ph5q +url: https://github.com/basecamp/trix/security/advisories/GHSA-qmpg-8xg6-ph5q +title: Trix has a Stored XSS vulnerability through serialized attributes +date: 2026-03-12 +description: | + ### Impact + + The Trix editor, in versions prior to 2.1.17, is vulnerable to XSS + attacks when a `data-trix-serialized-attributes` attribute bypasses + the DOMPurify sanitizer. + + An attacker could craft HTML containing a `data-trix-serialized-attributes` + attribute with a malicious payload that, when the content is rendered, + could execute arbitrary JavaScript code within the context of the + user's session, potentially leading to unauthorized actions being + performed or sensitive information being disclosed. + + ### Patches + + Update Recommendation + + Users should upgrade to Trix editor version 2.1.17 or later. + + ### References + + The XSS vulnerability was responsibly reported by Hackerone + researcher [newbiefromcoma](https://hackerone.com/newbiefromcoma). +cvss_v3: 4.6 +patched_versions: + - ">= 2.1.17" +related: + url: + - https://github.com/basecamp/trix/security/advisories/GHSA-qmpg-8xg6-ph5q + - https://github.com/basecamp/trix/releases/tag/v2.1.17 + - https://github.com/basecamp/trix/pull/1282 + - https://github.com/basecamp/trix/commit/53197ab5a142e6b0b76127cb790726b274eaf1bc + - https://github.com/advisories/GHSA-qmpg-8xg6-ph5q diff --git a/gems/camaleon_cms/CVE-2026-1776.yml b/gems/camaleon_cms/CVE-2026-1776.yml new file mode 100644 index 0000000000..1009ced182 --- /dev/null +++ b/gems/camaleon_cms/CVE-2026-1776.yml @@ -0,0 +1,34 @@ +--- +gem: camaleon_cms +cve: 2026-1776 +ghsa: jw5g-f64p-6x78 +url: https://nvd.nist.gov/vuln/detail/CVE-2026-1776 +title: Camaleon CMS vulnerable to Path Traversal through + AWS S3 uploader implementation +date: 2026-03-10 +description: | + Camaleon CMS versions 2.4.5.0 through 2.9.1, prior to commit f54a77e, + contain a path traversal vulnerability in the AWS S3 uploader + implementation that allows authenticated users to read arbitrary + files from the web server’s filesystem. The issue occurs in the + download_private_file functionality when the application is + configured to use the CamaleonCmsAwsUploader backend. Unlike the + local uploader implementation, the AWS uploader does not validate + file paths with valid_folder_path?, allowing directory traversal + sequences to be supplied via the file parameter. As a result, any + authenticated user, including low-privileged registered users, can + access sensitive files such as /etc/passwd. This issue represents a + bypass of the incomplete fix for CVE-2024-46987 and affects + deployments using the AWS S3 storage backend. +cvss_v4: 6.0 +unaffected_versions: + - "< 2.4.5.0" +notes: 'Never patched; last release was 2.9.1' +related: + url: + - https://nvd.nist.gov/vuln/detail/CVE-2026-1776 + - https://github.com/owen2345/camaleon-cms/pull/1127 + - https://github.com/owen2345/camaleon-cms/commit/f54a77e2a7be601215ea1b396038c589a0cab9af + - https://camaleon.website + - https://www.vulncheck.com/advisories/camaleon-cms-aws-uploader-authenticated-path-traversal-arbitrary-file-read + - https://github.com/advisories/GHSA-jw5g-f64p-6x78 diff --git a/gems/devise/GHSA-57hq-95w6-v4fc.yml b/gems/devise/GHSA-57hq-95w6-v4fc.yml new file mode 100644 index 0000000000..9e52759d9b --- /dev/null +++ b/gems/devise/GHSA-57hq-95w6-v4fc.yml @@ -0,0 +1,60 @@ +--- +gem: devise +ghsa: 57hq-95w6-v4fc +url: https://github.com/heartcombo/devise/security/advisories/GHSA-57hq-95w6-v4fc +title: Confirmable "change email" race condition permits + user to confirm email they have no access to +date: 2026-03-16 +description: | + ## Impact + + A race condition in Devise's Confirmable module allows an attacker + to confirm an email address they do not own. This affects any Devise + application using the reconfirmable option (the default when using + Confirmable with email changes). + + By sending two concurrent email change requests, an attacker can + desynchronize the confirmation_token and unconfirmed_email fields. + The confirmation token is sent to an email the attacker controls, + but the unconfirmed_email in the database points to a victim's + email address. When the attacker uses the token, the victim's email + is confirmed on the attacker's account. + + ## Patch + + This is patched in Devise v5.0.3. Users should upgrade as soon as possible. + + ## Workaround + + Applications can override this specific method from Devise models + to force unconfirmed_email to be persisted when unchanged: + (assuming your model is User) + + ``` + class User < ApplicationRecord + protected + + def postpone_email_change_until_confirmation_and_regenerate_confirmation_token + unconfirmed_email_will_change! + super + end + end + ``` + + Note: Mongoid does not seem to respect that will_change! should + force the attribute to be persisted, even if it did not really + change, so you might have to implement a workaround similar to + Devise by setting changed_attributes["unconfirmed_email"] = nil as well. +patched_versions: + - ">= 5.0.3" +related: + url: + - https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released + - https://github.com/heartcombo/devise/pull/5784 + - https://github.com/heartcombo/devise/issues/5783 + - https://portswigger.net/research/smashing-the-state-machine + - https://groups.google.com/g/heartcombo/c/ieiLJhG4EGE/m/PNlIQv54AAAJ + - https://groups.google.com/g/heartcombo/c/o9mtkcfvt_g/m/SABX6rp8AgAJ + - https://groups.google.com/g/heartcombo/c/XDII89RV6Ak/m/AJMOyayNAgAJ + - https://groups.google.com/g/heartcombo/c/TWge7vKELhc/m/gRTrgKz4CQAJ + - https://github.com/heartcombo/devise/security/advisories/GHSA-57hq-95w6-v4fc diff --git a/gems/sigstore/CVE-2026-31830.yml b/gems/sigstore/CVE-2026-31830.yml new file mode 100644 index 0000000000..6cafcbd124 --- /dev/null +++ b/gems/sigstore/CVE-2026-31830.yml @@ -0,0 +1,56 @@ +--- +gem: sigstore +cve: 2026-31830 +ghsa: mhg6-2q2v-9h2c +url: https://github.com/sigstore/sigstore-ruby/security/advisories/GHSA-mhg6-2q2v-9h2c +title: sigstore-ruby verifier returns success for DSSE bundles + with mismatched in-toto subject digest +date: 2026-03-11 +description: | + ### Summary + + `Sigstore::Verifier#verify` does not propagate the `VerificationFailure` + returned by `verify_in_toto` when the artifact digest does not match + the digest in the in-toto attestation subject. As a result, verification + of DSSE bundles containing in-toto statements returns `VerificationSuccess` + regardless of whether the artifact matches the attested subject. + + ### Details + + In `lib/sigstore/verifier.rb`, the verify method calls `verify_in_toto` + (line 176) without capturing or checking its return value: + + `verify_in_toto(input, in_toto)` + + When `verify_in_toto` detects a digest mismatch, it returns a + `VerificationFailure` object. Because the caller discards this + return value, execution unconditionally falls through to return + `VerificationSuccess`. This is the only verification sub-check in + the method (out of 12) whose failure is not propagated. + + The message_signature code path is not affected. + + ### Impact + + An attacker who possesses a valid signed DSSE bundle containing an + in-toto attestation for artifact A can present it as a valid attestation + for a different artifact B. All other verification checks (DSSE envelope + signature, certificate chain, Rekor inclusion, SCTs, policy) pass because + they are independent of the artifact content. Only the in-toto subject + digest check detects the mismatch, and its result is discarded. + + This allows an attacker to bypass artifact-to-attestation binding for + any consumer that relies on `Sigstore::Verifier#verify` to validate + DSSE/in-toto bundles. + + ### Workarounds + + None. Consumers cannot work around this without patching the library. +cvss_v3: 7.5 +patched_versions: + - ">= 0.2.3" +related: + url: + - https://nvd.nist.gov/vuln/detail/CVE-2026-31830 + - https://github.com/sigstore/sigstore-ruby/security/advisories/GHSA-mhg6-2q2v-9h2c + - https://github.com/advisories/GHSA-mhg6-2q2v-9h2c