Skip to content

Commit 48a80b7

Browse files
jasnowjasnow
committed
Redid work
2 parents 75881cb + 90e2384 commit 48a80b7

29 files changed

+893
-19
lines changed

‎gems/activejob/GHSA-mpwp-4h2m-765c.yml‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,6 @@ related:
2121
url:
2222
- https://advisories.gitlab.com/pkg/gem/activejob/OSVDB-112347
2323
- https://rubyonrails.org/2014/9/29/Rails-4-2-0-beta2-has-been-released
24-
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activejob/OSVDB-112347.yml
2524
- https://advisories.gitlab.com/pkg/gem/activejob/GHSA-mpwp-4h2m-765c
2625
- https://github.com/advisories/GHSA-mpwp-4h2m-765c
2726
notes: |

‎gems/activerecord/CVE-2013-3221.yml‎

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
---
2+
gem: activerecord
3+
framework: rails
4+
cve: 2013-3221
5+
ghsa: f57c-hx33-hvh8
6+
url: https://nvd.nist.gov/vuln/detail/CVE-2013-3221
7+
title: Data-type injection vulnerability
8+
date: 2013-04-21
9+
description: |
10+
The Active Record component in Ruby on Rails 2.3.x, 3.0.x, 3.1.x,
11+
and 3.2.x does not ensure that the declared data type of a database
12+
column is used during comparisons of input values to stored values
13+
in that column, which makes it easier for remote attackers to
14+
conduct data-type injection attacks against Ruby on Rails applications
15+
via a crafted value, as demonstrated by unintended interaction
16+
between the "typed XML" feature and a MySQL database.
17+
18+
## RELEASE INFO
19+
- Phrack writeup says that 'couple of days after the advisory the
20+
issue was "fixed" in Rails 3.2.12 as by the following commit' 921a296.
21+
But "Indeed the vector is completely fixed as of Rails 4.2 almost
22+
two years after the original advisory."
23+
cvss_v2: 6.4
24+
patched_versions:
25+
- ">= 4.2.0"
26+
related:
27+
url:
28+
- https://nvd.nist.gov/vuln/detail/CVE-2013-3221
29+
- https://github.com/rails/rails/commit/c9909db9f2f81575ef2ea2ed3b4e8743c8d6f1b9
30+
- https://github.com/rails/rails/commit/921a296a3390192a71abeec6d9a035cc6d1865c8
31+
- https://groups.google.com/group/rubyonrails-security/msg/1f3bc0b88a60c1ce
32+
- http://pl.reddit.com/r/netsec/comments/17yajp/mysql_madness_and_rails
33+
- http://openwall.com/lists/oss-security/2013/02/06/7
34+
- http://openwall.com/lists/oss-security/2013/04/24/7
35+
- https://gist.github.com/marianposaceanu/5442275
36+
- https://web.archive.org/web/20160307143147/http://www.phenoelit.org/blog/archives/2013/02/index.html
37+
- https://github.com/advisories/GHSA-f57c-hx33-hvh8
38+
- https://phrack.org/issues/69/12

‎gems/alchemy_cms/CVE-2026-23885.yml‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
gem: alchemy_cms
3+
cve: 2026-23885
4+
ghsa: 2762-657x-v979
5+
url: https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-2762-657x-v979
6+
title: AlchemyCMS - Authenticated Remote Code Execution (RCE) via
7+
eval injection in ResourcesHelper
8+
date: 2026-01-21
9+
description: |
10+
### Summary
11+
12+
A vulnerability was discovered during a manual security audit
13+
of the AlchemyCMS source code. The application uses the Ruby
14+
`eval()` function to dynamically execute a string provided by the
15+
`resource_handler.engine_name` attribute in
16+
`Alchemy::ResourcesHelper#resource_url_proxy`.
17+
18+
### Details
19+
20+
The vulnerability exists in `app/helpers/alchemy/resources_helper.rb`
21+
at line 28. The code explicitly bypasses security linting with
22+
`# rubocop:disable Security/Eval`, indicating that the use of a
23+
dangerous function was known but not properly mitigated.
24+
25+
Since `engine_name` is sourced from module definitions that can be
26+
influenced by administrative configurations, it allows an authenticated
27+
attacker to escape the Ruby sandbox and execute arbitrary system
28+
commands on the host OS.
29+
30+
But, for this attack to be possible local file access to the alchemy
31+
project or the source on a remote server is necessary in order to
32+
manipulate the module config file, though.
33+
cvss_v3: 6.6
34+
patched_versions:
35+
- "~> 7.4.12"
36+
- ">= 8.0.3"
37+
related:
38+
url:
39+
- https://nvd.nist.gov/vuln/detail/CVE-2026-23885
40+
- https://github.com/AlchemyCMS/alchemy_cms/security/advisories/GHSA-2762-657x-v979
41+
- https://github.com/AlchemyCMS/alchemy_cms/commit/55d03ec600fd9e07faae1138b923790028917d26
42+
- https://github.com/AlchemyCMS/alchemy_cms/commit/563c4ce45bf5813b7823bf3403ca1fc32cb769e7
43+
- https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v7.4.12
44+
- https://github.com/AlchemyCMS/alchemy_cms/releases/tag/v8.0.3
45+
- https://github.com/advisories/GHSA-2762-657x-v979

‎gems/decidim-core/CVE-2025-65017.yml‎

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
---
2+
gem: decidim-core
3+
cve: 2025-65017
4+
ghsa: 3cx6-j9j4-54mp
5+
url: https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp
6+
title: Decidim's private data exports can lead to data leaks
7+
date: 2026-02-03
8+
description: |
9+
### Impact
10+
11+
Private data exports can lead to data leaks in cases where the UUID
12+
generation causes collisions for the generated UUIDs.
13+
14+
The bug was introduced by #13571 and affects Decidim versions 0.30.0
15+
or newer (currently 2025-09-23).
16+
17+
This issue was discovered by running the following spec several
18+
times in a row, as it can randomly fail due to this bug:
19+
20+
```bash
21+
$ cd decidim-core
22+
$ for i in {1..10}; do bundle exec rspec
23+
spec/jobs/decidim/download_your_data_export_job_spec.rb
24+
-e "deletes the" || break ; done
25+
```
26+
27+
Run the spec as many times as needed to hit a UUID that converts
28+
to `0` through `.to_i`.
29+
30+
The UUID to zero conversion does not cause a security issue but
31+
the security issue is demonstrated with the following example.
32+
33+
The following code regenerates the issue by assigning a predefined
34+
UUID that will generate a collision (example assumes there are
35+
already two existing users in the system):
36+
37+
```ruby
38+
# Create the ZIP buffers to be stored
39+
buffer1 = Zip::OutputStream.write_buffer do |out|
40+
out.put_next_entry("admin.txt")
41+
out.write "Hello, admin!"
42+
end
43+
buffer1.rewind
44+
buffer2 = Zip::OutputStream.write_buffer do |out|
45+
out.put_next_entry("user.txt")
46+
out.write "Hello, user!"
47+
end
48+
buffer2.rewind
49+
50+
# Create the private exports with a predefined IDs
51+
user1 = Decidim::User.find(1)
52+
export = user1.private_exports.build
53+
export.id = "0210ae70-482b-4671-b758-35e13e0097a9"
54+
export.export_type = "download_your_data"
55+
export.file.attach(io: buffer1, filename: "foobar.zip",
56+
content_type: "application/zip")
57+
export.expires_at = Decidim.download_your_data_expiry_time.from_now
58+
export.metadata = {}
59+
export.save!
60+
61+
user2 = Decidim::User.find(2)
62+
export = user2.private_exports.build
63+
export.id = "0210d2df-a0c7-40aa-ad97-2dae5083e3b8"
64+
export.export_type = "download_your_data"
65+
export.file.attach(io: buffer2, filename: "foobar.zip",
66+
content_type: "application/zip")
67+
export.expires_at = Decidim.download_your_data_expiry_time.from_now
68+
export.metadata = {}
69+
export.save!
70+
```
71+
72+
Expect to see an error in the situation.
73+
74+
Now, login as user with ID 1, go to `/download_your_data`, click
75+
"Download file" from the export and expect to see the data that
76+
should be attached to user with ID 2. This is an artificially
77+
replicated situation with the predefined UUIDs but it can easily
78+
happen in real situations.
79+
80+
The reason for the test case failure can be replicated in case
81+
you change the export ID to
82+
`export.id = "e9540f96-9e3d-4abe-8c2a-6c338d85a684"`.
83+
This would return `0` through `.to_s`
84+
85+
After attaching that ID, you can test if the file is available
86+
for the export:
87+
88+
```ruby
89+
user.private_exports.last.file.attached?
90+
=> false
91+
user.private_exports.last.file.blob
92+
=> nil
93+
```
94+
95+
Note that this fails with such UUID as shown in the example and
96+
could easily lead to collisions in case the UUID starts with a
97+
number. E.g. UUID `"0210ae70-482b-4671-b758-35e13e0097a9"` would
98+
convert to `210` through `.to_s`. Therefore, if someone else has
99+
a "private" export with the prefixes "00000210", "0000210",
100+
"000210", "00210", "0210" or "210", that would cause a collision
101+
and the file could be attached to the wrong private export.
102+
103+
Theoretical chance of collision (the reality depends on the
104+
UUID generation algorithm):
105+
106+
- Potential combinations of the UUID first part (8 characters hex): 16^8
107+
- Potentially colliding character combinations (8 numbers
108+
characters in the range of 0-9): 10^8
109+
- 10^8 / 16^8 ≈ 2.3 (23 / 1000 users)
110+
111+
The root cause is that the class `Decidim::PrivateExport` defines
112+
an ActiveStorage relation to `file` and the table
113+
`active_storage_attachments` stores the related `record_id` as
114+
`bigint` which causes the conversion to happen.
115+
116+
### Workarounds
117+
118+
Fully disable the private exports feature until a patch is available.
119+
cvss_v4: 8.2
120+
unaffected_versions:
121+
- "< 0.30.0"
122+
patched_versions:
123+
- "~> 0.30.4"
124+
- ">= 0.31.0"
125+
related:
126+
url:
127+
- https://nvd.nist.gov/vuln/detail/CVE-2025-65017
128+
- https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp
129+
- https://github.com/decidim/decidim/releases/tag/v0.31.0
130+
- https://github.com/decidim/decidim/releases/tag/v0.30.4
131+
- https://github.com/decidim/decidim/pull/13571
132+
- https://github.com/advisories/GHSA-3cx6-j9j4-54mp

‎gems/decidim/CVE-2025-65017.yml‎

Lines changed: 132 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,132 @@
1+
---
2+
gem: decidim
3+
cve: 2025-65017
4+
ghsa: 3cx6-j9j4-54mp
5+
url: https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp
6+
title: Decidim's private data exports can lead to data leaks
7+
date: 2026-02-03
8+
description: |
9+
### Impact
10+
11+
Private data exports can lead to data leaks in cases where the UUID
12+
generation causes collisions for the generated UUIDs.
13+
14+
The bug was introduced by #13571 and affects Decidim versions 0.30.0
15+
or newer (currently 2025-09-23).
16+
17+
This issue was discovered by running the following spec several
18+
times in a row, as it can randomly fail due to this bug:
19+
20+
```bash
21+
$ cd decidim-core
22+
$ for i in {1..10}; do bundle exec rspec
23+
spec/jobs/decidim/download_your_data_export_job_spec.rb
24+
-e "deletes the" || break ; done
25+
```
26+
27+
Run the spec as many times as needed to hit a UUID that converts
28+
to `0` through `.to_i`.
29+
30+
The UUID to zero conversion does not cause a security issue but
31+
the security issue is demonstrated with the following example.
32+
33+
The following code regenerates the issue by assigning a predefined
34+
UUID that will generate a collision (example assumes there are
35+
already two existing users in the system):
36+
37+
```ruby
38+
# Create the ZIP buffers to be stored
39+
buffer1 = Zip::OutputStream.write_buffer do |out|
40+
out.put_next_entry("admin.txt")
41+
out.write "Hello, admin!"
42+
end
43+
buffer1.rewind
44+
buffer2 = Zip::OutputStream.write_buffer do |out|
45+
out.put_next_entry("user.txt")
46+
out.write "Hello, user!"
47+
end
48+
buffer2.rewind
49+
50+
# Create the private exports with a predefined IDs
51+
user1 = Decidim::User.find(1)
52+
export = user1.private_exports.build
53+
export.id = "0210ae70-482b-4671-b758-35e13e0097a9"
54+
export.export_type = "download_your_data"
55+
export.file.attach(io: buffer1, filename: "foobar.zip",
56+
content_type: "application/zip")
57+
export.expires_at = Decidim.download_your_data_expiry_time.from_now
58+
export.metadata = {}
59+
export.save!
60+
61+
user2 = Decidim::User.find(2)
62+
export = user2.private_exports.build
63+
export.id = "0210d2df-a0c7-40aa-ad97-2dae5083e3b8"
64+
export.export_type = "download_your_data"
65+
export.file.attach(io: buffer2, filename: "foobar.zip",
66+
content_type: "application/zip")
67+
export.expires_at = Decidim.download_your_data_expiry_time.from_now
68+
export.metadata = {}
69+
export.save!
70+
```
71+
72+
Expect to see an error in the situation.
73+
74+
Now, login as user with ID 1, go to `/download_your_data`, click
75+
"Download file" from the export and expect to see the data that
76+
should be attached to user with ID 2. This is an artificially
77+
replicated situation with the predefined UUIDs but it can easily
78+
happen in real situations.
79+
80+
The reason for the test case failure can be replicated in case
81+
you change the export ID to
82+
`export.id = "e9540f96-9e3d-4abe-8c2a-6c338d85a684"`.
83+
This would return `0` through `.to_s`
84+
85+
After attaching that ID, you can test if the file is available
86+
for the export:
87+
88+
```ruby
89+
user.private_exports.last.file.attached?
90+
=> false
91+
user.private_exports.last.file.blob
92+
=> nil
93+
```
94+
95+
Note that this fails with such UUID as shown in the example and
96+
could easily lead to collisions in case the UUID starts with a
97+
number. E.g. UUID `"0210ae70-482b-4671-b758-35e13e0097a9"` would
98+
convert to `210` through `.to_s`. Therefore, if someone else has
99+
a "private" export with the prefixes "00000210", "0000210",
100+
"000210", "00210", "0210" or "210", that would cause a collision
101+
and the file could be attached to the wrong private export.
102+
103+
Theoretical chance of collision (the reality depends on the
104+
UUID generation algorithm):
105+
106+
- Potential combinations of the UUID first part (8 characters hex): 16^8
107+
- Potentially colliding character combinations (8 numbers
108+
characters in the range of 0-9): 10^8
109+
- 10^8 / 16^8 ≈ 2.3 (23 / 1000 users)
110+
111+
The root cause is that the class `Decidim::PrivateExport` defines
112+
an ActiveStorage relation to `file` and the table
113+
`active_storage_attachments` stores the related `record_id` as
114+
`bigint` which causes the conversion to happen.
115+
116+
### Workarounds
117+
118+
Fully disable the private exports feature until a patch is available.
119+
cvss_v4: 8.2
120+
unaffected_versions:
121+
- "< 0.30.0"
122+
patched_versions:
123+
- "~> 0.30.4"
124+
- ">= 0.31.0"
125+
related:
126+
url:
127+
- https://nvd.nist.gov/vuln/detail/CVE-2025-65017
128+
- https://github.com/decidim/decidim/security/advisories/GHSA-3cx6-j9j4-54mp
129+
- https://github.com/decidim/decidim/releases/tag/v0.31.0
130+
- https://github.com/decidim/decidim/releases/tag/v0.30.4
131+
- https://github.com/decidim/decidim/pull/13571
132+
- https://github.com/advisories/GHSA-3cx6-j9j4-54mp

‎gems/fog-kubevirt/CVE-2026-1530.yml‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
---
2+
gem: fog-kubevirt
3+
cve: 2026-1530
4+
ghsa: m3hq-3qj8-c5fm
5+
url: https://access.redhat.com/security/cve/CVE-2026-1530
6+
title: fog-kubevirt allows remote attacker to perform MITM attack
7+
due to disabled certificate validation
8+
date: 2026-02-02
9+
description: |
10+
A flaw was found in fog-kubevirt. This vulnerability allows a remote
11+
attacker to perform a Man-in-the-Middle (MITM) attack due to disabled
12+
certificate validation. This enables the attacker to intercept and
13+
potentially alter sensitive communications between Satellite and
14+
OpenShift, resulting in information disclosure and data integrity
15+
compromise.
16+
cvss_v3: 8.1
17+
patched_versions:
18+
- ">= 1.5.1"
19+
related:
20+
url:
21+
- https://nvd.nist.gov/vuln/detail/CVE-2026-1530
22+
- https://github.com/fog/fog-kubevirt/releases/tag/v1.5.1
23+
- https://github.com/fog/fog-kubevirt/blob/8adb03e07972d6e19a7713ecf2a827aa2cfe4b9e/CHANGELOG.md?plain=1#L11
24+
- https://github.com/fog/fog-kubevirt/pull/168
25+
- https://github.com/fog/fog-kubevirt/commit/8371e9ded99f9ec3e74caf2f283836109763e450
26+
- https://github.com/fog/fog-kubevirt/commit/9603d79a239a0f68bedfc679cd1b65fbf6ec4753
27+
- https://access.redhat.com/security/cve/CVE-2026-1530
28+
- https://bugzilla.redhat.com/show_bug.cgi?id=2433784
29+
- https://github.com/advisories/GHSA-m3hq-3qj8-c5fm

0 commit comments

Comments
 (0)