# CVE-2026-66884: Cross-site request forgery in oidcc plug

> Attackers can bypass CSRF protections in oidcc_plug to sign victims into attacker-controlled accounts, leading to account takeover and data exposure.

- **Severity:** Low 2.1 (`CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 4 Aug 2026
- **Updated:** 4 Aug 2026
- **Also known as:** EEF-CVE-2026-66884, GHSA-fg66-w5gp-22cr

## What is CVE-2026-66884?

CVE-2026-66884 is a low-severity vulnerability in Erlang Ecosystem Foundation oidcc_plug, published on 4 Aug 2026. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.

### Official description

Cross-Site Request Forgery vulnerability in Erlang Ecosystem Foundation oidcc_plug (Oidcc.Plug.AuthorizationCallback module) allows an attacker to make a victim's browser complete an authorization flow the victim never initiated.

This vulnerability is associated with program file lib/oidcc/plug/authorization_callback.ex and program routine Oidcc.Plug.AuthorizationCallback.call/2.

A callback request that carries no Oidcc.Plug.Authorize session is processed with every security check disabled rather than being rejected. call/2 substitutes permissive defaults for the absent session, and each downstream check treats its value as nothing to compare and returns :ok, so the nonce, state, PKCE, peer IP and user agent checks are all skipped. A separate clause of check_state/2 also accepts a state-less request when a verifier is present.

An attacker obtains an authorization code for their own provider account, then induces the victim to visit the callback endpoint with that code and no state parameter. The application signs the victim in as the attacker, so the victim's subsequent actions occur in the attacker's account where the attacker can read them. Applications reusing one callback for both signing in and linking a provider account are further exposed to account takeover, the attacker's account becoming linked to the victim's.

The permissive fallback serves no conforming flow. Third-party-initiated login reaches a relying party at a separate login initiation endpoint and causes it to send a fresh authentication request, and this library implements no such endpoint. Oidcc.Plug.Authorize always sends a state parameter, which an authorization server must echo, so no legitimate callback lacks one.

This issue affects oidcc_plug: from 0.2.0-beta.1 before 0.5.0.

Weakness: CWE-352 (Cross-Site Request Forgery)

## Which versions are affected by CVE-2026-66884?

1 open source package ship an affected version, including oidcc_plug.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `oidcc_plug` | Hex | From 0.2.0-beta.1 | 0.5.0 |

## How do I fix CVE-2026-66884?

Upgrade oidcc_plug to 0.5.0 or later.

## Is CVE-2026-66884 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-66884 exists.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-66884 and fix it if it is affected.

What it is: CVE-2026-66884 is a low-severity vulnerability in Erlang Ecosystem Foundation oidcc_plug, published on 4 Aug 2026. An attacker can exploit it over the internet without logging in, and only if a user opens a file or follows a link.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-66884 exists.

Affected packages and fixed versions:
- oidcc_plug (Hex): affected from 0.2.0-beta.1; fixed in 0.5.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-66884/ (Markdown: https://insights.sbomify.com/CVE-2026-66884/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-66884
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-66884
- OSV: https://osv.dev/vulnerability/CVE-2026-66884

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-66884/
Summaries are generated and may contain mistakes; the official description above is the record.