# GHSA-m6w8-fq7v-ph4m: GovernorCompatibilityBravo incorrect ABI encoding may lead to unexpected behavior

> Incorrect ABI encoding in GovernorCompatibilityBravo allows creating governance proposals with wrong arguments, potentially altering execution logic.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 13 Jan 2022

## What is GHSA-m6w8-fq7v-ph4m?

GHSA-m6w8-fq7v-ph4m is a vulnerability in @openzeppelin/contracts, published on 13 Jan 2022. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

### Impact

The `GovernorCompatibilityBravo` module may lead to the creation of governance proposals that execute function calls with incorrect arguments due to bad ABI encoding. This happens if the proposal is created using explicit function signatures, e.g. a proposal to invoke the function `foo(uint256)` is created as `propose([target], [0], ["foo(uint256)"], ["0x00..01"])`. If the function selector is provided as part of the encoded proposal data the issue is not present, e.g. the same proposal is created as `propose([target], [0], ["0x2fbebd3800..01"])`, where `2fbebd38` is the function selector.

We've assessed the instances of this contract found on chain, and did not find any occurrence of this bug in the past. Proposal creation through Tally or OpenZeppelin Defender is not affected. The core `Governor` contract on its own is not affected.

### Patches

A fix is included in version v4.4.2 of `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`.

### Workarounds

Do not create proposals using explicit function signatures. Instead, use the `propose` function without the `signatures` argument, and create the proposal using the fully ABI-encoded function call including the function selector in the `calldatas` argument as explained above.

### References

https://github.com/OpenZeppelin/openzeppelin-contracts/issues/3099

### Credits

This issue was identified and reported by @GeraldHost.

### For more information

If you have any questions, comments, or need assistance regarding this advisory, email us at security@openzeppelin.com.

To submit security reports please use [our bug bounty on Immunefi](https://immunefi.com/bounty/openzeppelin/).

## Which versions are affected by GHSA-m6w8-fq7v-ph4m?

4 open source packages ship an affected version, including @openzeppelin/contracts and @openzeppelin/contracts-upgradeable.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `@openzeppelin/contracts` | npm | From 4.3.0 | 4.4.2 |
| `@openzeppelin/contracts` | npm | From 4.3.0 | 4.4.2 |
| `@openzeppelin/contracts-upgradeable` | npm | From 4.3.0 | 4.4.2 |
| `@openzeppelin/contracts-upgradeable` | npm | From 4.3.0 | 4.4.2 |

## How do I fix GHSA-m6w8-fq7v-ph4m?

Upgrade @openzeppelin/contracts to 4.4.2 or later.

## Is GHSA-m6w8-fq7v-ph4m being exploited?

There is no known exploitation of GHSA-m6w8-fq7v-ph4m in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-m6w8-fq7v-ph4m and fix it if it is affected.

What it is: GHSA-m6w8-fq7v-ph4m is a vulnerability in @openzeppelin/contracts, published on 13 Jan 2022. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-m6w8-fq7v-ph4m in the wild and no public exploit code.

Affected packages and fixed versions:
- @openzeppelin/contracts (npm): affected from 4.3.0; fixed in 4.4.2
- @openzeppelin/contracts (npm): affected from 4.3.0; fixed in 4.4.2
- @openzeppelin/contracts-upgradeable (npm): affected from 4.3.0; fixed in 4.4.2
- @openzeppelin/contracts-upgradeable (npm): affected from 4.3.0; fixed in 4.4.2

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/GHSA-m6w8-fq7v-ph4m/ (Markdown: https://insights.sbomify.com/GHSA-m6w8-fq7v-ph4m/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-m6w8-fq7v-ph4m

---
From sbomify Insights: https://insights.sbomify.com/GHSA-m6w8-fq7v-ph4m/
Summaries are generated and may contain mistakes; the official description above is the record.