[vulndb] data/reports: add symbols for GO-2026-4859
Gerrit Bot (Gerrit)
Gerrit Bot has uploaded the change for review![]( "Open in Gerrit")
Commit message
data/reports: add symbols for GO-2026-4859
Updates the affected symbols list to enable precise call graph analysis in govulncheck.
Fixes golang/vulndb#5011
Change diff
diff --git a/data/osv/GO-2026-4859.json b/data/osv/GO-2026-4859.json
index 6970e44..edf73ec 100644
--- a/data/osv/GO-2026-4859.json
+++ b/data/osv/GO-2026-4859.json
@@ -28,7 +28,29 @@
]
}
],
- "ecosystem_specific": {}
+ "ecosystem_specific": {
+ "imports": [
+ {
+ "path": "github.com/moby/buildkit/client/llb",
+ "symbols": [
+ "Git"
+ ]
+ },
+ {
+ "path": "github.com/moby/buildkit/source/git",
+ "symbols": [
+ "NewGitIdentifier",
+ "Source.Identifier"
+ ]
+ },
+ {
+ "path": "github.com/moby/buildkit/util/gitutil",
+ "symbols": [
+ "ParseURL"
+ ]
+ }
+ ]
+ }
}
],
"references": [
@@ -43,6 +65,14 @@
{
"type": "WEB",
"url": "https://github.com/moby/buildkit/releases/tag/v0.28.1"
+ },
+ {
+ "type": "FIX",
+ "url": "https://github.com/moby/buildkit/commit/45b038cd0b2ec2d34013ce0f085522276f7ee0d8"
+ },
+ {
+ "type": "FIX",
+ "url": "https://github.com/moby/buildkit/commit/f5462c216098af766f97ea4cb328e65c6d8f7256"
}
],
"database_specific": {
diff --git a/data/reports/GO-2026-4859.yaml b/data/reports/GO-2026-4859.yaml
index 646557d..af85793 100644
--- a/data/reports/GO-2026-4859.yaml
+++ b/data/reports/GO-2026-4859.yaml
@@ -4,6 +4,18 @@
versions:
- fixed: 0.28.1
vulnerable_at: 0.28.0
+ packages:
+ - package: github.com/moby/buildkit/client/llb
+ symbols:
+ - Git
+ - package: github.com/moby/buildkit/source/git
+ symbols:
+ - NewGitIdentifier
+ derived_symbols:
+ - Source.Identifier
+ - package: github.com/moby/buildkit/util/gitutil
+ symbols:
+ - ParseURL
summary: BuildKit Git URL subdir component can cause access to restricted files in github.com/moby/buildkit
cves:
- CVE-2026-33748
@@ -13,8 +25,8 @@
- advisory: https://github.com/moby/buildkit/security/advisories/GHSA-4vrq-3vrq-g6gg
- web: https://docs.docker.com/build/concepts/context/#url-fragments
- web: https://github.com/moby/buildkit/releases/tag/v0.28.1
-notes:
- - failed to auto-populate symbols: no commits found for github.com/moby/buildkit
+ - fix: https://github.com/moby/buildkit/commit/45b038cd0b2ec2d34013ce0f085522276f7ee0d8
+ - fix: https://github.com/moby/buildkit/commit/f5462c216098af766f97ea4cb328e65c6d8f7256
source:
id: GHSA-4vrq-3vrq-g6gg
created: 2026-03-26T15:25:09.28540352-04:00
Change information
- M data/osv/GO-2026-4859.json
- M data/reports/GO-2026-4859.yaml
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gopher Robot (Gerrit)
Gopher Robot added 1 comment![]( "Open in Gerrit")
I spotted some possible problems with your PR:
1. You have a long 87 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)
2. Do you have the right bug reference format? For most repos outside the main go repo, the format is usually 'Fixes golang/go#12345' or 'Updates golang/go#12345' at the end of the commit message.
Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gopher Robot (Gerrit)
Message from Gopher Robot![]( "Open in Gerrit")
Congratulations on opening your first change. Thank you for your contribution!
Next steps:
A maintainer will review your change and provide feedback. See
https://go.dev/doc/contribute#review for more info and tips to get your
patch through code review.
Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kunal Memane (MK) (Gerrit)
Kunal Memane (MK) added 1 comment![]( "Open in Gerrit")
I spotted some possible problems with your PR:
1. You have a long 87 character line in the commit message body. Please add line breaks to long lines that should be wrapped. Lines in the commit message body should be wrapped at ~76 characters unless needed for things like URLs or tables. (Note: GitHub might render long lines as soft-wrapped, so double-check in the Gerrit commit message shown above.)
2. Do you have the right bug reference format? For most repos outside the main go repo, the format is usually 'Fixes golang/go#12345' or 'Updates golang/go#12345' at the end of the commit message.Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Done
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gerrit Bot (Gerrit)
Gerrit Bot uploaded new patchset![]( "Open in Gerrit")
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kunal Memane (MK) (Gerrit)
Kunal Memane (MK) added 1 comment![]( "Open in Gerrit")
Hi
@hu...@google.com, fyi as you own https://go-review.googlesource.com/c/vulndb/+/760421.
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kunal Memane (MK) (Gerrit)
Kunal Memane (MK) added 1 comment![]( "Open in Gerrit")
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nicholas Husin (Gerrit)
Nicholas Husin added 1 comment![]( "Open in Gerrit")
Thanks for the CL.
Can I ask how you came to these symbols and the motivation behind adding them?
I'm personally more inclined to keep the symbols unpopulated for the following reasons:
- The GHSA does not mention a specific fix commit. While the commits you selected look reasonable, it seems hard to be 100% sure without doing a thorough investigation.
- The fix you commits selected also include diffs to symbols that you have not added, e.g. `45b038cd0b2ec2d34013ce0f085522276f7ee0d8` changes `parseOpts`, which in turn affects `FromURL` in `github.com/moby/buildkit/util/gitutil`. It could very well be the case that this does not affect the vuln at all, but again, it is hard to be 100% sure without digging deeply.
- There is already a newer fixed version which, from a glance, does not introduce breaking API changes. So, users who are getting alerted by the vulnerability should be able to jut upgrade their module version.
Essentially, I think it is better to be conservative if we cannot be 100% sure that no other symbols are affected, so users do not get a false negative.
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kunal Memane (MK) (Gerrit)
Kunal Memane (MK) added 1 comment![]( "Open in Gerrit")
Thanks for the CL.
Can I ask how you came to these symbols and the motivation behind adding them?
I'm personally more inclined to keep the symbols unpopulated for the following reasons:
- The GHSA does not mention a specific fix commit. While the commits you selected look reasonable, it seems hard to be 100% sure without doing a thorough investigation.
- The fix you commits selected also include diffs to symbols that you have not added, e.g. `45b038cd0b2ec2d34013ce0f085522276f7ee0d8` changes `parseOpts`, which in turn affects `FromURL` in `github.com/moby/buildkit/util/gitutil`. It could very well be the case that this does not affect the vuln at all, but again, it is hard to be 100% sure without digging deeply.
- There is already a newer fixed version which, from a glance, does not introduce breaking API changes. So, users who are getting alerted by the vulnerability should be able to jut upgrade their module version.
Essentially, I think it is better to be conservative if we cannot be 100% sure that no other symbols are affected, so users do not get a false negative.
Thanks for the response.
The commits were identified by comparing v0.28.0..v0.28.1, the release notes explicitly reference this GHSA. Only 8 commits exist between the two versions; these two are the only ones related to Git URL/subdir handling.
Why these specific symbols:
1. llb.Git - the client-side LLB API entry point. The fix adds subdir normalization (path.Join("/", subdir)) directly here.
2. source/git.NewGitIdentifier / Source.Identifier - the server-side entry points. NewGitIdentifier had insufficient path.Clean logic that was replaced, and Source.Identifier (derived) delegates to it and also gained validateGitRef.
3. gitutil.ParseURL - the URL parsing entry point. It calls the unexported parseOpts (via FromURL/fromSCPStyleURL) where the core subdir normalization fix lives.
On symbols touched but not included:
1. parseOpts is unexported - covered by listing ParseURL.
2. FromURL is exported but is an intermediate step called by ParseURL.
3. validateDirsOnly, validateGitRef - newly added by the fix, not vulnerable symbols.
4. checkout, resolveMetadata, tryRemoteFetch — methods on the unexported gitSourceHandler type. The changes there are hardening with "no known attack" per the commit message.
On being conservative:
Leaving symbols unpopulated avoids false negatives but introduces false positives - every project importing buildkit at a vulnerable version gets flagged, even if it never uses Git sources. The symbols here are the minimal set of exported entry points covering all paths through which a malicious subdir enters the system. govulncheck can then correctly scope alerts to projects that actually call these functions.
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nicholas Husin (Gerrit)
Nicholas Husin added 1 comment![]( "Open in Gerrit")
Kunal Memane (MK)Thanks for the CL.
Can I ask how you came to these symbols and the motivation behind adding them?
I'm personally more inclined to keep the symbols unpopulated for the following reasons:
- The GHSA does not mention a specific fix commit. While the commits you selected look reasonable, it seems hard to be 100% sure without doing a thorough investigation.
- The fix you commits selected also include diffs to symbols that you have not added, e.g. `45b038cd0b2ec2d34013ce0f085522276f7ee0d8` changes `parseOpts`, which in turn affects `FromURL` in `github.com/moby/buildkit/util/gitutil`. It could very well be the case that this does not affect the vuln at all, but again, it is hard to be 100% sure without digging deeply.
- There is already a newer fixed version which, from a glance, does not introduce breaking API changes. So, users who are getting alerted by the vulnerability should be able to jut upgrade their module version.
Essentially, I think it is better to be conservative if we cannot be 100% sure that no other symbols are affected, so users do not get a false negative.
Thanks for the response.
The commits were identified by comparing v0.28.0..v0.28.1, the release notes explicitly reference this GHSA. Only 8 commits exist between the two versions; these two are the only ones related to Git URL/subdir handling.
Why these specific symbols:
1. llb.Git - the client-side LLB API entry point. The fix adds subdir normalization (path.Join("/", subdir)) directly here.
2. source/git.NewGitIdentifier / Source.Identifier - the server-side entry points. NewGitIdentifier had insufficient path.Clean logic that was replaced, and Source.Identifier (derived) delegates to it and also gained validateGitRef.
3. gitutil.ParseURL - the URL parsing entry point. It calls the unexported parseOpts (via FromURL/fromSCPStyleURL) where the core subdir normalization fix lives.On symbols touched but not included:
1. parseOpts is unexported - covered by listing ParseURL.
2. FromURL is exported but is an intermediate step called by ParseURL.
3. validateDirsOnly, validateGitRef - newly added by the fix, not vulnerable symbols.
4. checkout, resolveMetadata, tryRemoteFetch — methods on the unexported gitSourceHandler type. The changes there are hardening with "no known attack" per the commit message.On being conservative:
Leaving symbols unpopulated avoids false negatives but introduces false positives - every project importing buildkit at a vulnerable version gets flagged, even if it never uses Git sources. The symbols here are the minimal set of exported entry points covering all paths through which a malicious subdir enters the system. govulncheck can then correctly scope alerts to projects that actually call these functions.
FromURL is exported but is an intermediate step called by ParseURL.
It looks like `ParseURL` is a rather thin wrapper around `FromURL`:
```
// ParseURL parses a BuildKit-style Git URL (that may contain additional
// fragment metadata) and returns a parsed GitURL object.
func ParseURL(remote string) (*GitURL, error) {
if proto := protoRegexp.FindString(remote); proto != "" {
proto = strings.ToLower(strings.TrimSuffix(proto, "://"))
if _, ok := supportedProtos[proto]; !ok {
return nil, errors.Wrap(ErrInvalidProtocol, proto)
}
url, err := url.Parse(remote)
if err != nil {
return nil, err
}
return FromURL(url)
}
// Irrelevant part omitted...
}
```
If `ParseURL` is vulnerable, then `FromURL` is likely vulnerable too, in which case this CL would leave vulnerable users (those who use `FromURL` directly) uninformed.
I think your heuristic for determining the vulnerable symbols are largely correct. However, manually digging into symbols like this for every report is likely not something we can and should do. As in the case of `FromURL`, it is easy for us to miss vulnerable symbols by doing solely manual evaluation.
While I don't think this is true for this particular case, even missing some fix commits entirely is probably pretty plausible. A package author, for example, might have some of their fix contained in a seemingly unrelated commit due to bad version control hygiene (or perhaps, it was an entirely unintended side-effect).
While a false positive from being conservative might be annoying, I think that's ultimately working as intended and better than the alternative. With the volume of reports we have coming in, adding the symbols for all reports are likely untenable and prone to mistake. We have to choose our battles wisely here. When symbols need to be added manually, it should be done when we are very sure that we can get it done right, and when doing so affects a large amount of users (e.g., package with a lot of imports and no fixed newer version).
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Kunal Memane (MK) (Gerrit)
Kunal Memane (MK) added 1 comment![]( "Open in Gerrit")
Thanks for the detailed explanation, that makes sense. You're right that FromURL is a gap I missed, which itself proves your point about manual symbol analysis being error prone.
I agree that being conservative is the right default here, especially given the volume of incoming reports. The false positive tradeoff is better than risking false negatives from incomplete symbol coverage.
I'll drop the change and keep the report with an unpopulated symbols section.
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gopher Robot (Gerrit)
Gopher Robot abandoned this change.
Gopher Robot abandoned this change![]( "Open in Gerrit")
Related details
Code-Review
LUCI-Pass
No-Unresolved-Comments
Review-Enforcement
TryBots-Pass
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |