Repository navigation
fix: bump pelletier/go-toml/v2 to v2.4.3 - #621
Merged
Merged
Conversation
Procore's Xray scan of 2.18.1 reports XRAY-1033007 against
github.com/pelletier/go-toml/v2 v2.2.4, fixed in v2.4.3. The module
arrives indirectly via spf13/viper, whose v1.21.0 go.mod requires
v2.2.4, so nothing in the 2.18.1 work moved it.
v2.4.3 is the release carrying upstream PR #1092, "bound array and
inline table nesting depth to prevent stack-overflow DoS", which lines
up with a High-severity denial-of-service finding. v2.3.0 through v2.4.2
also removed the unsafe package entirely and fixed several
fuzz-discovered panics.
Not reachable in this codebase, but worth bumping regardless. The TOML
codec is linked in because viper registers codecs for every entry in
SupportedExts, but options.go pins viper.SetConfigType("yaml") and
viper's getConfigType returns configType verbatim when set, so the toml
branch in viper's encoding.go is never selected. That is also why
govulncheck reports nothing reachable.
Worth noting for the customer reply: this advisory is not in any public
database. OSV returns zero results for this module at every version, so
it is absent from both the Go vulnerability database and the GitHub
Advisory Database. XRAY-1033007 is JFrog proprietary research data,
which is why govulncheck and Dependabot are both silent on it and why
2.18.1 did not pick it up.
go build, go vet, go test ./... and golangci-lint all pass; govulncheck
remains at 0. Verified v2.4.3 is recorded in a linux/amd64 build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
erangeles
approved these changes
Sep 25, 2026
cspath1
added a commit
that referenced
this pull request
Sep 25, 2026
Prepares the 2.18.2 release by hand, same approach as 2.18.1 in #620 and 2.18.0 in #618: rulesets block the release workflow from pushing version bumps straight to main, so the bump lands as a normal PR. Ships the pelletier/go-toml/v2 v2.4.3 bump from #621, which clears the XRAY-1033007 finding Procore reported against the 2.18.1 binary. Also realigns the Action tag and the scanner version at 2.18.2. The 2.18.1 prep replaced every 2.17.0 reference in the Action metadata README, including the `uses: launchdarkly/find-code-references@v2.17.0` examples, but the Action repo was tagged v2.18.0 rather than v2.18.1. That left the README -- here and, after the #67 sync, live in the Action repo -- pointing at a tag that does not exist, so the examples 404 when copy-pasted. Both streams now read 2.18.2. Publish order, unchanged from 2.18.1 and worth repeating because immutable releases allow one attempt per tag name: - do not push the tag before running the release workflow - build artifacts first (make products-for-release) - create the release as a draft with all 15 assets attached, verify the count, then publish - sync find-code-references and tag it v2.18.2 so the README examples resolve, then move its v2 tag <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > **Release 2.18.2** bumps the embedded scanner version and aligns GitHub Action metadata so copy-paste examples and default container images point at **`v2.18.2`** / **`launchdarkly/ld-find-code-refs-github-action:2.18.2`** instead of the missing **`v2.18.1`** Action tag. > > The changelog records **2.18.2** as addressing **XRAY-1033007** via **`github.com/pelletier/go-toml/v2` v2.4.3** (indirect through Viper; config stays YAML-only) and fixing the Action README/tag mismatch from the 2.18.1 prep. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 2616ac2. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Xray scan of 2.18.1 reports XRAY-1033007 against github.com/pelletier/go-toml/v2 v2.2.4, fixed in v2.4.3. The module arrives indirectly via spf13/viper, whose v1.21.0 go.mod requires v2.2.4, so nothing in the 2.18.1 work moved it.
v2.4.3 is the release carrying upstream PR #1092, "bound array and inline table nesting depth to prevent stack-overflow DoS", which lines up with a High-severity denial-of-service finding. v2.3.0 through v2.4.2 also removed the unsafe package entirely and fixed several fuzz-discovered panics.
Not reachable in this codebase, but worth bumping regardless. The TOML codec is linked in because viper registers codecs for every entry in SupportedExts, but options.go pins viper.SetConfigType("yaml") and viper's getConfigType returns configType verbatim when set, so the toml branch in viper's encoding.go is never selected. That is also why govulncheck reports nothing reachable.
Worth noting: this advisory is not in any public database. OSV returns zero results for this module at every version, so it is absent from both the Go vulnerability database and the GitHub Advisory Database. XRAY-1033007 is JFrog proprietary research data, which is why govulncheck and Dependabot are both silent on it and why 2.18.1 did not pick it up.
go build, go vet, go test ./... and golangci-lint all pass; govulncheck remains at 0. Verified v2.4.3 is recorded in a linux/amd64 build.