Source
ghsa
### Summary An Unauthenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an unauthenticated attacker to access guest address information without supplying valid credentials or session cookies. ### Details During testing, it was observed that all guest users can make an unauthenticated request to retrieve address data belonging to other guest users by manipulating object identifiers. The attacker would need to know the storefront URL structure to perform this attack (which can be learnt after creating a registered user account). Affected Component(s) * Address Edit endpoint: `/addresses/{addressId}/edit` Root Cause - Faulty authorization check in CanCanCan Ability class: ```diff - can :manage, ::Spree::Address, user_id: user.id + can :manage, ::Spree::Address, user_id: user.id if user.persisted? ``` the `user` object in `Spree::Ability` class for guest users is a `Spree.user_class.new` object. Addresses endpoint to access it is part of the `...
### Summary An Authenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an authenticated user to retrieve other users’ address information by modifying an existing order. By editing an order they legitimately own and manipulating address identifiers in the request, the backend server accepts and processes references to addresses belonging to other users, subsequently associating those addresses with the attacker’s order and returning them in the response. ### Details Affected Component(s) - Authenticated user order management - Address association logic - Order update endpoint(s) Affected Endpoint(s): - `/api/v2/storefront/checkout` The application fails to enforce proper object-level authorization when updating an existing order. While the user is authenticated and authorized to modify their own order, the backend does not verify that the supplied address identifiers belong to the same authenticated user. ### PoC Preconditions - Valid authentic...
# Summary The function `list_html` generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page. # Details The vulnerable snippet of code is the following: [**dir.rs**](https://github.com/salvo-rs/salvo/blob/16efeba312a274739606ce76366d921768628654/crates/serve-static/src/dir.rs#L593) ```rust // ... fn list_html(... let mut ftxt = format!( r#"<!DOCTYPE html><html><head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width"> <title>{}</title> <style>{}</style></head><body><...
# Summary The function `list_html` generates a file view of a folder without sanitizing the files or folders names, potentially leading to XSS in cases where a website allows access to public files using this feature, allowing anyone to upload a file. # Details The vulnerable snippet of code is the following: [**dir.rs**](https://github.com/salvo-rs/salvo/blob/16efeba312a274739606ce76366d921768628654/crates/serve-static/src/dir.rs#L581) ```rust // ... fn list_html(... let mut link = "".to_owned(); format!( r#"<a href="/">{}</a>{}"#, HOME_ICON, segments .map(|seg| { link = format!("{link}/{seg}"); format!("/<a href=\"{link}\">{seg}</a>") }) .collect::<Vec<_>>() .join("") ) // ... ``` # PoC https://github.com/user-attachments/assets/1e161e17-f033-4cc4-855b-43fd38ed1be4 Here is the example app we used: `mian.rs` ```rs ...
### Summary Since 2017, the default webpack plugins have passed the entire `process.env` to `EnvironmentPlugin`. This pattern exposed ALL build environment variables to client-side JavaScript bundles whenever application code (or any dependency) referenced `process.env.VARIABLE_NAME`. This is not a regression - the vulnerable code has existed since the original Webpacker implementation. No recent code change in Shakapacker triggered this issue. ### Impact Any environment variable in the build environment that is referenced in client-side code (including third-party dependencies) is embedded directly into the JavaScript bundle. This includes: - `DATABASE_URL` - Database credentials - `AWS_SECRET_ACCESS_KEY` - AWS credentials - `RAILS_MASTER_KEY` - Rails encrypted credentials key - `STRIPE_SECRET_KEY`, `TWILIO_AUTH_TOKEN` - Third-party API keys - Any other secrets present in the build environment **Severity**: Critical - secrets are exposed in publicly accessible JavaScript files...
## LFS Lock Force-Delete Authorization Bypass ### Summary An authorization bypass in the LFS lock deletion endpoint allows any authenticated user with repository write access to delete locks owned by other users by setting the `force` flag. The vulnerable code path processes force deletions before retrieving user context, bypassing ownership validation entirely. ### Severity - **CWE-863:** Incorrect Authorization - **CVSS 3.1:** 5.4 (Medium) — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L` ### Affected Code **File:** `pkg/web/git_lfs.go` **Function:** `serviceLfsLocksDelete` (lines 831–945) **Endpoint:** `POST /<repo>.git/info/lfs/locks/:lockID/unlock` The control flow processes `req.Force` at line 905 before retrieving user context at line 919: ```go // Line 905-916: Force delete executes immediately without authorization if req.Force { if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil { // ... } renderJSON(w, http.StatusOK, l) ...
React Router (or Remix v2) is vulnerable to CSRF attacks on document POST requests to UI routes when using server-side route `action` handlers in [Framework Mode](https://reactrouter.com/start/modes#framework), or when using React Server Actions in the new unstable RSC modes. > [!NOTE] > This does not impact applications that use [Declarative Mode](https://reactrouter.com/start/modes#declarative) (`<BrowserRouter>`) or [Data Mode](https://reactrouter.com/start/modes#data) (`createBrowserRouter`/`<RouterProvider>`).
React Router (and Remix v1/v2) SPA open navigation redirects originating from loaders or actions in [Framework Mode](https://reactrouter.com/start/modes#framework), [Data Mode](https://reactrouter.com/start/modes#data), or the unstable RSC modes can result in unsafe URLs causing unintended javascript execution on the client. This is only an issue if developers are creating redirect paths from untrusted content or via an open redirect. > [!NOTE] > This does not impact applications that use [Declarative Mode](https://reactrouter.com/start/modes#declarative) (`<BrowserRouter>`).
A XSS vulnerability exists in in React Router's `<ScrollRestoration>` API in [Framework Mode](https://reactrouter.com/start/modes#framework) when using the `getKey`/`storageKey` props during Server-Side Rendering which could allow arbitrary JavaScript execution during SSR if untrusted content is used to generate the keys. > [!NOTE] > This does not impact applications if developers have [disabled server-side rendering](https://reactrouter.com/how-to/spa) in Framework Mode, or if they are using [Declarative Mode](https://reactrouter.com/start/modes#declarative) (`<BrowserRouter>`) or [Data Mode](https://reactrouter.com/start/modes#data) (`createBrowserRouter`/`<RouterProvider>`).
An attacker-supplied path can be crafted so that when a React Router application navigates to it via `navigate()`, `<Link>`, or `redirect()`, the app performs a navigation/redirect to an external URL. This is only an issue if developers pass untrusted content into navigation paths in their application code.