## Summary

Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.

`verify_token/2` in `lib/nimble_zta/cloudflare.ex` matches the result of `JOSE.JWT.verify/2` against `{_, token, _s}`, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the `cf-access-jwt-assertion` header, carrying the expected `iss` claim and the seven service token claims. `verify_iss/2` reads the `iss` claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.

This issue affects nimble_zta: from 0.1.2 before 0.1.3.

## Proof of concept

1. Build a JWT payload that carries the `aud`, `common_name`, `exp`, `iat`, `iss`, `sub` and `type` claims. Use the `iss` the application expects, set `exp` to a future timestamp, and set `common_name` to the service token to impersonate.
2. Append any signature segment. The segment must be present, because `JOSE.JWT.verify/2` needs three segments to parse the token. The signature does not need to verify against the Cloudflare keys.
3. Send a request to the application with the forged JWT in the `cf-access-jwt-assertion` header.
4. `NimbleZTA.Cloudflare.authenticate/3` returns the claims of the forged token as the authenticated identity, with the `strategy` field set to `service_token`.

## Impact

The attacker authenticates as an arbitrary Cloudflare service token without holding the Cloudflare signing key. The application receives the `client_id` and the claims of the forged token as the authenticated identity, so the attacker gets the access that the application grants to that service token.

## Workarounds

Disable the Cloudflare authentication strategy.

To keep the user identity strategy available, reject the service token requests yourself. Examine each request before you call `NimbleZTA.Cloudflare.authenticate/3`, and reject it if its JWT carries the `common_name` claim and the `type` claim.

## Configurations

The application must add `NimbleZTA.Cloudflare` to its supervision tree and authenticate requests through it.

## Summary

Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability in the Sign in with Apple strategy in pow-auth Assent allows an unauthenticated remote attacker to impersonate another user via the `user` parameter of the authorization callback.

Apple posts the user's name to the callback endpoint in a `user` form parameter that the browser submits and the client controls. `Assent.Strategy.Apple.callback/2` in `lib/assent/strategies/apple.ex` decodes that parameter, and `fetch_user/2` merges it over the claims of the verified ID token, so the unverified map wins. An attacker who completes a Sign in with Apple login with their own Apple ID and edits the `user` parameter can replace `sub`, `email`, and any other claim. Applications that look up, link, or authorize accounts by the returned subject or email then act on the attacker's values.

This issue affects assent: from 0.1.25 before 0.3.2.

## Details

**1. Unverified input.** Apple's `form_post` response mode delivers `code`, `id_token`, `state`, and on the first authorization a `user` parameter that holds a JSON object with the user's name and email. The browser submits this parameter and Apple does not sign it, so the client controls its content.

**2. Merge over verified claims.** `Assent.Strategy.Apple.callback/2` decodes the `user` parameter with `Helpers.decode_json/2` and stores the map in the config under `:user`. After `Assent.Strategy.OIDC.fetch_user/2` has validated the ID token, `Assent.Strategy.Apple.fetch_user/2` calls `Map.merge/2` with the verified claims first and the decoded parameter second. Keys from the parameter overwrite keys from the token, including `sub` and `email`.

**3. Result.** `normalize/2` reads `sub` and `email` from the merged map and sets `email_verified` to true, so the application receives attacker-chosen identity fields marked as verified.

**4. Fix.** Version 0.3.2 ignores the parameter by default. With `include_unverified_name: true`, only `given_name` and `family_name` are taken from it, and the verified claims are merged over them.

## Proof of concept

1. Start the Sign in with Apple flow of an application that uses `Assent.Strategy.Apple`.
2. Authenticate at Apple with an Apple ID the attacker controls.
3. Intercept the `form_post` request to the application's callback URL and set the `user` parameter to a JSON object that carries the victim's values, such as `{"sub": "<victim subject>", "email": "victim@example.com"}`.
4. The application calls `Assent.Strategy.Apple.callback/2`. It validates the attacker's ID token and returns a user map whose `sub` and `email` are the victim's values, with `email_verified` set to true.

## Impact

An attacker with any Apple ID can sign in to an application that uses the Apple strategy as any other user whose Apple subject or email they know. Account lookup, account linking, and email-based access control then act on the attacker-chosen identity.

## Workarounds

Remove the `user` parameter from the callback parameters before you pass them to `Assent.Strategy.Apple.callback/2`, for example with `Map.delete(params, "user")`. Without the parameter, `decode_user_params/2` yields an empty map and the verified ID token claims pass through unchanged. The user's name is then unavailable, because Apple delivers it only through this parameter.

## Summary

Code Injection vulnerability in phenixdigital phoenix\_storybook allows unauthenticated remote code execution via unsanitized attribute value interpolation in HEEx template generation.

The psb-assign WebSocket event handler in 'Elixir.PhoenixStorybook.Story.PlaygroundPreviewLive':handle\_event/3 accepts arbitrary attribute names and values from unauthenticated clients. These values are passed to 'Elixir.PhoenixStorybook.Helpers.ExtraAssignsHelpers':handle\_set\_variation\_assign/3, which stores them verbatim. When rendering, 'Elixir.PhoenixStorybook.Rendering.ComponentRenderer':attributes\_markup/1 interpolates binary attribute values directly into a HEEx template string as name="<val>" without escaping double quotes or HEEx expression delimiters. An attacker can supply a value containing a closing quote followed by a HEEx expression block (e.g. foo" injected={EXPR} bar="), which causes EXPR to be treated as an inline Elixir expression. The resulting template is compiled via EEx.compile\_string/2 and executed via Code.eval\_quoted\_with\_env/3 with full Kernel imports and no sandbox, giving the attacker arbitrary code execution on the server.

This issue affects phoenix\_storybook from 0.5.0 before 1.1.0.

CVE ID↕	Published↕	CVSS↑
EEF-CVE-2026-91187	Sep 24, 2026	Critical 9.3
EEF-CVE-2026-117656	Oct 30, 2026	Critical 9.3
EEF-CVE-2026-8467	May 20, 2026	Critical 9.5

Know every vulnerability
before it knows you.

hex CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerabilitybefore it knows you.

hex CVE Vulnerabilities — DevGuard Vulnerability Database

Know every vulnerability
before it knows you.