Skip to content

Bump github.com/oapi-codegen/oapi-codegen/v2 from 2.4.1 to 2.7.1 - #13

Merged
patramsey merged 1 commit into
mainfrom
dependabot/go_modules/github.com/oapi-codegen/oapi-codegen/v2-2.7.1
Aug 2, 2026
Merged

Bump github.com/oapi-codegen/oapi-codegen/v2 from 2.4.1 to 2.7.1#13
patramsey merged 1 commit into
mainfrom
dependabot/go_modules/github.com/oapi-codegen/oapi-codegen/v2-2.7.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 2, 2026

Copy link
Copy Markdown
Contributor

Bumps github.com/oapi-codegen/oapi-codegen/v2 from 2.4.1 to 2.7.1.

Release notes

Sourced from github.com/oapi-codegen/oapi-codegen/v2's releases.

Security fix for Go code injection

This is a security fix for a code injection vulnerability in v2.7.0, please see:

GHSA-rjwr-m7qx-3fjr

[!NOTE] A vulnerability like this requires that it is missed in code review and that you then call the malicious method.

Using an init() function could be enough to not require a direct call to the code, and instead rely on you importing the package, but either way, code review should be performed before any oapi-codegen generated code is executed.

We strongly recommend all users to be reviewing changes to their generated code before they execute anything within it, to protect against supply chain attacks or malicious injected code.

This is also why we recommend oapi-codegen generated code is committed to source control.

We're more strict about escaping strings passed into the OpenAPI specification, so that people can't inject Go code into generated code.

The problem was that it was possible to craft a description for server URL's which would emit arbitrary Go code, so if an attacker controlled your specification, they could inject Go code into your generated code which could do something malicious.

v2.7.0: Squashing bugs, many bugs (and adding some features)

Many improvements and even more bug fixes

This v2.7.0 release of oapi-codegen contains quite a bit of internal refactoring, focused on our most historically fragile code paths, which relate to the aggregate types (allOf/anyOf/oneOf), $ref to external specs, enums, and the spec traversal logic missing quite a few leaf nodes where models should have been generated, but were skipped.

The biggest changes are explicitly described in the sections below, and the full list of commits is at the bottom.

Thank you to all contributors, we've been going through all past PR's and updating them and merging where we can, and thanks to all our users for reporting issues that you hit.

I've (@​mromaszewicz) used a lot of LLM help here to scrub through old issues and do some deep internal refactoring to address common problem areas. I intend to continue doing this, since the conditional generation logic is getting quite complicated. When I originally released oapi-codegen, the use case was much simpler, all the models were under #/components/schemas, and all the references to them were in the requests, responses, etc. I never imagine how many things would be external references or unions, and how many complex OpenAPI specifications people would be generating code for. The initial design was never flexible enough to handle that, so ongoing bug fixes are getting increasingly complex due to edge cases. This version has a lot of internal changes you won't see as a user, but the way we handle type generation internally is unifying lots of copy/paste re-implementations into reusable code for consistency. Most of these changes can be done transparently, but some can't, so, onto the changes:

Code generation changes which might require some changes on your end

This release contains three changes, all very narrow in scope, which will require some manual adjustment of your own code. We've decided that these are small enough and uncommon enough not to require opt-in, which causes internal complexity. It's always a judgment call with these. If we got it wrong, we're happy to revisit it in a maintenance release.

Strict-server external response refs require strict-server generation in both packages (#2357)

If your strict-server spec uses an external $ref to a components/responses/... defined in another spec, that other spec must also be generated with strict-server: true. Add it to the source spec's config and regenerate:

# config for the spec being $ref'd
generate:
  models: true
  strict-server: true   # now required when imported by a strict-server spec

This restores the v2.0.0 behavior that lets you cast response models across package boundaries — the standard pattern for sharing error models (e.g. a common 400) across services. PR #1387 had silently changed the embedded type from N400JSONResponse to the bare externalRef0.N400, so the local and external response structs no longer had matching types and casts stopped compiling.

Many more anonymous inner schemas are now hoisted into top level schemas

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Bumps [github.com/oapi-codegen/oapi-codegen/v2](https://github.com/oapi-codegen/oapi-codegen) from 2.4.1 to 2.7.1.
- [Release notes](https://github.com/oapi-codegen/oapi-codegen/releases)
- [Commits](oapi-codegen/oapi-codegen@v2.4.1...v2.7.1)

---
updated-dependencies:
- dependency-name: github.com/oapi-codegen/oapi-codegen/v2
  dependency-version: 2.7.1
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file go Pull requests that update go code labels Aug 2, 2026
@patramsey
patramsey merged commit 442cb23 into main Aug 2, 2026
2 checks passed
@dependabot
dependabot Bot deleted the dependabot/go_modules/github.com/oapi-codegen/oapi-codegen/v2-2.7.1 branch August 2, 2026 02:22
patramsey added a commit that referenced this pull request Aug 2, 2026
Two things that both trace back to merging a generator bump without
regenerating.

kin-openapi carries two open advisories, GHSA-r277-6w6q-xmqw (critical,
fail-open authentication bypass in ValidationHandler.Load) and
GHSA-jpcw-4wr7-c3vq (nil-pointer panic in openapi3filter), both patched in
0.144.0. Neither is reachable here: kin-openapi enters the graph only through
the oapi-codegen tool, `go list -deps ./...` finds it in zero packages the
binary imports, nothing in this repo imports openapi3filter, and govulncheck
is clean. Bumping anyway — it costs nothing and clears the alert.

Dependabot's own PR for this (#14) was cut against main before the
oapi-codegen and Go bumps landed, so merging it would have reverted Go to
1.26.4 (reintroducing GO-2026-5856) and oapi-codegen to 2.4.1. This does the
bump on current main instead.

Regenerating: #13 moved oapi-codegen 2.4.1 -> 2.7.1 but left zz_generated.go
untouched, so the committed output no longer matched what the generator
produces — 1907 insertions and 843 deletions of drift. The regenerated file
removes nothing from the exported surface (825 -> 936 declarations, all 111
additions are Valid() enum validators that 2.7.x emits). Build, full test
suite, and lint all pass on it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMbe9JETGG73ue5S181hkA
patramsey added a commit that referenced this pull request Aug 2, 2026
Adds `make verify-generate`, run in CI: regenerate, then `git diff
--exit-code` on zz_generated.go.

This is the systemic fix for the previous commit. Bumping oapi-codegen
changes what it emits, but a dependency-bump PR regenerates nothing and
touches no file that would show it — so #13 merged green while leaving the
committed generated code 2750 lines away from what its own generator
produces. Nothing in build, test, or lint notices, because the stale file
still compiles and still passes.

With this step, the bump PR itself goes red and names the fix, instead of the
drift surfacing months later tangled into an unrelated change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMbe9JETGG73ue5S181hkA
patramsey added a commit that referenced this pull request Aug 2, 2026
…rator drift (#18)

* fix: bump kin-openapi to 0.144.0 and regenerate

Two things that both trace back to merging a generator bump without
regenerating.

kin-openapi carries two open advisories, GHSA-r277-6w6q-xmqw (critical,
fail-open authentication bypass in ValidationHandler.Load) and
GHSA-jpcw-4wr7-c3vq (nil-pointer panic in openapi3filter), both patched in
0.144.0. Neither is reachable here: kin-openapi enters the graph only through
the oapi-codegen tool, `go list -deps ./...` finds it in zero packages the
binary imports, nothing in this repo imports openapi3filter, and govulncheck
is clean. Bumping anyway — it costs nothing and clears the alert.

Dependabot's own PR for this (#14) was cut against main before the
oapi-codegen and Go bumps landed, so merging it would have reverted Go to
1.26.4 (reintroducing GO-2026-5856) and oapi-codegen to 2.4.1. This does the
bump on current main instead.

Regenerating: #13 moved oapi-codegen 2.4.1 -> 2.7.1 but left zz_generated.go
untouched, so the committed output no longer matched what the generator
produces — 1907 insertions and 843 deletions of drift. The regenerated file
removes nothing from the exported surface (825 -> 936 declarations, all 111
additions are Valid() enum validators that 2.7.x emits). Build, full test
suite, and lint all pass on it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMbe9JETGG73ue5S181hkA

* ci: fail when generated code drifts from its generator

Adds `make verify-generate`, run in CI: regenerate, then `git diff
--exit-code` on zz_generated.go.

This is the systemic fix for the previous commit. Bumping oapi-codegen
changes what it emits, but a dependency-bump PR regenerates nothing and
touches no file that would show it — so #13 merged green while leaving the
committed generated code 2750 lines away from what its own generator
produces. Nothing in build, test, or lint notices, because the stale file
still compiles and still passes.

With this step, the bump PR itself goes red and names the fix, instead of the
drift surfacing months later tangled into an unrelated change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NMbe9JETGG73ue5S181hkA

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file go Pull requests that update go code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant