## Summary In Gogs 0.14.1, `GET /attachments/:uuid` returns the raw attachment file **without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository**. In a test environment with `REQUIRE_SIGNIN_VIEW = false`, we confirmed that **an unauthenticated user can download attachments belonging to a private repository**. ## Description `/attachments/:uuid` retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file **without performing any authorization checks** against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known. Relevant code (internal/cmd/web.go:306): ```go m.Get("/attachments/:uuid", func(c *context.Context) { attach, err := database.GetAttachmentByUUID(c.Params(":uuid")) if err != nil { c.NotFoundOrError(err, "get attachment by UUID") return } else if !com.IsFile(attach.LocalPath()) { c.NotFound() return } fr, err := os.Open(attach.LocalPath()) if err != nil { c.Error(err, "open attachment file") return } defer fr.Close() c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox") c.Header().Set("Cache-Control", "public,max-age=86400") c.Header().Set("Content-Disposition", fmt.Sprintf(`inline; filename="%s"`, attach.Name)) if _, err = io.Copy(c.Resp, fr); err != nil { c.Error(err, "copy from file to response") return } }) ``` The UUID lookup itself also performs **no validation tied to repository visibility or user permissions**. Authorization is not enforced at this layer. Relevant code (internal/database/attachment.go:124): ```go // GetAttachmentByUUID returns attachment by given UUID. func GetAttachmentByUUID(uuid string) (*Attachment, error) { return getAttachmentByUUID(x, uuid) } ``` ## Preconditions * The attacker knows the target attachment’s UUID (i.e., the attachment URL). * For unauthenticated exploitation: `[auth] REQUIRE_SIGNIN_VIEW = false`. * Even when `REQUIRE_SIGNIN_VIEW = true`, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment. ## Steps to Reproduce 1. Log in as an administrator and create a private repository, e.g. `myadmin/idor-attach-1770724346-1a13bb`. 2. Add an attachment to an Issue in that repository and note the attachment UUID (example UUID used during testing: `f06d90f8-5b62-4c10-ac8d-f11fdf870b57`). 3. Log out and access the following as an unauthenticated user: * The repository page → 404 Not Found <img width="1702" height="758" alt="image" src="https://github.com/user-attachments/assets/8fdb1d92-cfc3-4ef8-977e-60ec13f792df" /> * The Issue page under that repository → 404 Not Found <img width="1983" height="546" alt="image" src="https://github.com/user-attachments/assets/c44c5e69-8ca2-4ea6-a071-62302b7e896f" /> * `GET /attachments/<uuid>` → **the attachment file is successfully downloaded** <img width="2007" height="378" alt="image" src="https://github.com/user-attachments/assets/23950ac6-6b3a-42f8-a06b-b9e0cf508d24" /> ## Minimum Required Privileges * `REQUIRE_SIGNIN_VIEW = false`: none (works without authentication). * `REQUIRE_SIGNIN_VIEW = true`: only the ability to log in (repository view permission is not required in practice). ## Impact * Confidential information attached to private repositories or restricted Issues/Releases may be disclosed. * Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments. * While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.
## Summary In Gogs 0.14.1, `GET /attachments/:uuid` returns the raw attachment file **without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository**. In a test environment with `REQUIRE_SIGNIN_VIEW = false`, we confirmed that **an unauthenticated user can download attachments belonging to a private repository**. ## Description `/attachments/:uuid` retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file **without performing any authorization checks** against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known. Relevant code (internal/cmd/web.go:306): ```go m.Get("/attachments/:uuid", func(c *context.Context) { attach, err := database.GetAttachmentByUUID(c.Params(":uuid")) if err != nil { c.NotFoundOrError(err, "get attachment by UUID") return } else if !com.IsFile(attach.LocalPath()) { c.NotFound() return } fr, err := os.Open(attach.LocalPath()) if err != nil { c.Error(err, "open attachment file") return } defer fr.Close() c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox") c.Header().Set("Cache-Control", "public,max-age=86400") c.Header().Set("Content-Disposition", fmt.Sprintf(`inline; filename="%s"`, attach.Name)) if _, err = io.Copy(c.Resp, fr); err != nil { c.Error(err, "copy from file to response") return } }) ``` The UUID lookup itself also performs **no validation tied to repository visibility or user permissions**. Authorization is not enforced at this layer. Relevant code (internal/database/attachment.go:124): ```go // GetAttachmentByUUID returns attachment by given UUID. func GetAttachmentByUUID(uuid string) (*Attachment, error) { return getAttachmentByUUID(x, uuid) } ``` ## Preconditions * The attacker knows the target attachment’s UUID (i.e., the attachment URL). * For unauthenticated exploitation: `[auth] REQUIRE_SIGNIN_VIEW = false`. * Even when `REQUIRE_SIGNIN_VIEW = true`, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment. ## Steps to Reproduce 1. Log in as an administrator and create a private repository, e.g. `myadmin/idor-attach-1770724346-1a13bb`. 2. Add an attachment to an Issue in that repository and note the attachment UUID (example UUID used during testing: `f06d90f8-5b62-4c10-ac8d-f11fdf870b57`). 3. Log out and access the following as an unauthenticated user: * The repository page → 404 Not Found <img width="1702" height="758" alt="image" src="https://github.com/user-attachments/assets/8fdb1d92-cfc3-4ef8-977e-60ec13f792df" /> * The Issue page under that repository → 404 Not Found <img width="1983" height="546" alt="image" src="https://github.com/user-attachments/assets/c44c5e69-8ca2-4ea6-a071-62302b7e896f" /> * `GET /attachments/<uuid>` → **the attachment file is successfully downloaded** <img width="2007" height="378" alt="image" src="https://github.com/user-attachments/assets/23950ac6-6b3a-42f8-a06b-b9e0cf508d24" /> ## Minimum Required Privileges * `REQUIRE_SIGNIN_VIEW = false`: none (works without authentication). * `REQUIRE_SIGNIN_VIEW = true`: only the ability to log in (repository view permission is not required in practice). ## Impact * Confidential information attached to private repositories or restricted Issues/Releases may be disclosed. * Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments. * While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.
Update gogs.io/gogs to 0.14.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanGogs Missing Authorization in Attachment Download affects gogs.io/gogs (go). Severity is high. ## Summary In Gogs 0.14.1, `GET /attachments/:uuid` returns the raw attachment file **without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository**. In a test environment with `REQUIRE_SIGNIN_VIEW = false`, we confirmed that **an unauthenticated user can download attachments belonging to a private repository**. ## Description `/attachments/:uuid` retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file **without performing any authorization checks** against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known. Relevant code (internal/cmd/web.go:306): ```go m.Get("/attachments/:uuid", func(c *context.Context) { attach, err := database.GetAttachmentByUUID(c.Params(":uuid")) if err != nil { c.NotFoundOrError(err, "get attachment by UUID") return } else if !com.IsFile(attach.LocalPath()) { c.NotFound() return } fr, err := os.Open(attach.LocalPath()) if err != nil { c.Error(err, "open attachment file") return } defer fr.Close() c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox") c.Header().Set("Cache-Control", "public,max-age=86400") c.Header().Set("Content-Disposition", fmt.Sprintf(`inline; filename="%s"`, attach.Name)) if _, err = io.Copy(c.Resp, fr); err != nil { c.Error(err, "copy from file to response") return } }) ``` The UUID lookup itself also performs **no validation tied to repository visibility or user permissions**. Authorization is not enforced at this layer. Relevant code (internal/database/attachment.go:124): ```go // GetAttachmentByUUID returns attachment by given UUID. func GetAttachmentByUUID(uuid string) (*Attachment, error) { return getAttachmentByUUID(x, uuid) } ``` ## Preconditions * The attacker knows the target attachment’s UUID (i.e., the attachment URL). * For unauthenticated exploitation: `[auth] REQUIRE_SIGNIN_VIEW = false`. * Even when `REQUIRE_SIGNIN_VIEW = true`, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment. ## Steps to Reproduce 1. Log in as an administrator and create a private repository, e.g. `myadmin/idor-attach-1770724346-1a13bb`. 2. Add an attachment to an Issue in that repository and note the attachment UUID (example UUID used during testing: `f06d90f8-5b62-4c10-ac8d-f11fdf870b57`). 3. Log out and access the following as an unauthenticated user: * The repository page → 404 Not Found <img width="1702" height="758" alt="image" src="https://github.com/user-attachments/assets/8fdb1d92-cfc3-4ef8-977e-60ec13f792df" /> * The Issue page under that repository → 404 Not Found <img width="1983" height="546" alt="image" src="https://github.com/user-attachments/assets/c44c5e69-8ca2-4ea6-a071-62302b7e896f" /> * `GET /attachments/<uuid>` → **the attachment file is successfully downloaded** <img width="2007" height="378" alt="image" src="https://github.com/user-attachments/assets/23950ac6-6b3a-42f8-a06b-b9e0cf508d24" /> ## Minimum Required Privileges * `REQUIRE_SIGNIN_VIEW = false`: none (works without authentication). * `REQUIRE_SIGNIN_VIEW = true`: only the ability to log in (repository view permission is not required in practice). ## Impact * Confidential information attached to private repositories or restricted Issues/Releases may be disclosed. * Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments. * While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| gogs.io/gogsgo | <=0.14.2 | 0.14.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate gogs.io/gogs to 0.14.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanGogs Missing Authorization in Attachment Download affects gogs.io/gogs (go). Severity is high. ## Summary In Gogs 0.14.1, `GET /attachments/:uuid` returns the raw attachment file **without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository**. In a test environment with `REQUIRE_SIGNIN_VIEW = false`, we confirmed that **an unauthenticated user can download attachments belonging to a private repository**. ## Description `/attachments/:uuid` retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file **without performing any authorization checks** against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known. Relevant code (internal/cmd/web.go:306): ```go m.Get("/attachments/:uuid", func(c *context.Context) { attach, err := database.GetAttachmentByUUID(c.Params(":uuid")) if err != nil { c.NotFoundOrError(err, "get attachment by UUID") return } else if !com.IsFile(attach.LocalPath()) { c.NotFound() return } fr, err := os.Open(attach.LocalPath()) if err != nil { c.Error(err, "open attachment file") return } defer fr.Close() c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox") c.Header().Set("Cache-Control", "public,max-age=86400") c.Header().Set("Content-Disposition", fmt.Sprintf(`inline; filename="%s"`, attach.Name)) if _, err = io.Copy(c.Resp, fr); err != nil { c.Error(err, "copy from file to response") return } }) ``` The UUID lookup itself also performs **no validation tied to repository visibility or user permissions**. Authorization is not enforced at this layer. Relevant code (internal/database/attachment.go:124): ```go // GetAttachmentByUUID returns attachment by given UUID. func GetAttachmentByUUID(uuid string) (*Attachment, error) { return getAttachmentByUUID(x, uuid) } ``` ## Preconditions * The attacker knows the target attachment’s UUID (i.e., the attachment URL). * For unauthenticated exploitation: `[auth] REQUIRE_SIGNIN_VIEW = false`. * Even when `REQUIRE_SIGNIN_VIEW = true`, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment. ## Steps to Reproduce 1. Log in as an administrator and create a private repository, e.g. `myadmin/idor-attach-1770724346-1a13bb`. 2. Add an attachment to an Issue in that repository and note the attachment UUID (example UUID used during testing: `f06d90f8-5b62-4c10-ac8d-f11fdf870b57`). 3. Log out and access the following as an unauthenticated user: * The repository page → 404 Not Found <img width="1702" height="758" alt="image" src="https://github.com/user-attachments/assets/8fdb1d92-cfc3-4ef8-977e-60ec13f792df" /> * The Issue page under that repository → 404 Not Found <img width="1983" height="546" alt="image" src="https://github.com/user-attachments/assets/c44c5e69-8ca2-4ea6-a071-62302b7e896f" /> * `GET /attachments/<uuid>` → **the attachment file is successfully downloaded** <img width="2007" height="378" alt="image" src="https://github.com/user-attachments/assets/23950ac6-6b3a-42f8-a06b-b9e0cf508d24" /> ## Minimum Required Privileges * `REQUIRE_SIGNIN_VIEW = false`: none (works without authentication). * `REQUIRE_SIGNIN_VIEW = true`: only the ability to log in (repository view permission is not required in practice). ## Impact * Confidential information attached to private repositories or restricted Issues/Releases may be disclosed. * Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments. * While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| gogs.io/gogsgo | <=0.14.2 | 0.14.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard