cgit is a fast web frontend for Git repositories. It can be a good fit for public code browsing, and it can also sit in front of private repositories when a deployment adds an authentication layer. The critical configuration question is simple: is an authentication filter defined, and does the surrounding web server enforce the intended access?

On 2026-11-11 at 08:46:59 +08:00, title="cgit" returned 124 ZoomEye matches with page 1, page size 1, and sub_type=all. A body query for http.body="cgit" returned 11,727 matches at 08:47:00 +08:00. The links are the title query and the body query.

The body query is very broad. cgit output, generated links, documentation, and asset paths can all contain the string. The title count is narrower but still does not prove that a server is intentionally public. Neither number identifies a vulnerable installation.

The default is no authentication

The cgitrc manual states that if no auth-filter is specified, no authentication is performed. That is a deployment choice, not a hidden vulnerability. A public mirror may intend to serve anonymous read access. A private source repository must not rely on a custom title, an unguessable URL, or a reverse proxy path that can be bypassed.

The auth filter receives request details and can require a login, validate a cookie, or show a login form. Review the filter as part of the application boundary. It should use a trusted identity source, reject malformed input, and fail closed when its authentication backend is unavailable.

Check both UI and clone paths

An HTML browser can receive a login page while the Git transport path accepts anonymous clone requests. The cgit route and the underlying repository route must be tested together. Use a Git client without credentials to attempt a clone, then repeat with a least-privileged account and an account that should be denied.

Review repository-specific configuration as well as the global cgitrc. A per-repository file can change settings when scanning is enabled. If the deployment uses a scan path, verify which files are trusted and whether a repository can override a security-relevant option. The repository owner should not be able to silently disable an authentication control that the platform expects.

Look for cached and alternate routes

cgit can be deployed behind a cache or a reverse proxy. A cached response may survive a policy change. An alternate hostname may point directly to the cgit listener while the primary hostname passes through the authentication proxy. Record every route and test after a configuration change.

The web server may also serve static files or repository archives from a directory that cgit does not control. Those paths need their own access rules. A public HTML page can coexist with a private archive directory only if the routing and filesystem permissions make that intention explicit.

A focused validation plan

For each confirmed cgit deployment:

  1. 1.

    Record whether auth-filter is configured.

  2. 2.

    Test anonymous access to the index and one repository.

  3. 3.

    Test an anonymous clone URL.

  4. 4.

    Test a denied private repository as a non-member.

  5. 5.

    Confirm the proxy strips client-supplied identity headers.

  6. 6.

    Repeat after a cache purge or restart.

The result should distinguish a public mirror from a private repository with an accidental public route. The cgit manual gives the deployment a direct place to express that distinction. The operator should verify that the configured filter is actually the one in effect.

Use the counts carefully

The 124 title matches and 11,727 body matches describe search visibility, not a security verdict. Body matches are especially likely to include generated pages and mentions. Start from a confirmed host, inspect its configuration, and test the transport path. That evidence is more useful than a larger count.

References